Policy-Based-Routing (pbr) package discussion

Community Builds, Projects & Packages
2492

all of the sudden ? any idea ?

Logs

root@ax6000:~# service pbr start
pbr 1.2.1-r47 FAILED TO START in fw4 nft file mode!!!
Check the output of nft -c -f /var/run/pbr.nft
ERROR: Required binary 'ip-full' is missing!
ERROR: Errors encountered, please check https://docs.openwrt.melmac.ca/pbr/1.2.1/#ErrorMessagesDetails!

root@ax6000:~# nft -c -f /var/run/pbr.nft
internal:0:0-0: Error: Could not open file "/var/run/pbr.nft": No such file or directory

root@ax6000:~# apk list --installed | grep 'ipset|ip-full|dnsmasq|resolveip'
dnsmasq-full-2.91-r2 aarch64_cortex-a53 {feeds/base/network/services/dnsmasq} (GPL-2.0) [installed]
ip-full-6.18.0-r1 aarch64_cortex-a53 {feeds/base/network/utils/iproute2} (GPL-2.0) [installed]
resolveip-2 aarch64_cortex-a53 {feeds/base/network/utils/resolveip} (GPL-2.0) [installed]

root@ax6000:~#

2493

what is the output of:

readlink /sbin/ip

It should show /usr/libexec/ip-full

2494 
root@ax6000:~# readlink /sbin/ip
/usr/libexec/ip-full

downgrade to r41 fixed the issue, i'll stop using edge version for now

2495

HI,

using 25.12 on mt6000, and the pbr has a problem, kind of mismatch between pbr and luci-app-pbr, you can see it on the pic, idea what to do?

I tried what they say on the read me but the problem is still there.

thanks

Screenshot from 2026-01-05 20-50-46
Screenshot from 2026-01-05 20-50-461128×551 76.2 KB

2496

Could you try 1.2.1-45 that is what i am using an d works well for me

1 Like
2497

During the holidays things got out of sync but PR's are underway but it takes time to trickle through.

so either just wait or use Stans repo to update:

echo 'https://apk.openwrt.melmac.ca/packages.adb' >> /etc/apk/repositories.d/customfeeds.list
wget https://apk.openwrt.melmac.ca/apk.openwrt.melmac.ca.pem -O /etc/apk/keys/apk.openwrt.melmac.ca.pem
apk update
1 Like
2498

@egc may I ask if the 09-stop-wan-leak script is going to be embedded by default to the luci-app-pbr package at some point so that we do not have to manually place it in the desired location every time we do a fw update? It appears that by clicking retaining the config upon upgrade, it does not keep this file in place and we have to copy it over again.

Thanks!

2499

Good question, but did you add the script to /etc/sysupgrade.conf
So add to that:

/etc/hotplug.d/iface/09-stop-wan-leak

That should retain the script during upgrades.

If that works (and it should) then I will add a note to the script

2 Likes
2500

I tested it and it works. Thanks again.

Shall I raise an “issue” in pbr’s github section to get the change in a formal and transparent manner? Or there is no easy way to apply this script upstream so that everyone gets benefitted automatically?

2 Likes
2501

At the moment I am in bed with the flu but will think about it when I get better.

Before even contemplating adding it I need to add discovery of the wan interface by using the pbr uplink interface WANIF="$(uci -q get pbr.config.uplink_interface)" and also a config item in PBR to disable/enable it
option stop_wan_leak_on_start '1'

Will get back to you with a new version when I am well again

2 Likes
2502

Sure, I hope you get better soon.

Let me know when you get the new version.

Question: Will this be automatically reflected in the luci-app-pbr or does the maintainer of the luci-app-pbr need to make another change?

Thanks

1 Like
2503

Hi, I’ve been dealing with a persistent issue with PBR that was resolved in a previous version but has since reappeared.

When the default service gateway is set to the VPN and I create a policy to route the entire LAN subnet (192.168.1.1/24) through WAN, everything works fine. The LAN connects to services, but if an interface goes down or something similar happens, PBR attempts to "restart," which fails to work properly. I also utilize the hotplug script, but it doesn't make a difference. As a result, once PBR tries to recover from a downed interface, I lose access to those LAN services until I manually restart PBR through the web interface. Even if it says "running."

Firewall Example:

Lan -> services

Can anyone advise me on how to fix this? I remember there was a version that didn’t have this problem, but I can't recall which one.

Thanks!
@egc @stangri

2504

A few things you can try:

  1. Update to at least 1.2.1-45
  2. For a policy rule for the lan interface use @br-lan instead of 192.168.1.1/24
  3. disable the hotplug script and see if that makes a difference
2505

It looks like it's functioning now, thanks! I upgraded to the latest version through the repo and switched to using @ as well. I didn’t bother removing the hotplug script since it’s working fine now. However, I noticed that PBR tends to leak traffic when you restart the WAN/VPN (service gateways) or PBR. If an interface has both VPN and WAN, and you route that interface through the VPN, it still leaks traffic to the WAN during a restart. The same issue occurs in the opposite scenario.

2506

Great to hear it is working, probably upgrading is what did the trick as older versions were lacking local routes in the tables.

to be sure we are on the same page what script are you referring to?

A leak is normal when using PBR there are several ways to mitigate that, in your case making a traffic rule to REJECT traffic from LAN > WAN looks like the way to go

2507

Can someone confirm if the DSCP tagging works for them? I am on OpenWrt 24.10.5 with PBR version 1.2.1-r47 but can’t seem to get the DSCP tag for AmneziaWG interface, specifically for Firefox under Windows to work anymore. The URL policies are working but DSCP tagged browser still goes through the default WAN interface.

How do I troubleshoot this? I don’t recall exactly when this started happening either so can’t back track to make it work.

——–

Update: went back to PBR Version 1.2.0-r6 and all is normal now…….