<a name="p-1211380-edit-nevermind-while-i-still-dont-understand-why-this-route-was-unreachable-everything-stops-working-when-both-sides-are-in-an-vrf-vrfs-are-really-the-biggest-whack-a-mole-ever-what-i-am-actually-trying-to-so-is-same-as-described-in-this-questionhttpsforummikrotikcomtaccessing-router-hosted-services-dns-http-etc-from-a-vrf172411-1" class="anchor" href="#p-1211380-edit-nevermind-while-i-still-dont-understand-why-this-route-was-unreachable-everything-stops-working-when-both-sides-are-in-an-vrf-vrfs-are-really-the-biggest-whack-a-mole-ever-what-i-am-actually-trying-to-so-is-same-as-described-in-this-questionhttpsforummikrotikcomtaccessing-router-hosted-services-dns-http-etc-from-a-vrf172411-1" aria-label="Heading link"> EDIT: Nevermind, while I still don't understand why this route was unreachable everything stops working when both sides are in an VRF. VRFs are really the biggest whack-a-mole ever. What I am actually trying to so is same as described in this question . <a name="p-1211380-edit2-solution-to-this-particular-question-httpsforummikrotikcomt7-23-1-resolvable-route-is-unreachable-did-i-find-a-bug-or-doing-something-wrong2716246-turns-out-i-also-tried-that-already-but-what-the-issue-is-that-the-vrf-has-to-be-specified-even-if-its-to-be-resolved-in-the-same-vrf-i-was-using-the-target-vrf-not-the-source-vrf-2" class="anchor" href="#p-1211380-edit2-solution-to-this-particular-question-httpsforummikrotikcomt7-23-1-resolvable-route-is-unreachable-did-i-find-a-bug-or-doing-something-wrong2716246-turns-out-i-also-tried-that-already-but-what-the-issue-is-that-the-vrf-has-to-be-specified-even-if-its-to-be-resolved-in-the-same-vrf-i-was-using-the-target-vrf-not-the-source-vrf-2" aria-label="Heading link"> EDIT2: Solution to this particular question: 7.…

Much thanks for the Nevermind at the top! Saved some angst! I have not used VRFs yet, and if nothing else this thread has motivated me to "stay the course" LOL.

[image] anav: I have not used VRFs yet, and if nothing else this thread has motivated me to "stay the course" LOL. You are becoming very selective with age ... ... no CapsMan/Caps ... no VRFs

I still want to try for the ultimate most seemless failover on using wireguard and two ISPs, and VPS using BGP and OSPF, but I keep seeing fixes for that functionality so I will wait till its stable LOL.

I've posted an example configuration in the other thread, where it's possible to access the router's services in @main from other VRFs: [image] Accessing router-hosted services (DNS, HTTP, etc) from a VRF General Based on the tunnel idea from this thread , here…

[image] divB: Now I want to do the opposite as well: DNS is part of main VRF but should also be available from vlan55 (which is part of vrf-as): /ip route add distance=1 dst-address=10.2.79.2/32 gateway=172.18.1.20 routing-table=vrf-as scope=30 target-scope=10 Here 10.2.79.2 is RouterOS's own …

Nice to show it but why not add an explanation of a. how mt allows one to add "happy endings" to things. b. what it says if reading it, and also the functionality it applies.

I consider @ to mean "at" :wink: : Address@VRF: Tells the router which routing table to look at to find the path. and % to mean "through" : Address%Interface: Tells the router which physical/virtual pipe to go through.

When no @xxx is added to the gateway, it's assumed to be @main. So [image] divB: /ip route add distance=1 dst-address=10.2.79.2/32 gateway=172.18.1.20 routing-table=vrf-as scope=30 target-scope=10 means: in the routing table vrf-as destinations 10.2.79.2/32 can reach the gateway by resolving…

EDIT: Whops for some reason I never got a notification for the other thread and did not see your answer . As I describe in this post below, I think this works much simpler, without macvlan interfaces. [image] CGGXANNX: The reason why this route is unreachable is because you forgot to include @vr…

Yes, the MACVLAN "tunnel" workaround was intended for the situation when one of the two sides of the communication is a router's local address in main and the other side is in a different VRF, because accessing the local address in main has always been special (in the routing lookup decision this is…

7.23.1 Resolvable route is unreachable. Did I find a bug or doing something wrong?

RouterOS General

CGGXANNX July 17, 2026, 11:49am 5

I've posted an example configuration in the other thread, where it's possible to access the router's services in @main from other VRFs: