[Openswan dev] Re: transport mode and NAT-T

[Norbert Wegener]

Hi Michael,
great, that you've found those bugs. If you need access to the machine 
again, please let me know.
Do you need me to crash pluto again, or is it sufficient, when you have 
access to that machine? 
Unfortunately the server is down right now, but maybe tomorrow in the 
afternoon German time I will find to bring it up again.
Please let me know, how I can help.
Norbert

Michael Richardson wrote:

>-----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,
>
Yes.

> 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-----
>  
>