Hi All,
I have read the threads on these two subjects which I couldn't see a definitive answer for. I apologise in advance for merging the two issues into the same thread, there is a reason for doing so which will become clear.
Coming from a Cisco/Juniper environment we can configure the device in such a way as we have a management VRF & do not manage the device on the same public IP network that is routing customer traffic, this avoids worrying about some elements of the control plane which may be subject to attack by traditional vectors. In RouterOS we cannot do this and must access an IP in the "main" routing table in order to manage the device.
This brings me to my second hurdle. The L2TP server should reply to the client using the address the L2TP client targetted, if you configure say 4 Loopback on a Cisco or Juniper and the device is running L2TP, and you tried to fire up an L2TP session to each of these 4 loopback, it would work just fine as the Cisco/Juniper would reply from the same IP you fired the session towards. RouterOS will not reply from any Loopback and instead replies from the interface IP associated to the default gateway interface regardless of what IP the client targets, or even what table the request came in on.
This mean RouterOS can not act as a true LNS or LAC/LNS switch in a service provider environment where a number of carriers are involved and we must reply from specific addresses in order to have a bidirectional L2TP tunnel form. (I'm pretty sure this is part of the L2TP RFC). There appears to be no way to specify a source IP against the L2TP server or place any constraints that I am familar with using vpdn-groups on a Cisco. (Eg vpdn-group 1, terminate from hostname blah, use this template, reply from this source IP etc.) RouterOS L2TP appears to be very immature in its development.
Curiously enough, the L2TP server will answer inside a VRF, but still throw back the IP of the interface facing the gateway in the main table which again I can't see how that could be acceptable under the RFC as the IP it is sending the frame from isn't even in the VRF routing table so it's effectively spoofing packets from one table to another.
Furthermore, by RouterOS replying to the L2TP request inside the VRF, this allows any VRF customer which are intended to be in private IP space to interact with the L2TP server inside their VRF, despite the fact that RouterOS would never be able to fire up a session because it doesn't reply form the IP inside the VRF? (DoS anyone?) .. What's worse is there appears to be no way to turn off L2TP from listening inside the VRF aswell as public, even though it doesn't work in a VRF anyway. Given the whole point of a VRF is that it is a private routing table, the customer should never be able to hit my Router and talk to it's daemons. that's just crazy talk.
Here I am hitting the RouterOS L2TP on a IP that is inside a VRF and seeing replies inside the VRF with the source IP of the main table interface IP facing the default gateway
03:24:35 l2tp,debug,packet sent control message to 192.168.1.254:1701
03:24:35 l2tp,debug,packet (M) Message-Type=SCCRQ
03:24:35 l2tp,debug,packet rcvd control message from 210.9.189.x:1701
03:24:35 l2tp,debug,packet (M) Message-Type=SCCRP
03:24:35 l2tp,debug received SCCRP before SCCRQ, rejecting
03:24:35 l2tp,debug,packet sent control message to 210.9.189.x:1701
03:24:35 l2tp,debug,packet (M) Message-Type=StopCCN
Am looking for a definitive answer as to if and when Mikrotik will come to the party on these things, if at all and how others are accommodating for these deficiencies.