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



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


  • Rebel Alliance Developer Netgate

    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.



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



  • 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


  • Rebel Alliance Developer Netgate

    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.