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.
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).
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.
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.
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!!!