Cannot connect from Windows Server 2019

[ptrcnull]

Client is Windows Server 2019 (1809 b. 17763.1098), with both registry patches (AssumeUDPEncapsulation... and ProhibitIpSec) applied.

All other clients like Windows 10, Windows 7, macOS 10.13, Manjaro Linux and Android 10 work just fine

Symptoms are the same as with unsupported kernel, but I've updated both xl2tpd and the kernel (to 4.19) and the issue persists.

vpn    | Redirecting to: /etc/init.d/ipsec start
vpn    | Starting pluto IKE daemon for IPsec: .
vpn    | xl2tpd[1]: Not looking for kernel SAref support.
vpn    | xl2tpd[1]: Using l2tp kernel support.
vpn    | xl2tpd[1]: xl2tpd version xl2tpd-1.3.12 started on hostname.domain.tld PID:1
vpn    | xl2tpd[1]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
vpn    | xl2tpd[1]: Forked by Scott Balmos and David Stipp, (C) 2001
vpn    | xl2tpd[1]: Inherited by Jeff McAdams, (C) 2002
vpn    | xl2tpd[1]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
vpn    | xl2tpd[1]: Listening on IP address 0.0.0.0, port 1701
vpn    | xl2tpd[1]: control_finish: Peer requested tunnel 1 twice, ignoring second one.
vpn    | xl2tpd[1]: control_finish: Peer requested tunnel 1 twice, ignoring second one.
vpn    | xl2tpd[1]: control_finish: Peer requested tunnel 1 twice, ignoring second one.
vpn    | xl2tpd[1]: control_finish: Peer requested tunnel 1 twice, ignoring second one.
vpn    | xl2tpd[1]: control_finish: Peer requested tunnel 1 twice, ignoring second one.
vpn    | xl2tpd[1]: Maximum retries exceeded for tunnel 51631.  Closing.
vpn    | xl2tpd[1]: Connection 1 closed to ***.***.***.***, port 1701 (Timeout)
vpn    | xl2tpd[1]: Unable to deliver closing message for tunnel 51631. Destroying anyway.

[ptrcnull]

Update: it might be an issue on my network, because Windows Server is a virtual machine on KVM (tested both routed setup and NAT, same thing), but a Linux VM doesn't work either...

Here's a screenshot of a pcap dump recorded on the server, blue is the server, pink is the client:

Looks like the server isn't responding to the client, I guess..?

[hwdsl2]

@ptrcnull Hello! This does look like a network issue. Did you reboot your Windows Server after applying the fix for Windows error 809 [1]? Please also check the Libreswan (IPsec) logs for errors [2] after trying to re-connect.

[1] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#windows-error-809 [2] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#check-logs-and-vpn-status

[ptrcnull]

Yes, I've rebooted the Windows Server. Libreswan logs:

# grep pluto /var/log/auth.log
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: responding to Main Mode from unknown peer <client ip>:500
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: Oakley Transform [AES_CBC (256), HMAC_SHA1, DH20] refused
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, DH19] refused
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: STATE_MAIN_R1: sent MR1, expecting MI2
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: STATE_MAIN_R2: sent MR2, expecting MI3
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: Peer ID is ID_IPV4_ADDR: '<client ip>'
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA1 group=MODP2048}
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: Configured DPD (RFC 3706) support not enabled because remote peer did not advertise DPD support
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: the peer proposed: <server ip>/32:17/1701 -> <client ip>/32:17/0
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: NAT-Traversal: received 2 NAT-OA. Using first; ignoring others
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #2: responding to Quick Mode proposal {msgid:00000001}
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #2:     us: <server ip>:17/1701
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #2:   them: <client ip>:17/1701
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 transport mode {ESP/NAT=>0x289f07d6 <0xf79fb918 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=<client ip> NATD=<client ip>:4500 DPD=unsupported}
Jun 17 16:33:01 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x289f07d6 <0xf79fb918 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=<client ip> NATD=<client ip>:4500 DPD=unsupported}
Jun 17 16:33:36 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: received Delete SA(0x289f07d6) payload: deleting IPsec State #2
Jun 17 16:33:36 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #2: deleting other state #2 (STATE_QUICK_R2) aged 35.029s and sending notification
Jun 17 16:33:36 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #2: ESP traffic information: in=642B out=0B
Jun 17 16:33:36 hotaru pluto[1841]: "l2tp-psk"[1] <client ip> #1: deleting state (STATE_MAIN_R3) aged 35.063s and sending notification
Jun 17 16:33:36 hotaru pluto[1841]: "l2tp-psk"[1] <client ip>: deleting connection "l2tp-psk"[1] <client ip> instance with peer <client ip> {isakmp=#0/ipsec=#0}

[hwdsl2]

@ptrcnull Thanks for the update. From the logs, we see that the VPN connection was successfully established, but disconnects after 35 seconds. As you mentioned, this is most likely an issue with your virtual machine's network, not caused by the VPN server itself.