Static IPv4 route not showing up in routing table

I added the following static route config:

config route
	option target ''
	option netmask ''
	option table 'main'
	option onlink '1'
	option interface 'wg0'

However, the route is not showing up in the routing table. Using this command works:

ip route add dev wg0 proto static scope link

Any idea why it does not work with UCI? Already tried rebooting, using another interface (just to test it), another table, ... Looks like it randomly works sometimes, but doesn't most of the time. Also cannot find an error in the system log.

I doubt you want this for a Wireguard link. Remove it.

This is generally used for encapsulations where a "gateway" config would be the Layer 3 endpoint to reach that subnet (e.g. with IPENCAP/IP Protocol No. 4). In some, protocols it has another meaning. Obviously, such is not used in Wireguard and it should be omitted.

Before trying to manually add the static route, I checked what OpenWrt does when ticking the Route Allowed IPs box. The output of ip route list contains e.g.: dev wg0 proto static scope link

I thought to have the scope link part in a static route, I would have to add option onlink '1'. So this is not what it is doing?

Anyway, I also tried adding the static route without option onlink '1', but the route still does not show up in the routing table. IPv6 static routes do work. Any ideas about this? Is this a known bug?

The standard method being unreliable possibly due to some sort of race condition that is usually not easy to troubleshoot, so try use options allowed_ips and route_allowed_ips in the WG-peer section.

1 Like

'link' != 'onlink'

Can you show your configs please?

No, there's no known bugs. I use routes with onlink 0 and 1 all the time.

IPv6 routes???

(I'm starting to think maybe you're having an issue with the syntax...routing is a pretty basic function.)

:bulb: Also, are you actually rebooting or reloading the network config???

/etc/init.d/network reload

Also, confirm you're not editing the WG interface simetaneously.

I got a similar issue when I tried to let an IP address bypass the default VPN routing rules.

The route add command did work, but the rules added in LuCI didn't, which is also equal to writing configurations in /etc/config/network.

The most wired thing was that the route command didn't show any rules in LuCI at all. It meant that the rules added in LuCI did not generate a corresponding rule for the routing table after I clicked Save & Apply. Then I checked the official document on setting up static routes, and I was sure there were no mistakes.

After many attempts of different option combinations, I finally found that it would work if I gave METRIC a whatever number. Although it is not a mandatory option, as long as I left METRIC blank, the rule would not show up in the routing table and, of course, won't work.

Luckily I found this trick, but I don't know why this happened. Or maybe it's a bug or something. I hope somebody can explain it to me.

An update:

Things seem to become more complex after I try it several times again.
Whether the rule will show up in the routing table is becoming more unpredictable.

Look at the results of a setting sequence:
Metric = blank, fail
Metric = 0, fail
Metric = 1, fail
Metric = 2, work
Metric = 3, work
Metric = 2, work
Metric = 1, work
Metric = 0, work
Metric = blank, fail
Metric = 0, fail
Metric = 1, fail
Metric = 2, work

Static IPv4 route not showing up in routing table - #4 by vgaetera

What is the best way to manually create routing table and a rule to match?
Wiki suggest ip [1] [2] but it seems to cause issue.

It works for me pretty well on the current stable release.
Make sure to use UCI for better integration with netifd.

1 Like