You can do some very hack-ish trick with mangle rules to get it to work. Unfortunately thats how I have to do it, but Mikrotik has stated numerous times in the forums that this will likely not be a feature in RouterOS v6, which is upsetting. It would be nice to have vrf aware services like aaa (tacacs please), syslog, ntp, winbox, ssh etc. But until then play with the mangle rules, it is possible I promise
This problem can be solved easily. But it is important to understand where the problem arises from:
Assuming a VRF Green with e.g. bridge-interface IP 10.0.0.1/24 or a loopback interface with ip 10.0.0.1/32
Your Winbox traffic enters the VRF Green via an associated interface. The ip-packets with destination 10.0.0.1 are traveling through the
INPUT-chain and the ROS responses accordingly BUT BUT BUT the response packets are traveling through the OUTPUT-chain and will be routed in the table main, and only table main.
So, the communication will not be not established. The good thing is, your VFR Green clients cannot gain access to the router, the bad thing is you also cannot gain access, as you are considered as VFR Green client. (But MAC Telnet is still working: Try in Winbox IP/Neighbors and select your router, click MAC Telnet and login into the CLI)
On IP Layer we need to map the router traffic back into VRF Green. One simple solution is a routing rule. I use this in my large SOHO-Network
That´s all. This rule assures that the response traffic is resolved/routed in table VFR Green and no longer in table main. If you like, you may restrict client access by firewall rules in the INPUT-chain or use Port Knocking techniques. Other solutions are now very clear: static routes, connection-mark and routing-mark and so and so on. But dont forget that in most cases matching “routing-mark=Green” is required in such rules. The advantage of the simple routing rule is that your host may have ip-address from any subnet, because it does not appear in the rule.
Make sure that VFR Green has routes back to your host, enter static routes or use OSPF running in VFR Green by selecting Routing-Table=Green in the OSPF Instance definition!
We work with this the other way around, management via main routing table and customer traffic in VRFs. We drink our own Kool-Aid though, so our own offices have routers where our traffic is in a VRF and we subsequently didn’t have access to routers from within our own network.
The following rules essentially mark new connections arriving from rfc1918 sources (address list ‘local’), towards any IP local to the router (dst-address-type=local (NOT the address list)) and then NATs those connections to the loopback IP in the main routing table (192.168.254.1). The result is that one can then connect to any of the router’s IP addresses from within a VRF.
The VRF is called ‘mpls’ in this example, output mangle rule essentially marks routing for packets associated with a connection mark of ‘mpls’ to the VRF routing table.
The normal approach is to run the management in the “main” table or “backbone”. With that said I know Cisco has the possibility to bind some management services in a separate VRF instance.