Community discussions

MikroTik App
 
dannosky123
just joined
Topic Author
Posts: 5
Joined: Tue Oct 30, 2018 5:36 pm
Location: Iowa

Windows VPN

Wed Nov 16, 2022 11:35 pm

I manage a customer's network, including their MikroTik RB1100AHx2, running 6.48.6, and I've recently had two end users experience problems VPN'ing into this network. Each user can VPN in from one work location but cannot get into the same VPN at a different location (SOHO). The only common denominator for both users is they are accessing the same Mikrotik and they are both using the Windows VPN client. Otherwise, their home and remote offices are different, their computers are different, and their VPN accounts are different. Both end users have also tried PPTP and L2TP VPNs with the same end result.

I'd be happy to provide router configuration specifics. I'm just not sure what would be needed at this point.

Thanks in advance!

Dan
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Windows VPN

Thu Nov 17, 2022 12:46 am

Maybe you should start from explaining what "cannot get into the same VPN" means in detail. It can be anything from getting no response at all through authenticating but immediately disconnecting to connecting successfully but not being able to exchange data with the private network.

Since you say the same happens regardless the type of VPN used (L2TP, PPTP, and the basic one is?), one thing to come to my mind is a collision between the IP address assigned by the Mikrotik and the IP subnet those PCs are connected in when this happens. E.g. if the PC gets an address 192.168.1.x/24 from the local DHCP server, and then another 192.168.1.y from the Mikrotik via VPN, this may make it terminate the VPN connection. But that's just a wild guess.

The log on the Mikrotik should tell you more - e.g. /system logging add topics=l2tp will enable debug messages for L2TP to be logged, and /log print follow-only where topics~"l2tp" will show them as they will be written. You cannot choose only log messages from a particular client to be shown so it would be good to ask the affected clients to try to connect at a time when only a few other clients would be connecting/disconnecting.

Loosely related, please stop using PPTP. It has not been considered secure since long ago (and it has issues with NAT).
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2855
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: Windows VPN

Thu Nov 17, 2022 9:04 am

Are you sure that VPN traffic is not blocked at ISP level?
 
dannosky123
just joined
Topic Author
Posts: 5
Joined: Tue Oct 30, 2018 5:36 pm
Location: Iowa

Re: Windows VPN

Thu Nov 17, 2022 6:48 pm

Maybe you should start from explaining what "cannot get into the same VPN" means in detail. It can be anything from getting no response at all through authenticating but immediately disconnecting to connecting successfully but not being able to exchange data with the private network.

Since you say the same happens regardless the type of VPN used (L2TP, PPTP, and the basic one is?), one thing to come to my mind is a collision between the IP address assigned by the Mikrotik and the IP subnet those PCs are connected in when this happens. E.g. if the PC gets an address 192.168.1.x/24 from the local DHCP server, and then another 192.168.1.y from the Mikrotik via VPN, this may make it terminate the VPN connection. But that's just a wild guess.

The log on the Mikrotik should tell you more - e.g. /system logging add topics=l2tp will enable debug messages for L2TP to be logged, and /log print follow-only where topics~"l2tp" will show them as they will be written. You cannot choose only log messages from a particular client to be shown so it would be good to ask the affected clients to try to connect at a time when only a few other clients would be connecting/disconnecting.

Loosely related, please stop using PPTP. It has not been considered secure since long ago (and it has issues with NAT).
Thank you for your reply!

Both end users cannot connect to the VPN. I see the connection attempts on the MikroTik but I don't understand the logs. The end user is getting an error that states: "The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g., firewalls, NAT, routers, etc) between your computer and the remote server is not configured to allow VPN connections."

This end user can connect to a different customer's MikroTik L2TP VPN from his home office with no issue.

Here is a portion of the log file:

Nov/17/2022 10:21:43 ipsec,debug KA: 192.168.170.245[4500]->END-USER-PUBLIC-IP[40086]
Nov/17/2022 10:21:43 ipsec,debug 1 times of 1 bytes message will be sent to END-USER-PUBLIC-IP[40086]
Nov/17/2022 10:21:43 ipsec,debug,packet ff
Nov/17/2022 10:21:47 ipsec,debug ===== received 76 bytes from END-USER-PUBLIC-IP[40086] to 192.168.170.245[4500]
Nov/17/2022 10:21:47 ipsec,debug,packet e0921645 7535261c de5b0579 9df616a6 08100501 030d993b 0000004c cce7eee6
Nov/17/2022 10:21:47 ipsec,debug,packet 7abd85b3 af581e33 c7ae2b22 77bec42f 1cf9a3a3 91157288 d208fe04 76872404
Nov/17/2022 10:21:47 ipsec,debug,packet 9c30fae1 7219b42e 6b3f20dd
Nov/17/2022 10:21:47 ipsec,debug receive Information.
Nov/17/2022 10:21:47 ipsec,debug,packet compute IV for phase2
Nov/17/2022 10:21:47 ipsec,debug,packet phase1 last IV:
Nov/17/2022 10:21:47 ipsec,debug,packet 94544ac1 5df39a76 030d993b
Nov/17/2022 10:21:47 ipsec,debug hash(sha1)
Nov/17/2022 10:21:47 ipsec,debug,packet encryption(3des)
Nov/17/2022 10:21:47 ipsec,debug,packet phase2 IV computed:
Nov/17/2022 10:21:47 ipsec,debug,packet 425b5b9b 16b67aac
Nov/17/2022 10:21:47 ipsec,debug,packet encryption(3des)
Nov/17/2022 10:21:47 ipsec,debug,packet IV was saved for next processing:
Nov/17/2022 10:21:47 ipsec,debug,packet 7219b42e 6b3f20dd
Nov/17/2022 10:21:47 ipsec,debug,packet encryption(3des)
Nov/17/2022 10:21:47 ipsec,debug,packet with key:
Nov/17/2022 10:21:47 ipsec,debug,packet 3113c404 63a29e8f 3fe1fb10 be86772a 275db959 931c9b94
Nov/17/2022 10:21:47 ipsec,debug,packet decrypted payload by IV:
Nov/17/2022 10:21:47 ipsec,debug,packet 425b5b9b 16b67aac
Nov/17/2022 10:21:47 ipsec,debug,packet decrypted payload, but not trimed.
Nov/17/2022 10:21:47 ipsec,debug,packet 0c000018 736bc59f 965382b3 acc60478 7cd4a6f5 5b90475c 00000010 00000001
Nov/17/2022 10:21:47 ipsec,debug,packet 03040001 e2069574 00000000 00000000
Nov/17/2022 10:21:47 ipsec,debug,packet padding len=1
Nov/17/2022 10:21:47 ipsec,debug,packet skip to trim padding.
Nov/17/2022 10:21:47 ipsec,debug,packet decrypted.
Nov/17/2022 10:21:47 ipsec,debug,packet e0921645 7535261c de5b0579 9df616a6 08100501 030d993b 0000004c 0c000018
Nov/17/2022 10:21:47 ipsec,debug,packet 736bc59f 965382b3 acc60478 7cd4a6f5 5b90475c 00000010 00000001 03040001
Nov/17/2022 10:21:47 ipsec,debug,packet e2069574 00000000 00000000
Nov/17/2022 10:21:47 ipsec,debug,packet HASH with:
Nov/17/2022 10:21:47 ipsec,debug,packet 030d993b 00000010 00000001 03040001 e2069574
Nov/17/2022 10:21:47 ipsec,debug,packet hmac(hmac_sha1)
Nov/17/2022 10:21:47 ipsec,debug,packet HASH computed:
Nov/17/2022 10:21:47 ipsec,debug,packet 736bc59f 965382b3 acc60478 7cd4a6f5 5b90475c
Nov/17/2022 10:21:47 ipsec,debug hash validated.
Nov/17/2022 10:21:47 ipsec,debug begin.
Nov/17/2022 10:21:47 ipsec,debug seen nptype=8(hash) len=24
Nov/17/2022 10:21:47 ipsec,debug seen nptype=12(delete) len=16
Nov/17/2022 10:21:47 ipsec,debug succeed.
Nov/17/2022 10:21:47 ipsec,debug END-USER-PUBLIC-IP delete payload for protocol ESP
Nov/17/2022 10:21:47 ipsec purged IPsec-SA proto_id=ESP spi=0xe2069574
Nov/17/2022 10:21:47 ipsec purged IPsec-SA proto_id=ESP spi=0x7117a80
Nov/17/2022 10:21:47 ipsec removing generated policy
Nov/17/2022 10:21:47 ipsec,debug purged SAs.
Nov/17/2022 10:21:47 ipsec,debug ===== received 84 bytes from END-USER-PUBLIC-IP[40086] to 192.168.170.245[4500]
Nov/17/2022 10:21:47 ipsec,debug,packet e0921645 7535261c de5b0579 9df616a6 08100501 445ca0c7 00000054 4128e6dc
Nov/17/2022 10:21:47 ipsec,debug,packet f6c030e3 6e560784 bd0bbb46 1d85ca99 a054e5e0 97f2c464 018b0035 50090df6
Nov/17/2022 10:21:47 ipsec,debug,packet fd12e7d3 c478a45f aa65c07e 11d89764 911e7f04
Nov/17/2022 10:21:47 ipsec,debug receive Information.
Nov/17/2022 10:21:47 ipsec,debug,packet compute IV for phase2
Nov/17/2022 10:21:47 ipsec,debug,packet phase1 last IV:
Nov/17/2022 10:21:47 ipsec,debug,packet 94544ac1 5df39a76 445ca0c7
Nov/17/2022 10:21:47 ipsec,debug hash(sha1)
Nov/17/2022 10:21:47 ipsec,debug,packet encryption(3des)
Nov/17/2022 10:21:47 ipsec,debug,packet phase2 IV computed:
Nov/17/2022 10:21:47 ipsec,debug,packet 56b7801f ed6edda2
Nov/17/2022 10:21:47 ipsec,debug,packet encryption(3des)
Nov/17/2022 10:21:47 ipsec,debug,packet IV was saved for next processing:
Nov/17/2022 10:21:47 ipsec,debug,packet 11d89764 911e7f04
Nov/17/2022 10:21:47 ipsec,debug,packet encryption(3des)
Nov/17/2022 10:21:47 ipsec,debug,packet with key:
Nov/17/2022 10:21:47 ipsec,debug,packet 3113c404 63a29e8f 3fe1fb10 be86772a 275db959 931c9b94
Nov/17/2022 10:21:47 ipsec,debug,packet decrypted payload by IV:
Nov/17/2022 10:21:47 ipsec,debug,packet 56b7801f ed6edda2
Nov/17/2022 10:21:47 ipsec,debug,packet decrypted payload, but not trimed.
Nov/17/2022 10:21:47 ipsec,debug,packet 0c000018 b7626d9b c6bdebc1 25d3fc6b 5183378e ae2a4011 0000001c 00000001
Nov/17/2022 10:21:47 ipsec,debug,packet 01100001 e0921645 7535261c de5b0579 9df616a6 00000000
Nov/17/2022 10:21:47 ipsec,debug,packet padding len=1
Nov/17/2022 10:21:47 ipsec,debug,packet skip to trim padding.
Nov/17/2022 10:21:47 ipsec,debug,packet decrypted.
Nov/17/2022 10:21:47 ipsec,debug,packet e0921645 7535261c de5b0579 9df616a6 08100501 445ca0c7 00000054 0c000018
Nov/17/2022 10:21:47 ipsec,debug,packet b7626d9b c6bdebc1 25d3fc6b 5183378e ae2a4011 0000001c 00000001 01100001
Nov/17/2022 10:21:47 ipsec,debug,packet e0921645 7535261c de5b0579 9df616a6 00000000
Nov/17/2022 10:21:47 ipsec,debug,packet HASH with:
Nov/17/2022 10:21:47 ipsec,debug,packet 445ca0c7 0000001c 00000001 01100001 e0921645 7535261c de5b0579 9df616a6
Nov/17/2022 10:21:47 ipsec,debug,packet hmac(hmac_sha1)
Nov/17/2022 10:21:47 ipsec,debug,packet HASH computed:
Nov/17/2022 10:21:47 ipsec,debug,packet b7626d9b c6bdebc1 25d3fc6b 5183378e ae2a4011
Nov/17/2022 10:21:47 ipsec,debug hash validated.
Nov/17/2022 10:21:47 ipsec,debug begin.
Nov/17/2022 10:21:47 ipsec,debug seen nptype=8(hash) len=24
Nov/17/2022 10:21:47 ipsec,debug seen nptype=12(delete) len=28
Nov/17/2022 10:21:47 ipsec,debug succeed.
Nov/17/2022 10:21:47 ipsec,debug END-USER-PUBLIC-IP delete payload for protocol ISAKMP
Nov/17/2022 10:21:47 ipsec,info purging ISAKMP-SA 192.168.170.245[4500]<=>END-USER-PUBLIC-IP[40086] spi=e09216457535261c:de5b05799df616a6.
Nov/17/2022 10:21:47 ipsec purged ISAKMP-SA 192.168.170.245[4500]<=>END-USER-PUBLIC-IP[40086] spi=e09216457535261c:de5b05799df616a6.
Nov/17/2022 10:21:47 ipsec,debug purged SAs.
Nov/17/2022 10:21:47 ipsec,info ISAKMP-SA deleted 192.168.170.245[4500]-END-USER-PUBLIC-IP[40086] spi:e09216457535261c:de5b05799df616a6 rekey:1
Nov/17/2022 10:21:47 ipsec KA remove: 192.168.170.245[4500]->END-USER-PUBLIC-IP[40086]
Nov/17/2022 10:21:47 ipsec,debug KA tree dump: 192.168.170.245[4500]->END-USER-PUBLIC-IP[40086] (in_use=1)
Nov/17/2022 10:21:47 ipsec,debug KA removing this one...


Again, thank you!!!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Windows VPN

Thu Nov 17, 2022 7:15 pm

I would prefer a log from the very beginning - let things "cool down" for at least 15 minutes, then start logging into a separate file using /log print follow-only file=vpn-start where topics~"ipsec|l2tp", and then let the client make a single connection attempt).

But before actually doing that: the log shows that the Mikrotik receives the incoming connection attempts on a private address, which either means that there is a NAT between the Mikrotik and the internet, or that there is a dst-nat rule on the Mikrotik itself. In any case, by default, Windows clients do not tolerate server-side NAT.

This can be changed by allowing server-side NAT in Windows registry, or there is another approach: to put the public IP up also on the Mikrotik as a /32 one, e.g. on a port-less bridge, and "un-dst-nat" the port-forwarded incoming requests back to that public address. Doing so makes the client happy, but there is a minor catch - if a client itself happens to use a public IP, the IPsec stacks of the initiator (client) and responder (server) doesn't find out that there actually is a NAT somewhere on the network path, and would use bare ESP to transport the encrypted payload. This may or may not be a problem, depending on whether the NAT device between the Mikrotik and the internet can forward ESP to Mikrotik's WAN address.

If L2TP/IPsec is your primary VPN, there is an additional issue you may or may not hit - multiple clients connecting from behind the same public IP. It also has a solution, but it is a bit complex.
 
dannosky123
just joined
Topic Author
Posts: 5
Joined: Tue Oct 30, 2018 5:36 pm
Location: Iowa

Re: Windows VPN

Fri Nov 18, 2022 8:30 pm

Sindy,

There are several NAT rules on this router but I noticed that LAN IP in the VPN logs as well. I did the registry hack you mentioned, setting the AssumeUDPEncapsulationContextOnSendRule registry value to "2" and that fixed the problem!

Thank you so much for your help on this. I owe you several beers!!!!!

Who is online

Users browsing this forum: Ahrefs [Bot], alotofbacardi, baragoon, GoogleOther [Bot], Pincha3, SpOuK3 and 94 guests