I’ve been using L2TP VPN to connect to my network from my phone for quite a long time now. Since VPN’s and encryption is sort of black magic to me, in the sense that a lot of people are using it, but only a select few actually understand how it works, I used some guide when I set it up. Everything has worked fine, but I can’t be 100% sure my configuration is safe, since I don’t actually understand how it works. Since there are more than one way to configure L2TP/IPsec in RouterOS, I’ve tried to learn a bit more about this, since I’m now setting it up on my new hEX.
There are of course a few YT videos on the subject and in one of the not particularly good ones, it is set up with the “Use IPsec” shortcut in the “L2TP Server” dialog box and thus (if I understand it correctly) generating dynamic configurations in the IPsec settings. To me it looks like it’s set up with encryption, but yet two of the comments suggests that this approach is unsafe. Is this a safe way or not and can someone point me to an up-to-date guide how to set this up safely?
Link to the video in question: https://www.youtube.com/watch?v=QOGiMDSv3nE
Thank you!
I generally don’t like shouts in the dark “it’s A” or “it’s not A” without stating a reason.
So first, let’s assume that L2TP encrypted using an IPsec security association established using IKE(v1) with a pre-shared key is secure enough.
In this case, the biggest danger is that the embedded VPN client on Windows may be configured to just “prefer” encryption, rather than “require” it, which means that if the IPsec SA does not establish for any reason, it connects using plain L2TP which has no own encryption by design (because it relies on the one provided by IPsec). When you configure the /interface l2tp-server server, you can set use-ipsec to required, but the manual says: When required is selected, server will accept only those L2TP connection attempts that were encapsulated in the IPSec tunnel. This sounds to me as if the already established L2TP connection continues without encryption should the IPsec SA break. Hence I prefer to add an /ip ipsec policy row action=drop protocol=udp src-port=1701 src-address=x.x.x.x as the last (bottom-most) one, where x.x.x.x is the IP address of the WAN interface; this policy ensures that L2TP traffic which doesn’t match any dynamically created policy will be dropped. However, this cannot prevent the remote device from sending the L2TP traffic if the security association breaks, so some plaintext information can still be sniffed by a man in the middle until the remote device gives up.
Except that the only way to tell the L2TP server itself to ignore incoming connections which do not come via an IPsec SA is to set use-ipsec to required, there is no other difference between the dynamically created IPsec configuration for L2TP and a manually created one. In manually created configuration, the same effect with the same limitation (i.e. affecting only the initiation of the L2TP connection) can be provided by a firewall rule that only accepts incoming connections to UDP port 1701 if they come via an IPsec SA; the /ip ipsec policy row mentioned above works better than such a rule because it also covers the case of SA failure.
Second, let’s assume that the above solution is not secure enough, due to some weakness of IKE(v1) with authentication using a pre-shared key or due to the possible SA failure scenario described above. In that case, the highest degree of security you can currently get is to use bare IKEv2 with a certificate. In this mode, the packets sent if the SA fails should not get too far as they likely have a private destination address (but that doesn’t mean they get nowhere at all), and certificate-based authentication should be more secure than a pre-shared key based one. The drawback is that at the moment, you can only use a machine certificate on Windows, and that the embedded VPN client of Android doesn’t support this type of VPN. I have no idea whether iOS/macOS support it. Other positives, on top of security, are that RouterOS can push a routing table to the Windows client - the method of doing this that Windows accept is currently not supported for any other VPN type.
Thank you very much for taking the time to write this rather thorough explanation! Cleared things up a bit:) After reading your reply I went for the more user-friendly setup in the “L2TP Server” dialog box, instead of my old “manual” configuration. Everything works fine and the performance with the new router is amazing!