You should also upgrade luci-app-pbr to 1.1.8-r4
Upgrade instructions needed if you are not running Snapshot: https://docs.openwrt.melmac.net/
Is there any error log or something like that, cause I've noticed recently that pbr always starts in a failed state, with
Unknown error!
Failed to set up 'wan/br-wan' / lan / etc.
over all the interfaces
But, as I rarely reboot the OpenWrt I don't have a slightest idea after what updates or changes that started to happen.
Had to add (sleep 15; /etc/init.d/pbr restart) & to rc.local, after what it works fine, no errors whatsoever.
There is a setting in the PBR config for adding a boot delay see the read.me
From my notes:
Note that especially OpenVPN is slow to setup so adding some delay is often necessary:
option procd_boot_delay '30' option procd_reload_delay '20'You might need different values
Furthermore depending on web browser used and add-ons I also noticed that the browser does not always refresh after a reload of PBR and although PBR is running, Luci-PBR shows stopped but after a refresh of the browser (CTRL+F5) it shows the correct running state
Nope, it is in a truly failed state (Ctrl-F5 wouldn't change it).
And I played with different values for the procd_boot_delay, up to 90, without success.
As if it always fails at the first launch. But works nicely after a forced restart.
And I believe that pbr should get reloaded when the slow interfaces go up or down anyways. But it seems like in that failed state it's not even able to sense these events.
What pbr build do you have?
Current is 1.1.8-r4 if you do not have that I would recommend to upgrade
At 1.1.7-31, the rc at the 1.1.8 stops me from upgrading.
You should be able to upgrade with instructions in the read.me :
Add OPKG/IPK repository to your OpenWrt device (GitHub)
opkg update
opkg install wget-ssl
echo -e -n 'untrusted comment: OpenWrt usign key of Stan Grishin\nRWR//HUXxMwMVnx7fESOKO7x8XoW4/dRidJPjt91hAAU2L59mYvHy0Fa\n' > /etc/opkg/keys/7ffc7517c4cc0c56
sed -i '/stangri_repo/d' /etc/opkg/customfeeds.conf
echo 'src/gz stangri_repo https://repo.openwrt.melmac.net' >> /etc/opkg/customfeeds.conf
opkg update
No that is not correct you have to use a local source e.g. @br-lan.
Note that if you have implemented IPv6 you also have to take care of DNS IPv6
See my notes: https://github.com/egc112/OpenWRT-egc-add-on/blob/main/stop-dns-leak/README.md#pbr-dns-policies
1 Like
Hello... I have an issue with pbr v.1.1.1-7 (?) installed on my router with OpenWrt 22.03.5 which does not behave as I expected.
Probably I posted in the wrong section, but this is the link
https://forum.openwrt.org/t/vpn-policy-based-routing-web-ui/
Could you please give a look?
Thanks
Your build is old and almost EOL, without using the latest PBR 1.1.8-r4 (which probably will not run on your build as it is nft only) it is difficult to do any troubleshooting
Oh... thanks a lot for feedback... but so pbr evolved so much? from 1.1.1-7 (latest available in my build) up to 1.1.8???
Lots of things have changed and bugs resolved
Ok, I see, Anyway my general question is: do you confirm it shall be possible to have two VPNs client (1 Wireguard and 1 OpenVPN) and route the traffic to WAN, WireguardVPN, OpenVPN interface depending on the destination urls, right?
I've just noticed that if I have 2 rules, like some urls shall go to wg0 and all the rest (I discovered this is an useless rule) to WAN, I have problems as well.
Thanks for your support
Sure I have 4 WG tunnels and two OpenVPN tunnels.
Make sure you do not set a port on the WG tunnels and that all subnets do not overlap.
Sorry what do you mean with do not set a port on the WG tunnels? As for the subnet they do not overlap! Thanks for hints
If you set a listen port on a wg tunnel, pbr will assume it's a "server" not a "client". That means that by default, pbr will not auto-detect that interface as a potential service gateway. Though this can be easily overridden by setting the interface name in the "supported interfaces" field in the advanced settings section.
2 Likes
I am confused by https://docs.openwrt.melmac.net/pbr/#Fw4NftFileMode . Is dnsmasq-full still required by 1.1.7+? Does https://docs.openwrt.melmac.net/pbr/#footnote7 apply to 1.1.7+?
I think, if you use Destinations (Domains) as routing and want to use nftset (the old ipset) then yes, so basically nothing has changed in this respect
That's doubly confusing in light of this:
Version 1.1.8
- This release completely drops the iptables/ipset (and resolvers using ipset) support.
- This release uses the fw4 nft file mode by default.
Those docs claim they're for 1.1.8, and that makes it sound like ipset support has been removed, and (by implication) dnsmasq-full is no longer required? However, elsewhere in those docs, there is a reference to how to (optionally) install dnsmasq-full.
The documentation is very difficult to understand by someone other than an expert (who probably doesn't need the docs).