VRF routing and Portforwarding between VRF's

RouterOS Forwarding Protocols
1

Hello Mikrotik Fourms,

I hope this is the correct catagory for this question I am about to ask. If not please tell me and I will move it.

At this moment we use a RB1100AH to NAT and port forward multiple customer VRF’s. This is no problem for external people to connect via the portforwards from the external IP address. EG ip address 1.1.1.1 port 25 to customer A VRF 192.168.0.1 server.

However if customer B’s (who is also on the same router) VRF internally tries to go to 1.1.1.1 port 25, we see no response to this port.

I will attach the configuration we have below, but if anyone could help us with this it would be greatly appreciated.

/interface vlan
add arp=enabled disabled=no interface=ether1 mtu=1500 name=internet use-service-tag=no vlan-id=500
add arp=enabled disabled=no interface=ether1 mtu=1500 name=Customer-A-Ethernet use-service-tag=no vlan-id=599
add arp=enabled disabled=no interface=ether1 mtu=1500 name=Customer-A-colo use-service-tag=no vlan-id=598
add arp=enabled disabled=no interface=ether1 mtu=1500 name=managerment use-service-tag=no vlan-id=501

/ip address
add address=172.17.100.254/24 disabled=no interface=managerment network=172.17.100.0
add address=192.168.10.254/24 disabled=no interface=Customer-A-colo network=192.168.10.0
add address=1.1.1.66/30 disabled=no interface=internet network=1.1.1.64
add address=1.1.1.68/32 disabled=no interface=bridge-external network=1.1.1.68
add address=1.1.1.18/32 disabled=no interface=bridge-external network=1.1.1.64
add address=172.16.252.1/30 disabled=no interface=Customer-A-Ethernet network=172.16.252.0

/ip firewall mangle
add action=mark-routing chain=prerouting comment=“Customer-A-Mangle” disabled=no dst-address=1.1.1.68 new-routing-mark=Customer-A passthrough=yes
add action=mark-routing chain=prerouting comment=Customer-B-Internal disabled=no dst-address=1.1.1.66 in-interface=internet new-routing-mark=Customer-B-internal passthrough=yes

/ip firewall nat
add action=src-nat chain=srcnat disabled=no out-interface=internet routing-mark=Customer-A to-addresses=1.1.1.68
add action=src-nat chain=srcnat disabled=no out-interface=internet routing-mark=Customer-B-internal to-addresses=1.1.1.66
add action=jump chain=dstnat disabled=no jump-target=Customer-A-dstnat routing-mark=Customer-A
add action=jump chain=dstnat disabled=no jump-target=Customer-B-internal-dstnat routing-mark=Customer-B-internal
add action=dst-nat chain=Customer-A-dstnat disabled=no dst-address=1.1.1.68 dst-port=25 protocol=tcp to-addresses=192.168.10.1
add action=dst-nat chain=Customer-A-dstnat disabled=no dst-address=1.1.1.68 dst-port=3389 protocol=tcp to-addresses=192.168.10.1


/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=1.1.1.65@main routing-mark=Customer-A scope=30 target-scope=10
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=1.1.1.65@main routing-mark=Customer-B-internal scope=30 target-scope=10
add disabled=no distance=1 dst-address=10.0.0.0/8 gateway=ECN routing-mark=Customer-B-internal scope=30 target-scope=10
add disabled=no distance=1 dst-address=172.16.0.0/12 gateway=ECN routing-mark=Customer-B-internal scope=30 target-scope=10
add disabled=no distance=1 dst-address=192.168.0.0/16 gateway=ECN routing-mark=Customer-B-internal scope=30 target-scope=10
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=1.1.1.65 scope=30 target-scope=10

/ip route vrf
add disabled=no export-route-targets=1.1.1.68:111 import-route-targets=1.1.1.68:111 interfaces=Customer-A-Ethernet,Customer-A-colo route-distinguisher=1.1.1.68:111 routing-mark=Customer-A
add disabled=no export-route-targets=1.1.1.64:111 import-route-targets=1.1.1.64:111 interfaces=managerment,ECN route-distinguisher=1.1.1.64:111 routing-mark=Customer-B-internal

2

Any thoughts guys?

3

Did you figure this out?

4

You’re probably going to need to also masquerade the traffic inward after it hits the pinhole, or else src-nat each user’s public IP specifically.

Basically, if you do the dst-nat but no src-nat, then the internal IP space of user A is being leaked into user B’s network, and the user B routing table may not contain a network matching user B’s src IP. (You should NEVER leak B’s routing table into A - this breaks the entire reason for VRF)

So src-nat to a public IP for the user is the best solution but might require many rules if you have many public IPs.
If you don’t have a need for the users’ servers to be able to see the actual src IP (for logging, perhaps?) then just masquerade such requests to the router’s internal IP of the destination VRF.

5

Hi, we’re having the same problem.
Did you solve it?

6

Im keen to understand this better as well as we are having the same issue…any thoughts anyone?

7

As it turns out, this isnt possible…in my view, a bug, or oversight on Mikrotiks part for not implementing.