FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
+1 vote
1,026 views 7 comments
by anonymous
Hi all,

I am moving a bunch of Teltonika's from OpenVPN to Wireguard. The Teltonika's are connected to another router via the WAN port and the WAN interface has an IP in the 192.168.10.x range. They also have a backup SIM card in case the main network fails.

I noticed the weirdest behaviour when adding a Wireguard endpoint; a static route is added for the Wireguard server public IP that forces all Wireguard traffic to route via the 4G connection;

# ip route
default via 192.168.10.1 dev eth1
default dev wwan0  scope link  metric 10
[some 4G IP] dev wwan0  proto static  scope link  metric 10
[WG server IP] dev wwan0  proto static  scope link  metric 10  <---- this one
172.21.0.0/16 dev wg_ses  proto static  scope link
172.23.0.0/16 dev wg_ses  proto static  scope link
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1
192.168.10.0/24 dev eth1  proto kernel  scope link  src 192.168.10.105

I don't want this route! It's making the wireguard connection super slow and also costs a lot in 4G traffic. The SIM card is only there as a backup.

Why is this route added? How do I disable this behaviour?

1 Answer

0 votes
by anonymous

Hello,

I would like you to attach a complete troubleshoot file to your question to review your configuration details. Please, replicate the issue, then access router's WebUI, go to System -> Administration -> Troubleshoot section and download troubleshoot file from there. 

Attached files are only visible to Teltonika moderators.

Best regards,

by anonymous
File is attached.

Note that this problem occurs on EVERY SINGLE Teltonika I set up with Wireguard. This is not a one-off. If you want more dumps from other Teltonikas, I can provide them.
by anonymous

Do all your devices have RUT2XX_R_00.01.13.3 firmware installed?

Could you try updating one of your device's firmware version to the latest RUT2_R_00.07.03.1 with Keep settings option set to off, reconfigure your device, and, if the issue persists, attach a new file generated from the updated device?

by anonymous
Upgrading the devices without keeping the settings was not an option, since most of these are hundreds of miles away from me somewhere in the field... and also not in one place.

I did do the firmware upgrade with "keep settings" on and on MOST devices that fixed the problem; the route is no longer there. On 5 of them, though, it persisted. I am still trying to find out why. I've attached the troubleshoot file of one of them, maybe there's something there. I'm also digging through the device settings and comparing it with other devices.
by anonymous
Did a bunch of tests and research and cannot figure out why this route persists on these 5 devices.

I did find the culprit; in the /etc/hotplug.d/iface/18-wireguard, the route is added towards the bottom;

[ "$ACTION" = "ifup" ] && {
        [ -n "$gw" ] && ip route add "$peer" via "$gw" dev "$DEVICE" metric "$metric" || ip route add "$peer" dev "$DEVICE" metric "$metric"
        echo "ip route del "$peer" dev "$DEVICE" metric $metric" >> "/tmp/wireguard/default-status"
}
 

Why this triggers for these 5 devices and not for others is something I don't understand; the configs are all the same and they all have this script. Can someone shed some light on this? And maybe explain WHY this route is added?
by anonymous

In the troubleshoot file provided, there is failover enabled for both mobile and wired interfaces. However, no wired connection is available during file generation, but mobile connection is up. 

Also, in your Wireguard peer configuration, you have Route allowed IPs option enabled, which generates the aforementioned route:

  • [WG server IP] dev wwan0 proto static scope link metric 10

Upon restoring the wired communication, route with Wireguard server's IP would be generated over eth1 as gateway.

You can remove undesired route with SSH command:

  • ip route del [WG server IP] dev wwan0

Otherwise, disable Route allowed IPs option.

Best regards,

  

by anonymous

route allowed IPs created routes for the IP range on the wireguard network, not to the wireguard peer, so that has nothing to do with this.

I know how to delete the route, the problem is that it is regenerated each time the failover occurs, or when the device reboots.

I did some more experiments and here are my findings;
I have both WAN and the mobile connection set as failover. When the device boots, I have these routes;

default via 192.168.180.1 dev eth0.2 proto static src 192.168.180.125 metric 1
default dev wwan0 proto static scope link src 10.6.17.167 metric 2
[mobile IP] dev wwan0 proto static scope link metric 2
[wg peer IP] via 192.168.180.1 dev eth0.2 proto static metric 1
172.21.0.0/16 dev wg_ses proto static scope link
172.23.0.0/16 dev wg_ses proto static scope link
192.168.1.0/24 dev br-lan proto static scope link metric 1
192.168.180.0/24 dev eth0.2 proto static scope link metric 

This is all fine. The route for the peer IP is weird, since it should just use the default route, but ok.
If I then unplug the WAN cable, it changes the routes, including the WG route to this;

default dev wwan0 proto static scope link src 10.6.17.167 metric 2
[mobile IP] dev wwan0 proto static scope link metric 2
[wg peer IP] dev wwan0 proto static scope link metric 2
172.21.0.0/16 dev wg_ses proto static scope link
172.23.0.0/16 dev wg_ses proto static scope link
192.168.1.0/24 dev br-lan proto static scope link metric 1

This is also fine! The peer IP route is still not doing anything in particular, but it's ok.
Finally if I plug the cable back into the WAN port, I end up with these routes;

default via 192.168.180.1 dev eth0.2 proto static src 192.168.180.125 metric 1
default dev wwan0 proto static scope link src 10.6.17.167 metric 2
[mobile IP] dev wwan0 proto static scope link metric 2
[wg peer IP] dev wwan0 proto static scope link metric 2
172.21.0.0/16 dev wg_ses proto static scope link
172.23.0.0/16 dev wg_ses proto static scope link
192.168.1.0/24 dev br-lan proto static scope link metric 1
192.168.180.0/24 dev eth0.2 proto static scope link metric 1

As you can see, the default route via WAN is back and all traffic routes via that unless it goes to the internal network. The route to the wireguard peer REMAINS and all WG traffic is routed via the mobile connection until I reset the device.

This is a problem. Either the route needs to switch back - which it doesn't - or it should not be there at all and simply use the default route and everything would be fine.

I have no idea why this happens, or where. I found that script mentioned earlier and it appears to be part of the wireguard package.

How can I avoid this route being created, or force it to switch back?

by anonymous
Any resolution for this?  I seem to have the same issue on a brand new device with the latest firmware loaded before any changes were made.