<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
Hello, <BR>
<BR>
I'm trying to deploy a net-to-net VPN using openswan 2.2.0 and two Linux boxes running kernel 2.6 (so native Ipsec support is used). My problems are multiple and I've done a lot of tests to discover whats doing me crazy. Writting all here would be too mucho, so I'll try to ask only my main headaches ;-) Thanks for reading<BR>
<BR>
In mi case, I'm forced to use NAT-T support because both ends of the desired tunnel are located after soho routers doing NAT:<BR>
<BR>
<BR>
---Net1----T1-----R1------------------------Internet-------------------R2---------T2----Net2<BR>
NAT NAT<BR>
<BR>
Routers R1 and R2 are form different vendors and I suspect one of them is doing something nasty with Ipsec-passthrough because after setting up correctly openswan in both ends, tunnel only comes up initiating from T1 and gets blocked forever in MainMode if I try to initiate from T2. When initiation from T1 is done, Initiation from T2 in Quick mode gets up with no problems.<BR>
<BR>
Lets supose that this assymetric behaviour is not there.<BR>
<BR>
1st big problem: When rekey time is reached, or tunnel goes down/up on the remote end (restaring ipsec, entire host, or simulation (delete+add+up), NEGOTIATION NEVER WORKS !! anybody can tell me why ? ipsec barf shows lines similar to the next in a loop:<BR>
<BR>
Oct 22 18:00:50 Glaurung pluto[3972]: packet from x.x.x.x:516: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]<BR>
Oct 22 18:00:50 Glaurung pluto[3972]: packet from x.x.x.x:516: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 108<BR>
Oct 22 18:00:50 Glaurung pluto[3972]: packet from x.x.x.x:516: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]<BR>
Oct 22 18:00:50 Glaurung pluto[3972]: packet from x.x.x.x:516: initial Main Mode message received on 192.168.1.10:500 but no connection has been authorized<BR>
<BR>
The only way to recover the tunnel is totally rebuild it in both ends. Obiously, this has no future.<BR>
<BR>
After get tired of what seems problems in IKE+NAT+router magic, I decided to build tunnel manually without using IKE at all.<BR>
<BR>
QUESTION: How can it be done ? I've tried the options that comes with Openswan2.2.0 (ipsec manual), but my great surprise is that ipsec manual relies completelly over pseudo-interfaces like ipsec0 and they are not there in kernel 2.6 !! Is this a reported BUG ? or a big TODO ;-)<BR>
I've setted up a tunnel playing with setkey with something like this:<BR>
<BR>
#!/sbin/setkey -f<BR>
<BR>
# Flush the SAD and SPD<BR>
flush;<BR>
spdflush;<BR>
<BR>
# ESP SAs doing encryption using 192 bit long keys (168 + 24 parity)<BR>
# and authentication using 128 bit long keys<BR>
add 192.168.1.10 T1.T1.T1.T1 esp 0x201 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;<BR>
<BR>
add T2.T2.T2.T2 192.168.1.10 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;<BR>
<BR>
# Security policies<BR>
spdadd 192.168.1.10/32 10.10.0.0/16 any -P out ipsec esp/tunnel/192.168.1.10-T1.T1.T1.T1/require;<BR>
<BR>
spdadd 10.10.0.0/16 192.168.1.10/32 any -P in ipsec esp/tunnel/T2.T2.T2.T2-192.168.1.10/require;<BR>
<BR>
It works (chypers traffic), but IT DOES NOT ENCAPSULATE ESP in UDP (NAT-T), so is totally useless for me :-(<BR>
<BR>
THE BIG QUESTION:<BR>
Is possible to set up a tunnel suporting NAT on both ends ? and if true (I hope), how can it be done WITHOUT IKE ? will it be possible on kernel 2.6 + Openswan 2.2.0 or a downgrade is needed ? any config example ? some similar experience ?<BR>
<BR>
Any help will be great !!!<BR>
<BR>
Bye<BR>
Albert<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>