It is always a misconception that you can’t access services (management services like HTTP, WinBox or SNMP, and end-user services like SMB or DNS) from a VRF on RouterOS 6.x. In fact, you can, and here’s how you can achieve it.
The Theory
No service (except ICMP echo, if you count it as a service) on RouterOS 6.x is VRF aware. That means, the service daemons do listen on all the IPs on all the VRFs, but when they send a reply packet, the packet is only routed using the main (global) routing table. Depending on your routing table setup, the reply packet may or may not be routed to the client.
To solve this problem, we simply leverage the connection tracking capability of iptables: let it remember which VRF the packet is coming from, then identify the reply packets of the same session and route them back using the correct routing table. This creates a symmetric packet flow similar to the default reverse route mode on the Juniper SRX.
The Configuration
First of all, delete all FastTrack rules (rules with the “fasttrack connection” action) from your firewall. The VRF on the RouterOS 6.x depends on every packet going through all the firewall rules, so if you have fasttrack rules, VRF itself won’t work at all.
Enable connection tracking:
1 |
/ip firewall connection tracking set enabled=yes |
Disable RP filter (uRPF):
1 |
/ip settings set rp-filter=no |
For every VRF that you want devices to access ports on the router, create an interface list to match all the interfaces you assigned to that VRF:
1 2 3 4 5 |
/interface list add name=vrf-client /interface list member add interface=vlan100 list=vrf-client add interface=vlan200 list=vrf-client |
For every VRF that you want devices to access ports on the router, create a pair of mangle rules:
1 2 3 |
/ip firewall mangle add action=mark-connection chain=input connection-mark=no-mark in-interface-list=vrf-client new-connection-mark=vrf-client passthrough=yes add action=mark-routing chain=output connection-mark=vrf-client new-routing-mark=vrf-client passthrough=yes |
(Put these rules on the top of the mangle table before your other rules. Don’t modify the connection mark and the routing mark of these connections further.)
Now you should have no problem accessing the ports on the router from that VRF.
Notes
Using VRF on RouterOS 6.x require disabling FastTrack which comes with some performance penalty. Connection tracking (enabled on factory settings) affects device performance too. Depending on your device and your use case, you might not want to use VRF.
You only need to do this for VRFs with connected routes (i.e. ones that you have interfaces assigned to it). If you have VRFs used for creating routing table views and all packets are steered to it with rules, and it doesn’t have interfaces directly assigned to it, then you don’t need to set the mangle rules for it. The reason for this is trivial and is left as an exercise to the readers.
Every time when you change the VRF’s assigned interfaces, remember to update the interface list as well!
One caveat: MAC Telnet and MAC WinBox protocol is not a layer 2 protocol, it runs on layer 3 (IP broadcast), so it will be affected by VRF. If you don’t apply the settings above and add a port into a VRF, MAC Telnet and MAC WinBox will be inaccessible from that port. On the contrary, RoMON is pure layer 2 so it is not affected by VRF. If you cannot connect to the router after setting up VRF, try use another MikroTik router (or the free RouterOS VM) and connect with RoMON (if you have set up RoMON on the victim beforehand).