Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

network_find_wan returns interfaces with non-default ip4table #5

Open
1 task done
gentoo-root opened this issue Jun 5, 2023 · 0 comments
Open
1 task done
Labels
bug Something isn't working

Comments

@gentoo-root
Copy link

Describe the bug

The network_find_wan function uses the following query to find the WAN interface: [@.route[@.target='0.0.0.0' && !@.table]].interface. If I parse it correctly, it's supposed to find the interfaces that have a route to 0.0.0.0, and this route is in the main table (i.e. no table override is set), which makes sense to me.

However, the !@.table part of the query seems to be a no-op, because table is missing even for routes of the interfaces that use option ip4table in /etc/config/network. That means, network_find_wan will find such interfaces, although their 0.0.0.0 route is not in the main routing table. Many packages use network_find_wan to find the actual WAN interface, and they will misbehave if network_find_wan returns a VPN interface instead of WAN.

The same issue affects network_find_wan6.

OpenWrt version

r23246-d85013460d

OpenWrt target/subtarget

mediatek/mt7622

Device

Linksys E8450 (UBI) (actually Belkin RT3200)

Image kind

Self-built image

Steps to reproduce

Configuration (mind the ...):

/etc/iproute2/rt_tables:

...
1 vpn

/etc/config/network:

...
config interface 'vpn'
        option proto 'wireguard'
        option private_key '...'
        list addresses '...'
        list addresses '...'
        option ip4table 'vpn'
        option ip6table 'vpn'
        option nohostroute '1'

config wireguard_vpn
        option public_key '...'
        option preshared_key '...'
        option endpoint_host '...'
        option endpoint_port '...'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '0.0.0.0/0'
        list allowed_ips '::/0'
...

Check that the routes don't have the table field:

$ ifstatus vpn | jsonfilter -e "@.route[@]"
{ "target": "::", "mask": 0, "nexthop": "::", "source": "::\/0" }
{ "target": "0.0.0.0", "mask": 0, "nexthop": "0.0.0.0", "source": "0.0.0.0\/0" }

Check that the default route of vpn is not in the main routing table:

$ ip route | grep '^default '
default via ... dev wan ...

Check that the default route of vpn is in the vpn routing table:

$ ip route show table vpn | grep '^default '
default dev vpn proto static scope link

Check that network_find_wan returns vpn instead of wan:

$ . /lib/functions/network.sh
$ network_find_wan wan; echo "$wan"
vpn

Actual behaviour

network_find_wan returns vpn, although the vpn interface doesn't have a default route in the main table.

Expected behaviour

network_find_wan should return wan. ifstatus vpn should return the "table": "vpn" field for each route.

Additional info

I believe the root cause might be in netifd, because it generates data for the ifstatus output, but I didn't dig into netifd's sources.

Diffconfig

No response

Terms

  • I am reporting an issue for OpenWrt, not an unsupported fork.
@gentoo-root gentoo-root added the bug Something isn't working label Jun 5, 2023
@jow- jow- transferred this issue from openwrt/openwrt Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant