[Openswan Users] Any known problems with NAT Traversal with Linux 2.4.26/2.6.7?

[Toby Corkindale]

Hi,

I currently have a VPN server that accepts connection successfully from
roadwarriors who have "real" IP addresses. However I have not managed to make
any successful connections from hosts behind NAT boxes. The machine behind the
NAT firewall believes it has made an encrypted session, but the other machine
doesn't.
I have a possible thought about what might be causing this - see below.

The VPN server is running linux kernel 2.4.26 w/OpenSwan 2.1.4.
The roadwarriors are all linux kernel 2.6.7 w/OpenSwan 2.1.4 and ipsec-tools.
Is anyone out there currently using such a combination successfully with
NAT-Traversal?

These machines' firewalls allow all ESP and AH traffic, as well as UDP on
ports 500 and 4500.
The configuration I am using works fine for non-NAT situations. The thing that
gets me is that it looks like it *should* be working in NAT situations, too!
I can see traffic travel back and forth, and the log files indicate that the
hosts realise that one of them is NATed.
UDP traffic on port 500 and 4500 is making it thru successfully in both
directions.

The machine behind the NAT box decides the connection is made, viz:
[snip]
pluto[24404]: "work-to-home" #2: initiating Quick Mode RSASIG+ENCRYPT+COMPRESS+TUNNEL+PFS+UP {using isakmp#1}
pluto[24404]: "work-to-home" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
pluto[24404]: "work-to-home" #2: sent QI2, IPsec SA established {ESP=>0x8d4ea27c <0x1ad917c9 IPCOMP=>0x0000a404 <0x000009d8}


However the server doesn't think so.. (IP address changed to 123.321 for the
external host intentionally.. it's actually valid normally ;)
[snip]
pluto[2850]: | NAT-T: new mapping 193.30.123.321:500/4500)
pluto[2850]: "roadwarrior"[4] 193.30.123.321:4500 #6: sent MR3, ISAKMP SA established
pluto[2850]: "roadwarrior"[4] 193.30.123.321:4500 #7: responding to Quick Mode
pluto[2850]: "roadwarrior"[4] 193.30.123.321:4500 #7: transition from state (null) to state STATE_QUICK_R1
pluto[2850]: packet from 192.168.2.11:4500: Quick Mode message is for a non-existent (expired?) ISAKMP SA
pluto[2850]: "roadwarrior"[4] 193.30.123.321:4500 #7: max number of retransmissions (2) reached STATE_QUICK_R1


Now, Look at the second to last line there - notice how the packet has come
from the NATed host's *internal* address, whereas all the previous packets
were from the external address..

Do you think that might have something to do with the problem?

Thanks,
Toby

-- 
Turning and turning in the widening gyre/The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world
(gpg --keyserver www.co.uk.pgp.net --recv-key 897E5FF3)