Should I consider a port knock on prior to allowing a VPN connection?

Then allow that IP address via a firewall filter input rule access to Winbox port 8291.

Should I consider a port knock on prior to allowing a VPN connection?

That's not needed. L2TP+IPSec will be secure enough.

Then allow that IP address via a firewall filter input rule access to Winbox port 8291.

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?

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

Evening,

Im to accomplish exactly this, is there any example of what the firewall rules should look like?

Karel

in case clients are behind the NAT, which most likely is the case, because otherwise there's no real point to use L2TP at all.

in case clients are behind the NAT, which most likely is the case, because otherwise there's no real point to use L2TP at all.

Can you be more verbose regarding this thought, please?

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.

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.

so opening the 4500 port is enough, no need to open both 4500 and 500.

so opening the 4500 port is enough, no need to open both 4500 and 500.

Прошу прощения, но 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.