L2TP/IPsec on FreeBSD 10 and a Windows 7 Client behind NAT

[Dr. Rolf Jansen]

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

[Martin Willi]

Hi,

Post by Dr. Rolf Jansen
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].

Using L2TP/IPsec over NAT is very problematic, and IMHO broken by
design. Having multiple clients behind the same NAT does not work
without quirks. You'd have to somehow bind your L2TP session to a
specific IPsec SA, but we don't bring any specific support for that (nor
does ipsec-tools, AFAIK).

Post by Dr. Rolf Jansen
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!!!).

All I can recommend is to not switch to "another system", but to a sane
protocol. Windows 7 has a well working native IKEv2 IPsec client, which
interoperates just fine with strongSwan [1]. On OS X you can use the
native IKEv1 client, or try our IKEv2 strongSwan App [2].

Regards
Martin

[1]https://wiki.strongswan.org/projects/strongswan/wiki/Windows7
[2]https://wiki.strongswan.org/projects/strongswan/wiki/MacOSX#Native-application

[Dr. Rolf Jansen]

Many thanks for your kind reply!

Post by Martin Willi

Post by Dr. Rolf Jansen
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].

Using L2TP/IPsec over NAT is very problematic, and IMHO broken by
design. Having multiple clients behind the same NAT does not work
without quirks. ...

I didn't mention this explicitly, however, I did all tests with the respective clients being the only active one behind the NAT. And as a matter of fact, Windows 7 does connect, but from the established IPsec endpoint, no single byte arrives at the L2TP-service on udp/1701, and this has never been a problem with any Apple clients. I agree, that multiple clients behind the same NAT are problematic, but this is not exactly the issue here.

Post by Martin Willi
... You'd have to somehow bind your L2TP session to a
specific IPsec SA, but we don't bring any specific support for that (nor
does ipsec-tools, AFAIK).

Multi-NAT-T is not a mission critical concern for me. If it works as with OS X or iOS connecting to strongSwan+mpd5, then this is nice to know, but if ever, it would be used rarely. The problem is that Windows even doesn't get IKEv1-Single-NAT-T right.

Post by Martin Willi

Post by Dr. Rolf Jansen
ipsec-tools do have a hell a lot of NAT-T issues, and I desperately
want to move to another system. ....

All I can recommend is to not switch to "another system", but to a sane
protocol. Windows 7 has a well working native IKEv2 IPsec client, which
interoperates just fine with strongSwan [1].

I am trying this already, using the win7-wiki [1]. So far this didn't work out, I could see a connection of Windows 7 in the charon log, but it stuck in phase 1, and after the time-out, charon deleted a half created SA. Yesterday, it became late over the trials (2 AM), and for sure I did something wrong. Today, I will go over it again. BTW, do I need to open special ports in the firewall for eap-tls besides UDP 500/4500?

Post by Martin Willi
On OS X you can use the
native IKEv1 client, or try our IKEv2 strongSwan App [2].

For the time being, let's forget OS X. Once I got Windows to work, using [1], I will see whether IKEv1 is broken then for OS X or not. Then – i.e. not now – I will need to evaluate all options again.

Best regards

Rolf