Possible issue: WireGuard IP remains in tables 51, 52 even after tunnel is closed

MT-3000, stock install, 4.1.2 December 5 firmware:

Route table 52 before bringing up WireGuard:

(LAN IP range 10.72.0.0/18, MT-3000 IP 10.72.34.141)

default via 10.72.0.1 dev apclix0 proto static src 10.72.34.141 metric 20
10.72.0.0/18 dev apclix0 proto static scope link metric 20
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1

Route table 52 after bringing up WireGuard:

default via 10.72.0.1 dev apclix0 proto static src 10.72.34.141 metric 20
10.72.0.0/18 dev apclix0 proto static scope link metric 20
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
W.X.Y.Z via 10.72.0.1 dev apclix0 proto static metric 20

Where W.X.Y.Z is the IP address of the WireGuard server.

After disconnecting the WireGuard client from the VPN Dashboard, W.X.Y.Z remains in route table 52. (And table 51, FWIW).

To be fair this looks like it may also be an issue in OpenWrt main, since my fresh compile on an a1300 does something different but similar - in that case it stays in the main route table, but is not in table 52.

You’re doing all the debugging for us. Sounds like you got a very early unit. You’re lucky :+1::+1::+1:

I’ve had mine a couple of weeks. Not doing anything too special, just using it more or less like I’d use a travel router, though minus the VPN (connected wirelessly to my access point, a few clients on the MT3000). I do turn the VPN on occasionally to make sure it works.

I feel like my use case is somewhat different than a lot of people here who run these as their primary routers, but who knows.

I would definitely be interested in testing the Tailscale functionality if there is an early build of that (@alzhao)!

1 Like