Having a weird issue with L2TP VPN I built on one of my mikrotiks and I’m not sure how to troubleshoot the issue.
VPN server - CCR
VPN Client - Another CCR at a remote locatoin.
The VPN works. I can connect to the VPN server via the client mikrotik, as well as a windows machine.
However, when the client mikortik tries to VPN into the server mikrotik, I get
On the client12:37:17 ipsec,debug pfkey add sent.
**On the server (IP removed by me)**12:37:53 l2tp,info first L2TP UDP packet received from XXX.XXX.XXX.XXX
And this just repeats over and over for about 5 minutes until it eventually connects.
Any ideas? It’s super aggravating, as the client side has a crummy ISP that microdrops, causing them to be unable to reach the server at HQ for 5-10 minutes while the MIkrotiks settle their argument.
Makes sense. I have about a dozen clients with the same VPN setup, but only this one has issues. The other clients are using fiber at all their locations, this one uses crummy copper wire megacorp cable.
Guess I’ll need to experiment with setting up an SSTP! I use PSK (I really need to use certs) currently.
I should know this, but SSTP, secure socket tunneling protocol, if it doesn’t use certs, how do they authenticate? Hopefully not use a username/password right?
You can use certs with SSTP between MT’s, but it is not required. My point was you can quickly test it without creating certs etc. if it works better, then implement with certs
Sorry for dragging some clouds to the clear sky, but VPNs using TCP as transport can cause more pain than help on lossy networks. The point is that if the payload protocol is also TCP, both the TCP layers do the retransmission - google for “TCP meltdown” for details. So in short-term you may have won, but in long-term you may encounter some hard to explain issues. Also for VoIP and other applications where loss of a packet now and then is less important than the delay caused by TCP retransmission, no VPN using TCP as transport is a good choice.
When the VPN transport doesn’t take care of the lost packets (like those using UDP, ESP, GRE as transport), it doesn’t interfere with the loss handling strategies of the payload applications.
So I’d rather get rid of the L2TP layer with its own negotiation and timeouts, and stick with IPsec alone or use IPsec to encrypt GRE which has no own negotiation. The easiest way to run another IPsec peer on the same address and port like the one used for encryption of L2TP is to use exchange-mode=ike2, which should also improve security a bit as compared to use of the IKE (v1).
There is not fix if you want to do L2TP, none that I found anyway. L2TP is great for users (laptops/remote desktops) needing to VPN, but not super solid for a site-to-site.
I ended up getting an OVPN (native to Mikrotiks, both server and client) setup with certificates, and the VPN connection between my two locations has an uptime of over two weeks.
So, your solution for a Site-to-Site VPN using two Mikrotiks is to use PPTP (fast, stable, not secure) or OVPN (fast, stable, secure) instead of L2TP (slowest option, not stable, super secure)
I really don’t agree with your statement that IPSEC/L2TP is nog solid. I have several IPSEC/L2TP site-to-site tunnels running for years without any problems at all.
It depends on what you call solidness and what are your requirements and network quality. L2TP sends an LCP EchoReq packet every 30 seconds and expects an EchoRep to come; if it doesn’t, it takes 4 more attempts 1 second apart and if it still doesn’t receive a response, it tears down the tunnel (and the client starts connecting again, which is seen as the L2TP UDP packet received from … message on the server). So if the loss rate of the connectivity between your sites can be very high for 6 consecutive seconds in at least one direction and the LCP EchoReq campaingn hits that very interval, this happens with L2TP, whereas with a VPN Protocol which uses TCP as transport (such as OpenVPN or SSTP) or which is not so sensitive about transport network quality (such as, probably, PPTP although I haven’t analysed its availability checking methods and their timeouts) may seem “solid” on the same quality of link. I’m not saying that TCP has no issues with a 6 seconds of total stop of transmission, I’m just saying that as the VPN uses TCP, it may not bother checking whether the other end is alive when it has no payload to send, relying on TCP to find out, and that if it is not a total stop but just a high loss rate (which can be caused by mere overload of the link), TCP may keep the connection up due to variable timeout between retransmissions.
So “solid” as in “I don’t panic if I cannot hear from the other end for quite a while” and “solid” as in “I constantly monitor the availability of the remote end and take measures to re-establish the connection if something went wrong” are different understandings of the word. On reliable enough transport network, no one cares about the meaning of “solid”; when the transport network randomly stops delivering packets for seconds, the difference becomes essential.
That said I have to return to my previous statement - use of TCP for tunneling another TCP causes little harm where the drop rate is low, but in such cases, UDP, ESP, or GRE as VPN transports also have no problems. Where drop rate is high, TCP over TCP causes a headache and may not be enough to save the situation.
So if your transport network is that bad but you have no other option, you have to experiment with various VPN types and find out which one suits your particular situation and needs best. Of course, any real-time transmission (such as VoIP) on a network that bad is something not to even dream of. But your network may actually not be that bad, it may just be that some of your traffic exhausts the available bandwidth of your last mile link because there is no QoS handling used.
This is a very informative answer that I will reference for the future.
The client side is located in a mall with a crummy ISP, but the only one that isn’t DSL. They’re not running VoIP, but they RDP into a Terminal server at the main site (maybe 3 miles away). I don’t like open RDP’s, and I was limited on software solutions due to client budget. So my compromise was to use their existing mikrotiks to establish a VPN so they can RDP via the TS’s local IP.
However, the client site has micro-outages with their ISP. Only for a few seconds, and it might be every 2 minutes, or every 2 hours. Long enough to break the L2TP tunnel, and they were down (unable to make sales) for about 2-3 minutes while the Mikrotik tried to rebuild the tunnel.
Both sides use a CCR. OVPN seems to be MUCH for fault tolerant.
In this situation I would use IKEv2 rather than L2TP/IPsec. With IPsec alone (without L2TP on top of it) you can choose the DPD interval and the agility of the reaction (how many DPD exchanges must fail to take measures). Between two Mikrotiks you can choose pre-shared key or cerficate authentication. Theoretically you could save even more bucks by using the Windows’ embedded VPN client instead of the client side Mikrotik, but I’ve found no other way to make it reconnect if it fails than a powershell script keeping an eye on the availability of the remote network, and I have no idea whether the DPD parameters can be configured there, so a small Tik box like hAP ac² is probably cheaper than the time spent fiddling with that on the Windows side even where it serves no other purpose at the client side.
I’ll have to play around with IKEv2 on my down time. I’m still learning, and have yet to do anything with it. I can setup a PPTP, L2TP w/ IPSec, and OVPN w/ certificates real easy, and only the latter two of the three are viable for 99% of situations.
I’m fairly young and new to the security side of things. I have a sec+ and try to learn, so your help is very beneficial. Thanks!