[VPR bug] discrepancy in net dev name convention producing duplicate ipt rule and causing gateway misallocation about source.openwrt.melmac.net HOT 21 CLOSED

Cannot reproduce the Luci bug on mainline 18.06.1.

With the proper ("br-guest") interface specified in the config, could you please run and post the output of:

source /lib/functions.sh
packageName="vpn-policy-routing"
config_load "$packageName"
config_get supportedIfaces          'config' 'supported_interface'
echo "$supportedIfaces"
process_interface(){ echo "$1"; }
config_load 'network'; config_foreach process_interface 'interface' 'create';

from source.openwrt.melmac.net.

So the interface name is just guest.
Can you please post (maybe in a short-lived pastie) the output of:

ip -4 route
ifconfig

from source.openwrt.melmac.net.

default via XX.46.104.107 dev pppoe-wan proto static
10.168.112.0/24 dev br-guest proto kernel scope link src 10.168.112.12
XX.46.104.107 dev pppoe-wan proto kernel scope link src XX.233.133.121
XX.43.174.98 via XX.46.104.107 dev pppoe-wan proto static
192.168.112.0/24 dev br-lan proto kernel scope link src 192.168.112.12

br-guest Link encap:Ethernet HWaddr D8:58:D7:00:87:4D
inet addr:10.168.112.12 Bcast:10.168.112.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:2304 Metric:1

from source.openwrt.melmac.net.

VPR shows the gateway, not an IP of the interface. Without the gateway VPR doesn't know how to route the packages from the interface. From the ip/ifconfig output for guest/br-guest, the VPR cannot obtain gateway.

from source.openwrt.melmac.net.

I had set a static route for the guest iface

config route
	option interface 'guest'
	option target '10.168.112.67'
	option gateway '10.168.112.12'
	option type 'local'

but that been superseded by this VPR policy

config policy
	option name 'lan'
	option local_addresses '192.168.112.12/24'
	option interface 'wg0'
	option remote_addresses '0.0.0.0/0'

from source.openwrt.melmac.net.

I put the static route back in but with type unicast and get

vpn-policy-routing 0.0.2-32 started on wan/xx.46.104.107 wg0/192.168.45.2 guest/10.168.112.12 [✓]

but the local traffic is still escaping via the WG policy/route, which is at the bottom of the VPR policies

tracert hpot

Tracing route to hpot.lan [10.168.112.67]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.112.12
2 21 ms 21 ms 20 ms 172.25.121.1
3 21 ms 21 ms 21 ms 172.25.120.1

from source.openwrt.melmac.net.

Well, the only policy you've set is for port 56007, so any traffic but destined for port 56007 should be routed thru default gateway.

from source.openwrt.melmac.net.

The issue seems somewhere along device vs. iface.

network_get_device if_icced iced; echo $if_iced prints

br-iced

and

ubus call network.interface.iced status

    "l3_device": "br-iced",
    "device": "br-iced",

so there is a dev named br-iced and then there is an iface named iced.

This becomes apparent by extending l469 of the init script

network_get_device dev "$iface"; echo $if_$iface; echo $if_$dev

iced
br-iced
Creating table 'iced/0.0.0.0' [✓]

from source.openwrt.melmac.net.

First of all, thank you for the investigation.

Maybe I didn't name the setting correctly, it probably should be called not supported interfaces, but supported networks. So in VPR settings it should be iced, not br-iced.

Did you also post something about uci and ip/ifconfig using different device names rather than interface/network names in some output resulting in duplicate rules?

from source.openwrt.melmac.net.

Could you please run and post the output of:

source /lib/functions/network.sh
for iface in guest iced; do
network_get_device dev "$iface"; echo "$iface - $dev";
done

from source.openwrt.melmac.net.

That prints

guest - br-guest
iced - br-iced

network_get_gateway() seems not to work for a br-iface since it being a L3 dev and thus its connected iface not being logical in the way it is interpreted by netifd & ubus. That would be my understanding.

From my understanding iproute2 does not make a distinction between dev and iface but prints the ifname of the dev and not the iface. Now you got the gateway info for br-iced but it is not matching the netifd iface ifname iced.

Which explains the wrong gateway.

Now about the fw rules being created twice by VPR I thought it was because of process_policy and process_interface but could not not find a fault in the logic. Could be related though to issue with dev name vs. face name.

from source.openwrt.melmac.net.

So dev names are being properly identified for interfaces on your system.

Can you please post the full output of ip -4 route | grep br-iced and ifconfig | grep br-iced (as text, not a screenshot).

from source.openwrt.melmac.net.

Also, what's the exact version of luci-app-vpn-policy-routing?

from source.openwrt.melmac.net.

luci-app-vpn-policy-routing git-18.356.64384-31d2..-34
vpn-policy-routing 0.0.2-34

ip -4 route | grep br-iced

172.20.112.0/24 dev br-iced proto kernel scope link src 172.20.112.12

ifconfig | grep br-iced

br-iced Link encap:Ethernet HWaddr D8:58:D7:00:87:5C

from source.openwrt.melmac.net.

Would 172.20.112.12 be the correct gateway for VPR to use for that bridge interface?

from source.openwrt.melmac.net.

yes, indeed it is the correct gateway.

Yet VPR produces

Chain VPR_PREROUTING (References: 5)

from source.openwrt.melmac.net.

Please test vpn-policy-routing 0.0.2-35.

from source.openwrt.melmac.net.

The routing appears to be working correctly/as expected 👍

/etc/init.d/vpn-policy-routing" restart

Routing 'router-iced' via iced [✓]
vpn-policy-routing 0.0.2-35 started on iced/172.20.112.12 [✓]
vpn-policy-routing 0.0.2-35 monitoring interfaces: iced [✓]

iptables -t mangle -S VPR_PREROUTING produces

-N VPR_PREROUTING
-A VPR_PREROUTING -d 172.20.112.0/24 -m comment --comment router-iced -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -m set --match-set iced dst -j MARK --set-xmark 0x30000/0xff0000

luci/admin/status/iptables#rule_mangle_VPR_PREROUTING is still showing, and what confuses me but perhaps is to be expected?

from source.openwrt.melmac.net.

Definitely not expected. I'm struggling to understand where it comes from tho.

from source.openwrt.melmac.net.

The routing appears to be working correctly/as expected 👍

Target Prot. In Out Source Destination Options
MARK all * * 0.0.0.0/0 172.20.112.0/24 /* router-iced */ MARK xset 0x30000/0xff0000
MARK all * * 0.0.0.0/0 0.0.0.0/0 match-set iced dst MARK xset 0x30000/0xff0000

Ah, right, sorry, the output you've posted is expected! Sorry!

from source.openwrt.melmac.net.

Oh, I see. Thank you for having fixed the issue! 🙇‍♀️

from source.openwrt.melmac.net.