UDP not good for unstable links, maybe try a TCP based site to site VPN, i.e. SSTP bwteen MT's, don't need certs in this case

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

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

For people of the future googling this issue.

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 not solid. I have several IPSEC/L2TP site-to-site tunnels running for years without any problems at all.

I really don't agree with your statement that IPSEC/L2TP is not 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.

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.

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.