Recursive routing not working while using wireguard interface as gateway

RouterOS General
1

While using recursive routing in a different routing table than the main, if you use a recursive route over a wireguard tunnel it won’t work because nexthope can’t be calculated.

If you change the routing table of the routes to the main one it works as expected, so this seems to happend on tables different than the main one.
As an example, this would be the config on the routing table “spain”:

/ip/route> print detail where routing-table=spain
11  As   ;;; Check connectivity over gateway 1
    dst-address=8.8.4.4/32 routing-table=spain gateway=wireguard_interface immediate-gw=wireguard_interface distance=1 scope=10 target-scope=10 suppress-hw-offload=no
6  Is   ;;; Route if connectivity works over gateway 1
    dst-address=0.0.0.0/0 routing-table=spain gateway=8.8.4.4 immediate-gw="" check-gateway=ping distance=1 scope=30 target-scope=11 suppress-hw-offload=no

This doesn’t work, but if you change this routes to the main table, they will start working.

Mikrotik support tells me that recursive routing needs an IP gateway, but in wireguard, the concept of IP gateway does not apply. You have peers and you can route traffic to that peers, but you don’t use an IP to route traffic, you use the wireguard interface itself, and it will handle the routing with it’s peers. Could there be a way to make it work? If it works on main routing table it could be possible to make it work on other tables.

Finally made DUAL WAN work!
2

WireGuard’s “Cryptokey” routing differs from traditional IP routing. That said, you can treat the WG interface just like a regular Ethernet interface. Just give it an IP address like you would with any other network interface, and recursive routing will work the same way.

3

Yes, the wireguard interface has IP address, but recursive routing is only working on the main routing table. It doesn’t work on other routing tables.

4

You should put the route with dst-address=8.8.4.4/32 in the main table. The “spain” table should only have one route with dst-address=0.0.0.0/0 gateway=8.8.4.4 check-gateway=ping.

See this screenshot

route-test-6.png
from this post of mine yesterday http://forum.mikrotik.com/t/finally-made-dual-wan-work/182174/1

It’s also better to refer to the remote WireGuard peer that will do the routing to the internet with its IP address (as example 10.24.10.1 in the screenshot, instead of the interface name (wireguard2 in my example)).

5

That was the trick, I didn’t expect that. And it’s something that is not related with wireguard, right? It works with other regular interfaces. Thank you so much, I was looking for the problem where it wasn’t.

But actually, this would make that address to go through another interface that I don’t want in the main routing table. I will look for other IP address to make the test, that’s not a problem, but it’s there another way to do it? Just curious.

Regarding using the wireguard IP of the peer, the problem in this case is that I don’t know wich one is the address, so I have to use the interface instead.

6

I updated my post above with the link to my other post where you can see that it works not only with WG interfaces (that 10.24.10.1 gateway), but also with other type of interfaces.

7

I think this is the relevant section in the documentation:

https://help.mikrotik.com/docs/spaces/ROS/pages/59965508/Policy+Routing#PolicyRouting-RoutingTables

With this warning and excerpt:

For a user-created table to be able to resolve the destination, the main routing table should be able to resolve the destination too.

In our example, the main routing table should also have a route to destination 8.8.8.8 or at least a default route, since the default route is dynamically added by the DHCP for safety reasons it is better to add 8.8.8.8 also in the main table.

Unfortunately, I’ve tried giving canary destination 8.8.8.8 two different routes in the “main” and “TEST1” tables, but my test has shown that the route in the “main” table is preferred over the one in the same table:

route-test-8.png
Which means it’s not the solution for this issue of yours:

But actually, this would make that address to go through another interface that I don’t want in the main routing table.

8

Yes, it looks like the recursive route only uses the main routing table. Well, for checking internet connectivity is not a big deal as there are lots of IP to check with.

9

You need to add a routing rule to make sure traffic goes through the “TEST1” table instead of the “main” table. Just an example to illustrate: “/ip route rule add src-address=x.x.x.x/y action=lookup table=TEST1”. This ensures that routing follows the specified table for the given source address x.x.x.x/y.

Check out various routing rule matching options like dst-address, src-address, interface etc in Mikrotik ROS > Policy Routing > Routing Rules.

10

I am aware of it, the post from yesterday that I linked above has the routing rules http://forum.mikrotik.com/t/finally-made-dual-wan-work/182174/1 What I wanted to show here with the screenshots is only the behavior that when using recursive routing, the rule in the non-main table will expect the referenced gateway to have a route in the main table, and that route is preferred. In the screenshot above, the relevant route is for destination 8.8.8.8/32, not the route for destination 0.0.0.0/0 (that will be used together with routing & mangle rules).

11

It was meant for TheSantiagoSP, so no worries! :smiley:

12

Okay, since I am utterly confused with recursive anyway LOL.

Let me start by poopooing the concept of wireguard using recursive… Wireguard is NOT a normal interface…
The router has no clue if wireguard is up or down…and this has do to with the other end of the tunnel which you have no control over.
You can canary your own local WAN but thats about it.

So to have some context let me state
ISP1, ISP2 ECMP, vlan10 goes out ISP1, vlan20 goes out ISP2, vlan30 goes out third party WG.

According the wise CGGX, this solves everything but wireguard

**_/routing table
add fib name=useWAN1
add fib name=useWAN2
add fib name=useWG

/routing rule
add action=lookup-only-in-table min prefix=0 table=main comment=“ensure all local traffic is not captured by next rules”
add action=lookup src-address=vlan10-subnet table=useWAN1
add action=lookup src-address=vlan20-subnet table=useWAN2
add action=lookup src-address=vlan30-subnet table=useWG_**

Note: In the last routing rule above, we need to know if wireguard is up or down, as the admin, wants users to be able to use local WAN if wireguard is down, otherwise the extra wg route would not be required.

/ip route
add check-gateway=ping comment=“Main - ISP1” dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=main scope=10 target-scope=12
add comment=“Recursive - ISP1” dst-address=8.8.8.8/32 gateway=ISP1 Gateway routing-table=main scope=10 target-scope=11
+++++++++++++++++
add check-gateway=ping comment=“Main - ISP2” dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=main scope=10 target-scope=12
add comment=“Recursive - ISP2” dst-address=1.1.1.1/32 gateway=ISP2 Gateway routing-table=main scope=10 target-scope=11
++++++++++++++++
add check-gateway=ping dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=useWAN1 scope=10 target-scope=12 comment=“CGGX input”
add check-gateway=ping dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=useWAN2 scope=10 target-scope=12 comment=“CGGX input”

Note: My thinking is that there should be NO Need to check-gateway=ping as that is already done on the main table for that canary address!!! Can you test/confirm?

=====================================================================
Now for the wireguard routes!!!
Remember we already have a direct route created by the router due to IP address.
add dst-address=172.16.0.2/24 gateway=wireguard1 routing-table=main comment=“wg Ip address assigned by third party provider”

/ip route
add dst-address=0.0.0.0/0 gateway=wireguard1 routing-table=useWG comment=“used by routing rule to move vlan30 through this route”
add check-gateway=ping dst-address=172.16.0.1 gateway=wireguard1 routing-table=main comment=“router confirms wireguard is connected to thirdparty provider transparently through avail local WAN”

13

Since WireGuard doesn’t use a traditional IP gateway but rather peer connections, the routing table in non-main tables might not calculate the nexthop properly. A potential solution could involve using routing rules or static routes that reference the WireGuard interface directly in the “spain” table, or adjusting the way nexthop is evaluated in these non-main tables. A senior at my university recommended DoMyPaper when I was struggling to complete multiple essays on time. I checked their website domypaper.com here and found it user-friendly. I liked that they allow direct communication with writers and offer unlimited revisions. My first paper was well-written and delivered on time. Since then, I’ve used their service for different assignments, and the quality has always been top-notch. This website is a great help for students who need professional assistance.