This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

L2TP Dialin stopped working

Hello Community,

I have a problem on a firewall, here the L2TP dialup does not work anymore. Until yesterday this had worked, it only had the problem that the PSK changed (community.sophos.com/.../l2tp-psk-issue). Yesterday I had reset the SSMK (Secure Storage Master Key) on the firewall and then re-entered the L2TP PSK on the firewall. Now I get this message on the client (Windows 10):

Can't connect to The L2TP connection attempt failed because the security layer could not negotiate compatible parameters with the remote computer.

Restarting the VPN processes and rebooting the firewall did not change anything either. Likewise, deleting the L2TP configuration and creating it again did not change anything.

On the Windows client I deleted the L2TP connection and created it again. This also did not change anything. The above error message comes very quickly.

When I use "show vpn L2TP-logs" to look at the L2TP, I don't see any entries in the connection setup log:

console> show vpn L2TP-logs
xl2tpd[21823]: Listening on IP address 0.0.0.0, port 1701
xl2tpd[21823]: death_handler: Fatal signal 15 received
xl2tpd[7334]: Not looking for kernel SAref support.
xl2tpd[7334]: L2TP kernel support not detected (try modprobing l2tp_ppp and pppol2tp)
xl2tpd[7334]: xl2tpd version xl2tpd-1.3.10 started on localhost PID:7334
xl2tpd[7334]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[7334]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[7334]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[7334]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
xl2tpd[7334]: Listening on IP address 0.0.0.0, port 1701

If I look at the whole thing with a TCPDump then I see exactly 2 packets and then the error message comes directly on the client:

SG550_XN01_SFOS 18.0.5 MR-5# tcpdump -i PortA1 host 80.xxx.xxx.xxx -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on PortA1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:24:38.218078 PortA1, IN: IP 80.xxx.xxx.xxx.500 > yyy.yyy.yyy.254.500: isakmp: phase 1 I ident
09:24:38.218854 PortA1, OUT: IP yyy.yyy.yyy.254.500 > 80.xxx.xxx.xxx.500: isakmp: phase 2/others R inf

When I look into the "strongswan.log" I see that the "received proposals" do not match with the "configured proposals". On the firewall I use the "DefaultL2TP" policy. I compared this with other firewalls (on which the dial-in works) and the same settings are set. From my client I can connect to the other sites. This log is from the not working dialup:

2021-04-29 09:27:31 29[NET] <177> received packet: from 80.xxx.xxx.xxx[500] to yyy.yyy.yyy.254[500] (408 bytes)
2021-04-29 09:27:31 29[ENC] <177> parsed ID_PROT request 0 [ SA V V V V V V V V ]
2021-04-29 09:27:31 29[ENC] <177> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:01
2021-04-29 09:27:31 29[IKE] <177> received MS NT5 ISAKMPOAKLEY vendor ID
2021-04-29 09:27:31 29[IKE] <177> received NAT-T (RFC 3947) vendor ID
2021-04-29 09:27:31 29[IKE] <177> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
2021-04-29 09:27:31 29[IKE] <177> received FRAGMENTATION vendor ID
2021-04-29 09:27:31 29[ENC] <177> received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
2021-04-29 09:27:31 29[ENC] <177> received unknown vendor ID: 26:24:4d:38:ed:db:61:b3:17:2a:36:e3:d0:cf:b8:19
2021-04-29 09:27:31 29[ENC] <177> received unknown vendor ID: e3:a5:96:6a:76:37:9f:e7:07:22:82:31:e5:ce:86:52
2021-04-29 09:27:31 29[IKE] <177> 80.xxx.xxx.xxx is initiating a Main Mode IKE_SA
2021-04-29 09:27:31 29[CFG] <177> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
2021-04-29 09:27:31 29[CFG] <177> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048
2021-04-29 09:27:31 29[IKE] <177> no proposal found
2021-04-29 09:27:31 29[ENC] <177> generating INFORMATIONAL_V1 request 2767287564 [ N(NO_PROP) ]
2021-04-29 09:27:31 29[NET] <177> sending packet: from yyy.yyy.yyy.254[500] to 80.xxx.xxx.xxx[500] (56 bytes)

The firewall on which the problem occurs is my firewall for the migration of my old UTM and unfortunately has only a base license at the moment, so I cannot open an official support case. Maybe someone in the community has a tip for me?

 

Thanks,

Ben



This thread was automatically locked due to age.