386.4 Static Route stopped working.

[DTM]

I am running an RT-AC88U and decided to update from 386.1.2 to 386.4. All seemed to be working well when I discovered I could not reach a router in my network that provides a gateway to another network. I have a static route defined that sends traffic from 10.0.0.0 (255.0.0.0) to an address on my LAN (192.168.1.23). This has worked fine for a couple of years now. After confirming the other network was up and running but unreachable by computers on my 192.168.1.0/24 network I decided to revert back to 386.1.2. Without changing anything setting wise 386.1.2 again worked perfectly with the static route. So I am back to 386.1.2 for now.

Is there something special I need to do with 386.4 and static routes? I did try turning the router's firewall off temporarily, but it did not change anything.

 

[eibgrad]

Dump the routing table and confirm if the routing is as expected.

ip route show table main

 

[DTM]

10.0.0.0/8 via 192.168.1.23 dev br0 metric 1

This is what it shows now while running 386.1.2

 

[eibgrad]

10.0.0.0/8 via 192.168.1.23 dev br0 metric 1

This is what it shows now while running 386.1.2

I assumed as much, since it's working. I'm interested if that changed w/ 386.4. Whether it's even there, or if perhaps something else in the table is causing it to be ignored. There's little we can do to debug it if you remain on the prior firmware.

 

[DTM]

ASUSWRT-Merlin RT-AC88U 386.4_0 Sat Jan 1 18:42:21 UTC 2022
admin@RT-AC88U-07B8:/tmp/home/root# ip route show table main
104.58.148.1 dev eth0 proto kernel scope link
1.1.1.1 via 104.58.148.1 dev eth0 metric 1
10.165.6.73 via 104.58.148.1 dev eth0 metric 1
10.8.3.0/24 dev tun11 proto kernel scope link src 10.8.3.6
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
104.58.148.0/22 dev eth0 proto kernel scope link src 104.58.151.86
10.0.0.0/8 via 192.168.1.23 dev br0 metric 1
127.0.0.0/8 dev lo scope link
default via 104.58.148.1 dev eth0

I just put 386.4 back on it. The full dump is above. Presently my other network is again unreachable.

 

[DTM]

10.165.6.73 is the address of my other router??? I note that is via an address similar to my ISP WAN address 104.58.151.86. I confess I don't understand a lot of what this means. I can reach 10.165.6.73 running 386.1.2 but not on 386.4.

 

[eibgrad]

Well one of problems I see is that you're using OpenVPN client, and the tunnel established (tun11) lies within the scope of that static route. So at least when it comes to 10.8.3.0/24, that's going to be routed over the VPN, NOT via the static route. In general, this is the kind of thing you want to avoid.

Another problem too is that when using routing policy, clients that are bound to that VPN use a different routing table (ovpnc1), and that probably doesn't contain the 10.0.0.0/8 route. IIRC, Merlin changed 386.4 to remove static routes.

ip route show table ovpnc1

If that's the case, then you would need to add a rule to bind that network back (as the remote IP) to the WAN's routing table (Iface).

 

[DTM]

admin@RT-AC88U-07B8:/tmp/home/root# ip route show table ovpnc1
104.58.148.1 dev eth0 proto kernel scope link
194.233.98.63 via 104.58.148.1 dev eth0
1.1.1.1 via 104.58.148.1 dev eth0 metric 1
10.165.6.73 via 104.58.148.1 dev eth0 metric 1
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.8.0.0/24 dev tun11 proto kernel scope link src 10.8.0.5
104.58.148.0/22 dev eth0 proto kernel scope link src 104.58.151.86
10.0.0.0/8 via 192.168.1.23 dev br0 metric 1
127.0.0.0/8 dev lo scope link
default via 10.8.0.1 dev tun11
====
The above is the dump of that command. I just turned the vpn off and still cannot reach the other network but I think I have discovered part of the problem. 10.165.6.73 is also the DNS server for the other network. I had it listed under the WAN section as the secondary DNS. If I remove it from there I can indeed reach the router at 10.165.6.73. Problem is, when I do I can't browse to sites that require DNS lookups on that network. The network is an amateur radio data network and requires its own DNS server.

 

[DTM]

Well by moving the 10.165.6.73 DNS to the LAN it appears that I have everything working again. Dumping the route table gave me some insight into the problem. Apparently, something changed between 1.2 and 4 with the way the DNS is handled.

THANK YOU for the help!!!!!!!