2.3.2-p1: No l2TP/IPSEC login for Windows Client behind NAT

SergeCaron

This happens on 2.3.2 releases: the logs below were created with:
2.3.2-RELEASE-p1 (amd64) built on Tue Sep 27 12:13:07 CDT 2016 FreeBSD 10.3-RELEASE-p9

There is no issue login IOS Clients (9.3.5 and 10.0.2) in this setup, regardless of NAT.

Windows Clients (7 Pro and 10 Pro) have the following setting:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule set to 2

I can verify with logs that pfSense is creating and deleting the L2TP tunnel when the client is not behind a NAT: :(

Windows 7 Client, No NAT

Oct 7 07:56:03 charon 05[ENC] <con1|6>parsed QUICK_MODE request 1 [ HASH ]
Oct 7 07:56:03 charon 05[IKE] <con1|6>CHILD_SA con1{6} established with SPIs c217cd81_i 381defdd_o and TS "pfSenseWANIP"/32|/0[udp/l2f] ===
"Client1WANIP"/32|/0[udp/l2f]
Oct 7 07:56:05 charon 05[KNL] interface l2tp0 activated
Oct 7 07:56:05 charon 05[KNL] 10.10.10.215 appeared on l2tp0
[…]
Oct 7 07:59:40 charon 16[KNL] 10.10.10.215 disappeared from l2tp0
Oct 7 07:59:40 charon 16[KNL] interface l2tp0 deactivated
Oct 7 07:59:44 charon 08[NET] <con1|6>received packet: from "Client1WANIP"[500] to "pfSenseWANIP"[500] (76 bytes)
Oct 7 07:59:44 charon 08[ENC] <con1|6>parsed INFORMATIONAL_V1 request 3874314286 [ HASH D ]
Oct 7 07:59:44 charon 08[IKE] <con1|6>received DELETE for ESP CHILD_SA with SPI 381defdd
Oct 7 07:59:44 charon 08[IKE] <con1|6>closing CHILD_SA con1{6} with SPIs c217cd81_i (412377 bytes) 381defdd_o (3163224 bytes) and TS
"pfSenseWANIP"/32|/0[udp/l2f] === "Client1WANIP"/32|/0[udp/l2f]

IOS 9.3.5 Client, No NAT

Oct 7 08:01:43 charon 15[ENC] <con1|7>parsed QUICK_MODE request 1648301045 [ HASH ]
Oct 7 08:01:43 charon 15[IKE] <con1|7>CHILD_SA con1{7} established with SPIs c700ce2e_i 096408a7_o and TS "pfSenseWANIP"/32|/0[udp/l2f] ===
"Client2WANIP"/32|/0[udp/59853]
Oct 7 08:01:46 charon 15[KNL] interface l2tp0 activated
Oct 7 08:02:01 charon 14[IKE] <con1|7>sending DPD request
[…]
Oct 7 08:07:52 charon 15[KNL] interface l2tp0 deactivated
Oct 7 08:07:52 charon 15[NET] <con1|7>received packet: from "Client2WANIP"[500] to "pfSenseWANIP"[500] (76 bytes)
Oct 7 08:07:52 charon 15[ENC] <con1|7>parsed INFORMATIONAL_V1 request 3293977714 [ HASH D ]
Oct 7 08:07:52 charon 15[IKE] <con1|7>received DELETE for ESP CHILD_SA with SPI 096408a7
Oct 7 08:07:52 charon 15[IKE] <con1|7>closing CHILD_SA con1{7} with SPIs c700ce2e_i (19657 bytes) 096408a7_o (50152 bytes) and TS
"pfSenseWANIP"/32|/0[udp/l2f] === "Client2WANIP"/32|/0[udp/59853]

If I place these clients behind a pfSense device (earlier version)
2.2.6-RELEASE (amd64) built on Mon Dec 21 14:50:08 CST 2015 FreeBSD 10.1-RELEASE-p25

I can verift that IOS devices can still login:

IOS 9.3.5 Client, NAT

Oct 7 08:17:21 charon 08[ENC] <con1|9>parsed QUICK_MODE request 3242839932 [ HASH ]
Oct 7 08:17:21 charon 08[IKE] <con1|9>CHILD_SA con1{9} established with SPIs c31f84c3_i 09a0a176_o and TS "pfSenseWANIP"/32|/0[udp/l2f] ===
"NATdeviceWANIP"/32|/0[udp/59727]
Oct 7 08:17:23 charon 08[KNL] interface l2tp0 appeared
Oct 7 08:17:23 charon 08[KNL] interface l2tp0 activated
Oct 7 08:17:39 charon 12[IKE] <con1|9>sending DPD request
[…]
Oct 7 08:18:46 charon 15[KNL] 10.10.10.215 disappeared from l2tp0
Oct 7 08:18:46 charon 15[KNL] interface l2tp0 deactivated
Oct 7 08:18:46 charon 15[NET] <con1|9>received packet: from "NATdeviceWANIP"[42557] to "pfSenseWANIP"[4500] (76 bytes)
Oct 7 08:18:46 charon 15[ENC] <con1|9>parsed INFORMATIONAL_V1 request 4108575017 [ HASH D ]
Oct 7 08:18:46 charon 15[IKE] <con1|9>received DELETE for ESP CHILD_SA with SPI 09a0a176
Oct 7 08:18:46 charon 15[IKE] <con1|9>closing CHILD_SA con1{9} with SPIs c31f84c3_i (8605 bytes) 09a0a176_o (14248 bytes) and TS
"pfSenseWANIP"/32|/0[udp/l2f] === "NATdeviceWANIP"/32|/0[udp/59727]
Oct 7 08:18:46 charon 05[NET] <con1|9>received packet: from "NATdeviceWANIP"[42557] to "pfSenseWANIP"[4500] (92 bytes)
Oct 7 08:18:46 charon 05[ENC] <con1|9>parsed INFORMATIONAL_V1 request 1495342214 [ HASH D ]
Oct 7 08:18:46 charon 05[IKE] <con1|9>received DELETE for IKE_SA con1[9]
Oct 7 08:18:46 charon 05[IKE] <con1|9>deleting IKE_SA con1[9] between "pfSenseWANIP"["pfSenseWANIP"]…"NATdeviceWANIP"[192.168.18.34]

But pfSense does not create the L2TP tunnel. In fact, the call is terminated as soon as the IPSEC SA/SPI are created:

Windows 10 Client, NAT

Oct 7 07:13:32 charon 10[IKE] <con1|1>CHILD_SA con1{1} established with SPIs cd9071af_i c2cbfa88_o and TS "pfSenseWANIP"/32|/0[udp/l2f] ===
"NATdeviceWANIP"/32|/0[udp/l2f]
Oct 7 07:14:07 charon 05[NET] <con1|1>received packet: from "NATdeviceWANIP"[52326] to "pfSenseWANIP"[4500] (76 bytes)
Oct 7 07:14:07 charon 05[ENC] <con1|1>parsed INFORMATIONAL_V1 request 2352928504 [ HASH D ]
Oct 7 07:14:07 charon 05[IKE] <con1|1>received DELETE for ESP CHILD_SA with SPI c2cbfa88
Oct 7 07:14:07 charon 05[IKE] <con1|1>closing CHILD_SA con1{1} with SPIs cd9071af_i (715 bytes) c2cbfa88_o (0 bytes) and TS "pfSenseWANIP"/32|/0
[udp/l2f] === "NATdeviceWANIP"/32|/0[udp/l2f]

Windows 7 Client, NAT

Oct 7 08:23:32 charon 07[ENC] <con1|10>parsed QUICK_MODE request 1 [ HASH ]
Oct 7 08:23:32 charon 07[IKE] <con1|10>CHILD_SA con1{10} established with SPIs cd5aabb2_i 0dfcc4c7_o and TS "pfSenseWANIP"/32|/0[udp/l2f] ===
"NATdeviceWANIP"/32|/0[udp/l2f]
Oct 7 08:24:07 charon 07[NET] <con1|10>received packet: from "NATdeviceWANIP"[3599] to "pfSenseWANIP"[4500] (76 bytes)
Oct 7 08:24:07 charon 07[ENC] <con1|10>parsed INFORMATIONAL_V1 request 1541744095 [ HASH D ]
Oct 7 08:24:07 charon 07[IKE] <con1|10>received DELETE for ESP CHILD_SA with SPI 0dfcc4c7
Oct 7 08:24:07 charon 07[IKE] <con1|10>closing CHILD_SA con1{10} with SPIs cd5aabb2_i (870 bytes) 0dfcc4c7_o (0 bytes) and TS "pfSenseWANIP"/32|/0
[udp/l2f] === "NATdeviceWANIP"/32|/0[udp/l2f]

There are no log entries that I can find explaining this behavior.

Can this be fixed?

Regards,</con1|10></con1|10></con1|10></con1|10></con1|10></con1|10></con1|1></con1|1></con1|1></con1|1></con1|1></con1|9></con1|9></con1|9></con1|9></con1|9></con1|9></con1|9></con1|9></con1|9></con1|9></con1|9></con1|7></con1|7></con1|7></con1|7></con1|7></con1|7></con1|7></con1|6></con1|6></con1|6></con1|6></con1|6></con1|6>

jimp

Windows clients will not work with L2TP/IPsec behind NAT – We even have a warning about that at the top of https://doc.pfsense.org/index.php/L2TP/IPsec

There is an issue between the Windows clients and strongSwan with L2TP/IPsec and for whatever reason the Windows client is not negotiating it properly.

You're better all-around if you move on to IKEv2 and don't bother with L2TP/IPsec.

SergeCaron

Thank you for your answer.

Actually, the warning is "Users have reported issues with Windows L2TP/IPsec clients behind NAT. If the clients will be behind NAT, an IKEv2 implementation may be a better fit.", which is a LOT weaker than your definitive "will not work behind NAT".

Perhaps, a review of said warning is in order.

Regards,

mikeboss

this is a total disaster! because of licensing BS, I switched all my customers from Sophos UTM to pfSense. using Sophos UTM, L2TP over IPsec worked just fine on both Windows and OS X clients without the need for any additional software on the client side. today I was trying to install the first Windows client: no-go. IMHO you should remove L2TP over IPsec completely if it's not working in the most common use case… or at least show a STRONG warning in the GUI of pfSense. now I feel like I did bet on the wrong horse.

regards,
michael

jimp

Both IPsec and L2TP work fine on their own for their intended purposes, it's the combination that fails in that situation. It wouldn't be accurate to place a warning anywhere in the pfSense GUI as it wouldn't be directly relevant, thus the warning on the wiki.