MikroTik

Hi team,

I couldn't understand how it's work?

I have routers (hardware and CHR)

I have backbone network on IPSec - GRE - OSPF in Main route table.

I have MPLS (VPLS) between their loopbacks.

All VPLS interfaces in difrent VRF.

I have loopbacks on routers in VRF too.

Please informed me, how can I manage with Winbox ( for example ) from VRF?

example.

CHR -

in main route table loopback (bridge) interface with IP - 10.10.10.1/32
in GREEN route table loopback (bridge) interface with ip 192.168.1.1/32

this loopbacks announcing in their OSPF instances.

I want from GREEN tables device open Winbox with 192.168.1.1 for example, what I should do?

AFAIK management not works in vrf. Only clients traffic.

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

I know

But maybe with Nat, Mangle Firewall rules I could do it?

Example:

1. in Mangle - Mark Connection - GREEN_MGNT -> Green VRF, dst IP - loopback, dst port - 8291
2. in Mangle - Mark Route to @main -> where Connection mark - GREEN_MGNT
3. in Nat - src-nat IP in @main out_int loopback -> where source ip - VRF GREEN management network (or another way)
4.....

in this case packets goes to @main for management, but needing return TCP packets back to GREEN VRF

Experts - have your any comments?

Hi,

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

/ip route rule add src-address=10.0.0.1/32 action=lookup table=Green

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!

Greetings

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.

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.

Code: Select all

/ip firewall address-list
  add address=10.0.0.0/8 list=local
  add address=172.16.0.0/12 list=local
  add address=192.168.0.0/16 list=local
/ip firewall mangle
  add action=mark-connection chain=prerouting comment=\
    "Policy based routing - MPLS - from 'local' address list to router's IP:" connection-mark=no-mark \
    connection-state=new dst-address-type=local new-connection-mark=mpls passthrough=yes src-address-list=local
  add action=mark-routing chain=output connection-mark=mpls dst-address-list=local new-routing-mark=mpls passthrough=no
/ip firewall nat
  add action=dst-nat chain=dstnat comment="Redirect - Management connections from within VRF:" connection-mark=mpls to-addresses=192.168.254.1

Awesome. Thank you!

Added src-address-type=local to the second mangle rule.

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.