As a test, I've named all my interfaces, dev and openvpn instances the same: tun0, tun1, etc and I still get these errors
Invalid OpenVPN config for tun0 interface
Invalid OpenVPN config for tun1 interface
Invalid OpenVPN config for tun2 interface
Invalid OpenVPN config for tun3 interface
I'm assuming its because I don't have dev specified directly in my OpenVPN config and they're configured like so.
config openvpn 'tun0'
option config '/etc/openvpn/tun0.ovpn'
option enabled '1'
Same here, the one that has a uci config inside the /etc/config/openvpn gives no warnings (if renamed the same as the interface), the one that is working with the external .ovpn config still does
In my case there is no wireguard config files, the interface is created in a sh file like so: ip link add dev "$tun" type wireguard
$tun being tun_w in the linked config example
Anyway, could you please shed some light on what are the downsides of simply ignoring that warning? In other words what paths your pbr init file misses in case of a warning?
@yxtc934 Well, if you manually assign a device tun* to a wireguard interface, pbr will detect it as an OpenVPN tunnel (since there's nothing in your /etc/config/network to indicate protocol otherwise).
The pickings are slim for pbr to identify the OpenVPN tunnel as when the tunnel is down, there's no /sys/devices/virtual/net/${dev}/tun_flags file, so it assumes that anything with tun* or tap* as a device is an OpenVPN tunnel.
My goal is to have the same interface enumeration wherever the tunnel is up or down, so that when the tunnels goes down/up, only the routing table for that interface needs to be rebuilt and the policies can stay the same. That would allow the pbr to generate the "atomic" nft-file on start, place it where fw4 would pick it up on restart/reload and then only deal with interface up/down events unless the policies change. For the netifd-compliant tunnels it can be further simplified by letting netifd handle routing table changes.
My understanding is that when the OpenVPN tunnel is configured like shown in the README, the interface enumeration will be the same wherever tunnels are up or down.
Until I implement the atomic nft file support there are no repercussions for ignoring the warning. My understanding is that once it's implemented, you will not be able to use atomic nft and the nft rules will have to be regenerated often.
Following a brilliant suggestion from @bogorad the pbr 1.1.0-13 will parse the interfaces listed in the WAN firewall zone and (if supported) will list them as target in WebUI/allow their use without having to explicitly set them as supported.
Not sure about the others, but I for example don't put all of them into the WAN firewall zone, but rather have a separate zone for each interface.
As another suggestion, wouldn't it be easier and less error prone (instead of trying to automatically figure out the type of the interface, through a thousands of user configurations) to just provide a configuration field (like you have now Supported Interfaces and Ignored Interfaces) for users to just put (or maybe select from a dropdown) their WAN interface, their OpenVPN interface(s), their Wireguard interface(s), etc.?
I see:
Edited the post you quoted for clarity.
There's still old code to parse all interfaces trying to identify them as well.
My goal is to have something that can be started and not needlessly configured beyond adding policies. If a user is savvy enough to change the name of wan interface or have a more complex configuration, they should be savvy enough to make their config discoverable by pbr. For everyone else, default configuration should be sufficient.
Does it support v2ray too ?
Updated to pbr/luci 1.1.0-20, now I only have the wan interface listed in the rule config's dropdown for the interface. Adding my interfaces to the "Supported Interfaces" list does nothing.
The routing rules themselves work fine
Can you try to restart RPCD, clear the browser cache and as a last resort reboot the router?
I can't reproduce this and I suspect it's because some luci components got cached.
Nope, even the full reboot and clearing the browser cache didn't fix that.
Hello,
will for any chance pbr prevent a port forwarding rule to be added.
i am trying to add a rule to forward all lan dns queries to my pihole but as soon as i hit save and apply the rule is discarded without any warning. all i can see in the logs is that pbr restarted:
Sun Mar 19 15:14:22 2023 user.notice pbr: Reloading pbr due to includes of firewall
Sun Mar 19 15:14:23 2023 user.notice pbr: Activating traffic killswitch [✓]
Sun Mar 19 15:14:23 2023 user.notice pbr: Setting up routing for 'wan/x.x.x.x [✓]
Sun Mar 19 15:14:23 2023 user.notice pbr: Setting up routing for 'wg0/x.x.x.x' [✓]
Sun Mar 19 15:14:23 2023 user.notice pbr: Routing 'synology' via wan [✓]
Sun Mar 19 15:14:24 2023 user.notice pbr: Deactivating traffic killswitch [✓]
Sun Mar 19 15:14:24 2023 user.notice pbr: service monitoring interfaces: wan wg0
What's the output of ubus -S call luci.pbr getInterfaces '{"name": "pbr" }' and your /etc/config/network file?
Depending on how it's been added.
root@OpenWrt:~# ubus -S call luci.pbr getInterfaces '{"name": "pbr" }'
{"pbr":{"interfaces":["wan","wg0"]}}
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ip6assign '60'
list ipaddr '192.168.1.254/24'
option ipv6 '0'
option delegate '0'
config device
option name 'wan'
option macaddr '62:38:e0:c5:36:18'
config interface 'wan'
option proto 'dhcp'
option ipv6 '0'
option device 'wan.1081'
option metric '20'
config interface 'wan6'
option proto 'dhcpv6'
option device 'wan.1081'
option reqaddress 'try'
option reqprefix 'auto'
config device
option type '8021q'
option ifname 'wan'
option vid '1081'
option name 'wan.1081'
config interface 'wg0'
option proto 'wireguard'
option private_key ''
list addresses ''
option peerdns '0'
list dns '8.8.8.8'
option metric '10'
config wireguard_wg0
option description 'US-NJ#9'
option public_key ''
list allowed_ips '0.0.0.0/0'
option route_allowed_ips '1'
option endpoint_host 'x
option endpoint_port '51820'
i added the rules in network > firewall > port forwards
as soon as i hit save the rules are rolled back.
ubus -S call luci.pbr getInterfaces '{"name": "pbr" }':
{"pbr":{"interfaces":["wan"]}}
/etc/config/network:
In the same boat here
Adding them into Supported Interfaces doesn't force them into the dropdown anymore either
