Static Routing causing no internet access

Installing and Using OpenWrt Network and Wireless Configuration
1

I am using x86/64 with the latest SNAPSHOT.

Randomly, last week, my phone stopped being capable of connecting to the WiFi. It said ‘no internet access’. I went and turned off my static routes I created that push its traffic to the WAN, and it suddenly started to work again, most likely because the wg tunnel was intercepting it.

My question is, what is causing this? A bug with static routing? A bug with Wireguard being the default route? No idea.

Nothing has been changed on the router for months in terms of settings. I updated it to see if that fixed the issue, but it did not.

Here are my configs:

/etc/config/network:

config interface 'loopback'
option device 'lo'
option proto 'static'
list ipaddr '127.0.0.1/8'

config globals 'globals'
option packet_steering '2'

config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
option ipv6 '0'

config interface 'lan'
option device 'br-lan'
option proto 'static'
list ipaddr '10.0.0.1/24'
option delegate '0'
list dns '10.0.0.1'
option multipath 'off'

config interface 'wan'
option device 'eth1'
option proto 'dhcp'
option hostname '*'
option peerdns '0'
list dns '10.0.0.1'
option multipath 'off'

config interface 'wg1'
option proto 'wireguard'
option private_key 'xxx'
option mtu '1420'
list addresses 'xxx'
list dns '10.0.0.1'
option multipath 'off'

config wireguard_wg1
option description 'xxx'
option public_key 'xxx'
list allowed_ips '0.0.0.0/0'
option endpoint_host 'xxx'
option route_allowed_ips '1'

config rule
option priority '1'
option in 'lan'
option src '10.0.0.4/32'
option lookup '100'
option enabled '1'

config route
option interface 'wan'
option target '0.0.0.0/0'
option mtu '1500'
option table '100'
option enabled '1'

/etc/config/firewall:

config defaults
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option synflood_protect '1'
option drop_invalid '1'
option flow_offloading '1'

config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'

config forwarding
option src 'lan'
option dest 'wan'

config include 'pbr'
option fw4_compatible '1'
option type 'script'
option path '/usr/share/pbr/firewall.include'

config zone
option name 'wan'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option masq '1'
list network 'wan'

config zone
option name 'wg1'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option masq '1'
list network 'wg1'

config forwarding
option src 'lan'
option dest 'wg1'

/etc/config/dhcp:

config dhcp 'lan'
option interface 'lan'
option start '2'
option limit '250'
option leasetime '12h'
option dhcpv4 'server'
option ipv6_only_preferred '0'

config odhcpd 'odhcpd'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '3'
option maindhcp '1'

config host
option name 'Device'
option ip '10.0.0.4'
option mac 'xxx’
2

I don't know how it has been working before, but you can omit the next hop (gateway) address for P2P connections only.

When the next hop address is missing, the router decides that the target is directly connected to its interface and sends an arp request (instead of forwarding the packet to the gateway).

Given that the wan interface uses DHCP (the gateway may change), it is probably a good idea to use option ip4table.

https://openwrt.org/docs/guide-user/network/network_configuration#common_options

1 Like
3

To add see my notes to do Policy Based Routing including directions to get the correct gateway or use option table.
OpenWRT Policy Based Routing (PBR)

4

Hm. Oddly enough, removing the static route that I set, and then setting the option ip4table ‘100’ under the WAN interface seems to have fixed it. I kept the static rule for the one device, of course, pointing to table 100.

Unsure why this suddenly broke everything, but as you said, it could be that the gateway changed due to DHCP on the WAN. (I never had the gateway specified in the first place for the static route since it never seemed to affect anything, but oh well.)

5

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