Invalid extra static route for wireguard server

I’m bumping on the same issue as mentioned here:

teltonika sometimes creates a spurious static router to the wireguard server
root@teltonika-13:~# ip r
default dev qmimux0 proto static scope link src 10.226.208.93 metric 2
default via 10.19.141.1 dev br-lan proto static metric 4
10.19.0.0/17 dev wg0 proto static scope link
x.x.x.x via 10.19.141.1 dev br-lan metric 4

Clearly routing via the br-lan interface will not work and make the device unreachable for us, except using rms. After rebooting with sms, generally the device was reachable for about a day, to be unavailable again after approximately 24 hours.

running ip r -d x.x.x.x via 10.19.141.1 fixed wireguard immediately

Actually, apart from the fact that this should not be generated (default route is good), the additional weird thing is that there is a default route via br-lan (not br-wan). This route is not configured anywhere in the failover.

I was able to fix the latter in uci. Strange that this was not visible anywhere in the UI. Not sure how it ended up there:

uci delete network.lan.gateway

This still does not explain why extra routes are generated. They should just follow the default route.

Because the logic regarding the DEFAULT_ROUTE variable in wireguard.sh is wrong. See this issue. Add a “option nohostroute ‘1’” line in the config as described to get rid of it.

1 Like

This topic was automatically closed after 15 days. New replies are no longer allowed.