Static routes set up with luci don't reflect in routing table

Hi, I've been trying to work this out for many hours now, reading all kinds of posts and possible solutions, but I just can't get it to work.

I have two routers R1 and R2, connected to an unmanaged switch S1, and R1 is then connected to another router which provides internet access.
I wanted R1 to be the default gateway for R2. R1 is in the 192.168.1.0/24 subnet and it's a DHCP server for devices starting from .100 (limit 150), while R2 is in the 192.168.2.0/24 subnet (with same configs for DHCP).
Therefore, I set the wan interface in R2 that's connected to R1, as a static address on 192.168.1.3 with 255.255.255.0 mask and 192.168.1.1 as a gateway. 192.168.1.1 also serves as a DNS server in this interface.
By default, the OpenWrt firewall has masquerading enabled, so with this setup I'm able to successfully connect to the Internet and to devices inside the 192.168.1.0/24 subnet. But I also wanted to be able to access the 192.168.2.0/24 subnet from R1. As I'm using masquerading, I'm only able to access R2 from R1 through 192.168.1.3.
So I thought I just needed to set up a static route from R1 to R2, as R1 didn't know how to reach the R2's subnet. Adding the route like this in R1 (through ssh) just works:

ip route add 192.168.2.0/24 via 192.168.1.3

But as I understand, this change isn't permanent, so I have several ways I can do it: Set it up through the web interface (luci), using uci through the CLI, or directly modifying the /etc/config/network file.
Though, even after rebooting, none of these methods seem to work, as the route seems to be missing when checking with ip route:

default via 192.168.0.1 dev wan  src 192.168.0.10 
192.168.0.0/24 dev wan scope link  src 192.168.0.10 
192.168.1.0/24 dev br-lan scope link  src 192.168.1.1 

I'm using OpenWrt 21.02.0 on R1. This is my /etc/config/network file:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option packet_steering '1'
        option ula_prefix [redacted]

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'
        option type 'bridge'
        option peerdns '0'
        list dns '1.1.1.1'
        list dns '1.0.0.1'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'
        option type 'bridge'

config route
        option interface 'lan'
        option gateway '192.168.1.3'
        option target '192.168.2.1'
        option netmask '255.255.255.0'

Tell me if you need to know any more info about the issue.
Thanks!

PD: I left out the ula_prefix just in case, but I'm not completely sure if it's sensitive or not as I don't know much about IPv6.

Can you draw a diagram of your network, complete with the subnets on each device? It'll be more obvious how things are configured.

Sure, I think it would be something like this.

The router connected with coax is the one provided by the ISP, but I couldn't find an icon that would fit exactly a modem that doubles as a wireless router (though not I'm not using it for that). I haven't messed up much with it, so R1 is a DHCP client for that router (and that's why one of the routes goes to the 192.168.0.0/24 subnet, with source 192.168.0.10).
But I really don't think that is important for my issue.

Is R2 connected via the WAN port to S1?

What is behind R2?

Should be 192.168.2.0

2 Likes

You're right that I forgot the interfaces and subnets. Yes, S1 is connected to the wan port in R2, and connected to R1 in lan2.

Is masquerading enabled on the wan firewall for R2? If so, that will prevent the routing from working as you desire.

Well, that did it. I guess I was thinking the issue was much more complex than that.
I thought of it but ignored it because I believed specifying the mask was enough.

Thank you and sorry for wasting your time with such a simple issue!

Out of curiosity, are there any logs where this kind of error would be shown? I think I looked at logread briefly but didn't find anything useful.

It's often the simple stuff that is easy to overlook.

Not really... if you had firewall logging enabled you might have seen packets hitting the interface, but otherwise this isn't really something that gets logged.

1 Like

I was also expecting the route at least to be added but to work incorrectly. But if I type the ip route command I mentioned in the original post, writing 192.168.2.1 instead of 192.168.2.0, it clearly fails.
Oh well, then I'll be more careful next time! Thanks again to you both for your assistance and quick response.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.