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

SergeCaron · Oct 7, 2016, 1:15 PM

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 · Oct 7, 2016, 2:19 PM

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 · Oct 7, 2016, 6:31 PM

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 · Oct 14, 2016, 8:18 PM

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 · Oct 19, 2016, 6:57 PM

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.