Just looking for confirmation and/or recommendations to further harden.
For remote access, I am planning on using a L2TP/IPSec VPN connection. I am planning on giving the admin VPN user a specific IP address say 192.168.88.5. Then allow that IP address via a firewall filter input rule access to Winbox port 8291. Am I missing anything? Should I consider a port knock on prior to allowing a VPN connection?
Any recommendations welcome.
That’s not needed. L2TP+IPSec will be secure enough.
Or you can allow access from the l2tp-in interface created for that user instead.
Thank you for this - are you saying add the user to an interface list? It looks like you can specify an interface list in the profile. I would need to create different VPN profiles as opposed to default. Do i have that right?
You can create “L2TP Server Binding” interfaces for every user, that needs to be static. And then use these interfaces in interface lists, firewall, etc.
Also you can use “all ppp” option in firewall’s in-interface/out-interface matchers.
No need for different profiles: one profile - multiple secrets (users).
L2TP Server Binding is tied to the particular secret (user).
The server interface binding is a straightforward concept but it can be used only with L2TP; the addition of the dynamically created interface to the interface list specified in the /ppp profile can be used with any PPP-based protocol, i.e. also SSTP, PPPoE, OVPN…
Ah - got it. Thanks.
Evening,
Im to accomplish exactly this, is there any example of what the firewall rules should look like?
Karel
For l2TP+IPSec these ports have to be open:
Can you be more verbose regarding this thought, please?
Clients, that can benefit from dial-in behaviour: PCs, phones, other personal devices are always behind at least one layer of NAT.
For sure I can imagine use cases for l2tp between two devices with public addresses too, but these are scenarios where building a symmetrical tunnel is impossible for some reason.
OK, but what you write is relevant for L2TP without IPsec, because it is the only one of “only tunneling” (i.e. without encryption) protocols which can traverse NAT nicely (leaving pptp aside because only one PPTP client of a given server can connect from behind each public IP). Once you add IPsec into the picture, you don’t need L2TP to traverse the NAT any more, because IPsec can take care about it itself, so you can have IPIP, GRE, EoIP between a client behind a NAT and the VPN server. For all the gadgets you have listed (where IPIP, GRE, EoIP are unlikely to be supported), IKEv2 can be used without wasting part of the MTU for the L2TP encapsulation. And L2TP, the way it has been glued with IPsec (i.e. using transport mode of the SA), suffers from the same issue like PPTP - only one client of a given server can be connected from behind the same public IP. This limitation doesn’t exist for L2TP without IPsec, and doesn’t exist for IPsec without L2TP 
So all in all, I do not see the need to traverse NAT as a reason to use L2TP/IPsec.
Ok, I never wrote that the point of L2TP+IPSec is to traverse NAT, I simply stated, that if somebody is going to use L2TP+IPSec most likely it will be used by clients from behind the NAT, so opening the 4500 port is enough, no need to open both 4500 and 500. That’s all 
Прошу прощения, но leaving aside my understanding of your “otherwise there’s no real point to use L2TP at all”, the above statement is simply wrong. You are perfectly right that an IKEv2 responder MUST always listen on 4500, and thus an IKEv2 initiator may initiate connections directly towards responder’s port 4500 (which RouterOS actually does), but L2TP comes bundled with IKE(v1), and there the initiator always contacts the responder at port 500 so the responder MUST listen there. The IKE(v1) session only migrates to port 4500 if the NAT-T extension finds out that the NAT is there.
Yes, my mistake.
You are right, как всегда.
I think, last few times I configured L2TP server, the rule for 500 port was already in place for other types of tunnels, so it slipped my mind.