The server is running FreeBSD 10-RELEASE-p9 with IPsec/NATT enabled in the 
Kernel.
I installed installed strongSwan 5.2.0 from the FreeBSD Ports tree.

The ipsec.conf is:

conn L2TP
   leftauth = psk
   rightauth = psk
   left = 11.11.11.11
   right = %any
   auto = add

The strongswan.conf is:

charon
{
   load_modular = yes
   plugins
   {
      include strongswan.d/charon/*.conf
   }

   install_routes = no
   process_route = no

   filelog
   {
      /var/log/charon.log
      {
         flush_line = yes
         ike_name = yes
         time_format = "%Y-%m-%d %H:%M:%S"
      }
   }
}

The L2TP-Daemon is mpd5, and it is listening on the public IP address 
(11.11.11.11[udp1701]).

I can connect to this L2TP/IPsec setup using Mac OS X 10.6 to 10.9, and iOS 7 
clients sitting behind a NAT. A Windows 7 client from behind the same NAT 
establishes successful the IPsec connection to the server, ie. the SPD's and 
SAD's look almost identical to those created for the Apple clients, but the 
traffic does not arrive on 11.11.11.11[udp1701].

The interesting difference is that the SPD's of the Windows client does not 
show the NAT port but the original port number 1701, while for the Apple 
clients the translated port numbers show up.

Windows 7 --  # setkey -DP

10.10.10.10[1701] 11.11.11.11[1701] udp
        in ipsec
        esp/transport//unique:5
        created: Sep 17 22:02:12 2014  lastused: Sep 17 22:02:12 2014
        lifetime: 9223372036854775807(s) validtime: 0(s)
        spid=114 seq=1 pid=2631
        refcnt=1
11.11.11.11[1701] 10.10.10.10[1701] udp
        out ipsec
        esp/transport//unique:5
        created: Sep 17 22:02:12 2014  lastused: Sep 17 22:02:12 2014
        lifetime: 9223372036854775807(s) validtime: 0(s)
        spid=113 seq=0 pid=2631
        refcnt=1

Mac OS X / iOS --  # setkey -DP

10.10.10.10[55485] 11.11.11.11[1701] udp
        in ipsec
        esp/transport//unique:6
        created: Sep 17 22:05:16 2014  lastused: Sep 17 22:05:18 2014
        lifetime: 9223372036854775807(s) validtime: 0(s)
        spid=120 seq=1 pid=2647
        refcnt=1
11.11.11.11[1701] 10.10.10.10[55485] udp
        out ipsec
        esp/transport//unique:6
        created: Sep 17 22:05:16 2014  lastused: Sep 17 22:05:18 2014
        lifetime: 9223372036854775807(s) validtime: 0(s)
        spid=119 seq=0 pid=2647
        refcnt=1

Using the same setup with racoon from the ipsec-tools, the Apple clients can 
connect, and Windows 7 is stuck again in the stage of a successfully 
established IPsec connection, in exactly the same manner as with charon. 
However, for the racoon setup, IPsec kernel and ipsec-tools patches do exist, 
which makes Windows 7 clients behind a NAT connect successfully to the 
L2TP/IPsec server.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146190
http://lists.freebsd.org/pipermail/freebsd-stable/2012-May/067416.html

I recompile the patched kernel and start a patched racoon instead of charon, I 
leave the settings of the L2TP-daemon (mpd5) the same, and now the Windows 7 
client behind NAT can connect into L2TP. In the racoon case the issue is 
related to TCP/UDP checksums of packets protected by ESP, and said kernel 
patches simply allows for ignoring checksum mismatches.

ipsec-tools do have a hell a lot of NAT-T issues, and I desperately want to 
move to another system. strongSwan serves perfectly well any Apple client 
sitting behind a NAT (even a multitude of clients behind the same NAT, wow!!!). 
Perhaps, ignoring ESP checksum mismatches, would enable Windows 7 to connect by 
NAT-T in transport mode as well with charon?????

_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to