L2TP/IPSEC issues with Windows 10

martinm · Mon Oct 18, 2021 12:55 am

Hi,

I'm tearing my hair out with a VPN issue. My VPN works with iOS/MacOS devices perfectly - no problems connecting to anything on the internal network. But I can't get it working with a Windows 10 client. Any suggestions gratefully received!

The client seems to successfully connect. It can resolve DNS names on the internal network configured under /ip dns static on the router, and can ping them successfully too. But any attempt at a TCP connection receives no response. I've reproduced this on multiple clients on both mobile and fixed (single-NAT) internet connections.

Relevant sections of my config are:

/ip pool
add name=vpn ranges=10.10.10.2-10.10.10.255
/ppp profile
add dns-server=10.10.10.1 local-address=10.10.10.1 name=L2TP only-one=no \
    remote-address=vpn
/interface l2tp-server server
set default-profile=L2TP enabled=yes ipsec-secret=\
    SomethingSecure max-mru=1460 max-mtu=1460 use-ipsec=yes
/ip firewall filter
...
add action=accept chain=input comment="Accept from VPN" log-prefix=acceptvpn \
    src-address=10.10.10.0/24
add action=accept chain=input comment="Accept L2TP" connection-state=new \
    dst-port=500,1701,4500 in-interface=pppoe-out1 log=yes log-prefix=\
    "fw accept l2tp" protocol=udp
add action=accept chain=input comment="Accept ipsec-esp" protocol=ipsec-esp
add action=accept chain=input comment="Accept ipsec-ah" in-interface-list=WAN \
    protocol=ipsec-ah
...
add action=accept chain=forward comment="Forward from VPN" log-prefix=\
    forwardvpn src-address=10.10.10.0/24
...
/ip firewall nat
...
add action=masquerade chain=srcnat comment="masq. vpn traffic" log-prefix=\
    vpnmasq src-address=10.10.10.0/24
...
/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
/ppp secret
add name=vpn password=SomethingElseSecure profile=L2TP

Logs are as follows (from a 4G dongle client connection, but iOS/MacOS fine in this scenario):

[22:32:28 ipsec,info respond new phase 1 (Identity Protection): 212.69.11.22[500]<=>92.40.33.44[11988] 
22:32:28 ipsec received MS NT5 ISAKMPOAKLEY ID version: 9 
22:32:28 ipsec received Vendor ID: RFC 3947 
22:32:28 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n 
22:32:28 ipsec received Vendor ID: FRAGMENTATION 
22:32:28 ipsec Fragmentation enabled 
22:32:28 ipsec 92.40.33.44 Selected NAT-T version: RFC 3947 
22:32:28 ipsec Adding xauth VID payload. 
22:32:28 ipsec sent phase1 packet 212.69.11.22[500]<=>92.40.33.44[11988] 732a4f9cf65235f9:3b533cf648815df4 
22:32:28 ipsec NAT detected: PEER 
22:32:28 firewall,info fw accept l2tp input: in:pppoe-out1 out:(unknown 0), src-mac 20:e0:9c:df:1b:4e, proto UDP, 92.40.33.44:11988->212.69.11.22:500, len 436 
22:32:28 ipsec Adding remote and local NAT-D payloads. 
22:32:28 ipsec sent phase1 packet 212.69.11.22[500]<=>92.40.33.44[11988] 732a4f9cf65235f9:3b533cf648815df4 
22:32:29 ipsec NAT-T: ports changed to: 92.40.33.44[40087]<=>212.69.11.22[4500] 
22:32:29 ipsec KA list add: 212.69.11.22[4500]->92.40.33.44[40087] 
22:32:29 ipsec,info ISAKMP-SA established 212.69.11.22[4500]-92.40.33.44[40087] spi:732a4f9cf65235f9:3b533cf648815df4 
22:32:29 ipsec respond new phase 2 negotiation: 212.69.11.22[4500]<=>92.40.33.44[40087] 
22:32:29 ipsec searching for policy for selector: 212.69.11.22:1701 ip-proto:17 <=> 92.40.33.44:1701 ip-proto:17 
22:32:29 ipsec generating policy 
22:32:29 ipsec Adjusting my encmode UDP-Transport->Transport 
22:32:29 ipsec Adjusting peer's encmode UDP-Transport(4)->Transport(2) 
22:32:29 ipsec sent phase2 packet 212.69.11.22[4500]<=>92.40.33.44[40087] 732a4f9cf65235f9:3b533cf648815df4:00000000 
22:32:29 ipsec IPsec-SA established: ESP/Transport 92.40.33.44[40087]->212.69.11.22[4500] spi=0x840ab0d 
22:32:29 ipsec IPsec-SA established: ESP/Transport 212.69.11.22[4500]->92.40.33.44[40087] spi=0x389325e2 
22:32:29 l2tp,info first L2TP UDP packet received from 92.40.33.44 
22:32:29 l2tp,ppp,info,account vpn logged in, 10.10.10.249 from 92.40.33.44 
22:32:29 l2tp,ppp,info <l2tp-vpn>: authenticated 
22:32:29 l2tp,ppp,info <l2tp-vpn>: connected

Cheers,

Martin

sindy · Mon Oct 18, 2021 11:03 am

Start by sniffing on the virtual l2tp-server interface corresponding to the Windows client (/tool sniffer quick interface=<l2tp-username> protocol=tcp), to see whether the SYN packets arrive from the Windows machine at all. Normally I would expect a firewall issue or a MTU handling issue. As you say you can ping the LAN hosts, it's not the most frequent case of the address pool for VPN clients overlapping with the LAN subnet.

martinm · Mon Oct 18, 2021 9:56 pm

Thanks very much for replying, really appreciated. I see quite a lot of activity when I kick off a connection and see traces like the below, which may start part way through an exchange as it scrolls scrolls off the console packet log quite quickly. I can't see the SYNs and ACKs explicitly but it looks like packets from 10.10.10.254 (client) are reaching 10.10.1.51 (server on my LAN) which is trying to respond.

I'd suspect a firewall issue except this all works for iOS/MacOS which would seem to rule out a firewall issue on the Mikrotik side. I've just tried turning off the Windows Defender firewall on the client and that makes no difference.

Cheers,

Martin

---

INTERFACE                  TIME    NUM DIR SRC-MAC           DST-MAC           VLAN   SRC-ADDRESS                         DST-ADDRESS                         PROTOCOL   SIZE CPU FP 
<l2tp-vpn>               14.028     27 <-                                             10.10.10.254:51365                  10.10.1.51:8006                     ip:tcp       52   0 no 
<l2tp-vpn>               14.037     28 <-                                             10.10.10.254:56219                  10.10.1.51:8006                     ip:tcp       52   0 no 
<l2tp-vpn>               14.052     29 ->                                             10.10.1.51:8006                     10.10.10.254:51365                  ip:tcp     1400   3 no 
<l2tp-vpn>               14.068     30 ->                                             10.10.1.51:8006                     10.10.10.254:56219                  ip:tcp     1400   2 no 
<l2tp-vpn>               14.332     31 ->                                             10.10.1.51:8006                     10.10.10.254:56219                  ip:tcp     1400   2 no 
<l2tp-vpn>               14.332     32 ->                                             10.10.1.51:8006                     10.10.10.254:51365                  ip:tcp     1400   3 no 
<l2tp-vpn>               14.876     33 ->                                             10.10.1.51:8006                     10.10.10.254:56219                  ip:tcp     1400   2 no 
<l2tp-vpn>                14.88     34 ->                                             10.10.1.51:8006                     10.10.10.254:51365                  ip:tcp     1400   3 no 
<l2tp-vpn>               14.979     35 <-                                             10.10.10.254:65215                  10.10.1.51:8006                     ip:tcp       40   0 no 
<l2tp-vpn>               15.154     36 <-                                             10.10.10.254:54776                  10.10.1.51:8006                     ip:tcp       40   0 no 
<l2tp-vpn>               15.932     37 ->                                             10.10.1.51:8006                     10.10.10.254:56219                  ip:tcp     1400   2 no 
<l2tp-vpn>               15.932     38 ->                                             10.10.1.51:8006                     10.10.10.254:51365                  ip:tcp     1400   3 no 
<l2tp-vpn>               17.362     39 <-                                             10.10.10.254:65215                  10.10.1.51:8006                     ip:tcp       40   0 no 
<l2tp-vpn>               17.382     40 <-                                             10.10.10.254:54776                  10.10.1.51:8006                     ip:tcp       40   0 no 
<l2tp-vpn>               18.076     41 ->                                             10.10.1.51:8006                     10.10.10.254:56219                  ip:tcp     1400   2 no 
<l2tp-vpn>               18.076     42 ->                                             10.10.1.51:8006                     10.10.10.254:51365                  ip:tcp     1400   3 no 
<l2tp-vpn>                18.96     43 ->                                             10.10.1.51:8006                     10.10.10.254:51365                  ip:tcp       40   3 no 
<l2tp-vpn>               18.982     44 ->                                             10.10.1.51:8006                     10.10.10.254:56219                  ip:tcp       40   2 no 
<l2tp-vpn>               19.029     45 <-                                             10.10.10.254:51365                  10.10.1.51:8006                     ip:tcp       52   0 no 
<l2tp-vpn>               19.041     46 <-                                             10.10.10.254:56219                  10.10.1.51:8006                     ip:tcp       52   0 no

sindy · Tue Oct 19, 2021 12:50 pm

I can't see the SYNs and ACKs explicitly but it looks like packets from 10.10.10.254 (client) are reaching 10.10.1.51 (server on my LAN) which is trying to respond.

To see the TCP layer flags, you have to stop the sniffer and then use tool sniffer packet print detail, but that's not the key here. Your sniff result shows that the TCP sessions did get past the initial (SYN>, <SYN+ACK, ACK>) exchange, as you can see 1400-byte packets to be sent from the LAN to the client.

Run Wireshark on the PC and try the same - maybe the payload packets encapsulated into the L2TP transport ones do not actually make it to the PC because there is some issue with encapsulating them into IPsec transport packets, or the IPsec transport packets have an issue to reach the PC. As ICMP packets and small TCP packets do get through, I'd assume some issue with packet fragmentation & reassembly.

So try to create a dedicated /ppp profile row for the Windows client and lower the max-mru and max-mtu values on that row to e.g. 1300.

Does the Windows client connect from the same LAN like the other clients that do not experience any trouble?

martinm · Wed Oct 20, 2021 12:29 am

Hi,

I have to confess I skipped over the WireShark stage and straight to changing the max-mtu and max-mru from 1460 to 1300 because it was so quick to try. I did this in "/interface l2tp-server server" as I couldn't see those options in "/ppp profile". Everything started working!

As 1300 is an arbitrary number and presumably higher is better, how should I work out the best value? Playing around unscientifically, things seem reliable up until around 1380. I did find the following suggesting that Windows may use a fixed MTU size of 1400 bytes for VPN connections, which seems a bit of a coincidence:

https://docs.microsoft.com/en-us/troubl ... connection

I'd rather not require registry changes on Windows clients - so is there much harm in leaving it at 1380 across the board? Anything else I should be doing to prevent fragmentation/reassembly problems? Or any way of using different values for different usernames/types of client? I really must remind myself how MRU and MTU work, it's been a while (as in about 2 decades) since I've been in the weeds of TCP/IP...

Happy to step back and do the Wireshark analysis if needed.

Again - thanks very much indeed!

Cheers,

Martin

L2TP/IPSEC issues with Windows 10

L2TP/IPSEC issues with Windows 10

Re: L2TP/IPSEC issues with Windows 10

Re: L2TP/IPSEC issues with Windows 10

Re: L2TP/IPSEC issues with Windows 10

Re: L2TP/IPSEC issues with Windows 10

Who is online