[Openswan dev] transport mode and NAT-T

Michael Richardson mcr at xelerance.com
Mon Jul 25 01:50:29 CEST 2005


-----BEGIN PGP SIGNED MESSAGE-----


Hi Norbert,

I wrote five test cases in the past couple of days:
a) iv-01     - reproduces issue with st_new_iv_len < e->blocksize,
	     and fixes it. (Norbert, this is what caused your system to
	     crash when it was unable to install the second SA)
	     See code in demux.c marked as such.
	     (Debugged on Friday)

b) nat-double-01 - test case for having two nodes (in tunnel mode)
		 behind the same NAT. I found no issues with this test
		 case.

c) transport-01	 - test case for transport mode between two non-NAT'ed
		 systems.  I guess people using transport mode realize
		 that they have to have a %pass policy for the ports
	         that they don't want to travel through the tunnel,
		 otherwise they get dropped. This is a KLIPS-ism, that
		 I'd like to fix in KLIPS3.

d) nat-transport-02 - same test case as above, but one end is behind a NAT.

e) nat-transport-03 - same as -02, but two nodes are behind a NAT.


Norbert, I could not reproduce your second issue, where it was unable to
install the second transport mode SA. Pluto thinks the second SA would
overlap with the first according to the logs that I read.

I will have to examine your configuration again to see if you are doing
something different than I.  I did not go all the way with l2tp, I just
used tcp transport mode SAs. I will write another test case that uses
UDP rather than TCP. I think that there is an outstanding patch relating
to UDP and NAT-T that affects L2TP.

I believe that you are using NETKEY rather than KLIPS, but I believe
that pluto decided before getting to the kernel that it would be unable
to do so. 

I did fix a nasty NAT-T bug --- DPD R_U_THERE_ACK messages were returned
from port 500 rather than from port 4500.  This would affect anyone with
a 5-tuple aware NAT box, (such as *LINUX* netfilter), but probably doesn't
affect the D-Link crowd. Anyone running HEAD may want to make clean,
just to be sure, since I added structure members.

The above code won't get committed until around Monday afternoon, since
I'm at my in-laws' cottage.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [

	
	
 
	

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQuRvhYqHRg3pndX9AQFXPwP+KSYF7+w0pnGWOmC/G0z61wvcNXdEiSAo
A4UtALpCNdk5Lf112Z7MEFBNL0EBYpJyGjwp/IwmYf7P6n5uorLrkDpR993J9A93
dO3RrULANQQm8Aoh0eidZnpi6R1bzA/WRIC7TI+wQr/TGsXjzR+FOqt/2GS8qHP5
OURLM2E46qY=
=UaPB
-----END PGP SIGNATURE-----


More information about the Dev mailing list