PBR 1.2.1-69 is out with some fixes on boot up when wan interface is slow to come up, fixes for automatic WireGuard server rules, fixes for better handling of the artificial split of wan and wan6 and other minor fixes,
It is intended for version 25.12 and Master/snapshots builds and available at:
But you can add Stangri's repository to your custom feeds on your router so that you can install the new version directly from stangri's repo.
@pstlr78 and other users interested in stop-wan-leak.
I have made a version which stops forwarding while PBR restarts or reloads
You still have a gap while rebooting but this should minimise the gap while pbr restarts or reloads.
I say minimise because a small millisecond gap is not impossible but normally on restart it can be a gap of 4 to 10 seconds depending on your routers CPU and config.
You can find this version and instructions how to install it at:
PBR 1.2.1-87 is out with some fixes on boot up when wan interface is slow to come up, fixes for automatic WireGuard server rules, fixes for better handling of the artificial split of wan and wan6 and other minor fixes,
It is intended for version 25.12 and Master/snapshots builds and available at:
But you can add Stangri's repository to your custom feeds on your router so that you can install the new version directly from stangri's repo.
Loaded today’s snapshot on my Flint2 router which contained PBR 1.2.1-r87. Router functioned correctly and my exempted VOIP device in PBR functioned correctly. However there were no Service Gateways listed with PBR 87. (Should show WAN and Wireguard and OVPN Gateways). I then downloaded PBR R91 from the Melmac site and installed those instead rebooting the router as well..And again no Gateways listed with PBR R91 just like R87. Flashed back to my previous Snapshot which contained PBR Version 1.2.1-r45 and my Gateways were once again listed as normal. Just an FYI. Regards.
@pstlr78 and others experiencing leakage via the wan when the router reboots or PBR restarts or an interface restarts, I am working on a PBR version which should stop leakage via the wan.
As PBR itself starts early I have some hopes that this might be sufficient to stop all form of wan leakage so hopefully no need for any hotplug scripts but it needs careful testing.
This experimental version is based on 1.2.1-r93 and can be downloaded from:
You can also find there instructions and a script monitor-ip.sh to check if you are leaking via the wan.
This is tested on Main/snapshot and 25.12-rc4 on a Netgear R7800 and Dynalink DL-WRX36.
You might want to try adding wanb to the supported_interface list in /etc/config/pbr. I'm assuming you have IPv6 support disabled (ipv6_enabled=0).
In r45, both wan and wanb were auto-detected via fuzzy pattern matching (any interface with a wan suffix or prefix was hit), so your wan and wanb would each receive its own routing table, mark, and rules. (I haven't checked the logic thoroughly and do not have a dual WAN environment to test. You can sanity check this by running ip rule list and ip route show all).
r87 introduces support for split uplinks and switches to a static configuration for supported WAN interfaces (using uplink_interface and uplink_interface6, defaulting to wan and wan6). As a result, wanb is no longer auto-detected and likely needs to be manually added to the supported_interface list.
wan6 shows up in r87 due to this split uplink support - wan6 is always recognized, but the actual IPv6 processing is conditional. The routing rules, policy processing, etc., are all gated behind the ipv6_enabled check.
Tried again today. The only Service Gateway shown today is WAN. Tried two different Browsers (Brave and Firefox) and hit Ctrl F5 several times. No difference. However as previously stated my OOMA Voip device is functioning correctly (Exempted from VPN as it shoud be). The output of (logread -e pbr) and (service pbr status && service pbr support) is too long to post in the thread. Regards.
Ok, do I need to add wan and my wireguard interface also? Or are those automatically added/detected. I don't want to keep experimenting as this is my primary/main router for my whole system. I don't have time to test it on my test setup until next weekend (swamped with work hahaha).
I turn on my IPv6 from time to time. Has issues with my current provider as there are times it doesn't work (it's their fault, they have routing issues in IPv6) that is why it's turned off most of the time. In that sense, do I need to add wan6 and wanb6 also?
No need. wan is the default uplink, and WireGuard interfaces are automatically detected by protocol (pbr checks the OpenWrt config to see if the interface proto is wireguard).
I strongly suggest waiting to test this when you have more time. Simply checking ipv6_enabled in pbr might not work out of the box, especially if you have multiple IPv6 GUAs/dynamic prefixes from your ISP. You might find you need to tweak source-based routing or network prefix translation to get it working, so it's best not to risk your main connection right now.
I installed OpenWrt 25.12.0-rc4 on Flint2, backup would not work (no network and no LuCI). I reconfigured manually the router up to PBR which is not working for me. Minor issue is that like motox22a, Gateway are not listed in the LuCI PBR status page.
When I start the service, then LuCI and internet connection stop working. Internet and LuCI come back working fine right after I stop the pbr service using ssh.
Here are some details about my configuration when the service starts:
===== /etc/init.d/pbr restart =====
Resetting routing [✓]
Resetting resolver [✓]
pbr 1.2.1-r93 (fw4 nft file mode) stopped [✓]
Using uplink interface (on_start): wan [✓]
Found uplink gateway (on_start): XXX.XXX.160.1 [✓]
Processing environment (on_start) [✓]
Setting up routing for 'wan/eth1/XXX.XXX.160.1' [✓]
Setting up routing for 'wg/10.2.0.2' [✓]
Routing 'Isp-To-Wan' via wan [✓]
Routing 'Lan-To-Wg' via wg [✓]
Installing fw4 nft file [✓]
Setting interface trigger for wan [✓]
Setting interface trigger for wg [✓]
pbr 1.2.1-r93 monitoring interfaces: wan wg
pbr 1.2.1-r93 (fw4 nft file mode) started with gateways:
wan/eth1/XXX.XXX.160.1
wg/10.2.0.2 [✓]
Status after restart:
pbr - environment
pbr 1.2.1-r93 on OpenWrt 25.12.0-rc4 r32534-12374d88b9.
Uplink (IPv4): wan/eth1/XX.XX.160.1.
Dnsmasq version 2.91 Copyright (c) 2000-2025 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-DNSSEC no-ID loop-detect inotify dumpfile
pbr fw4 nft file: /usr/share/nftables.d/ruleset-post/30-pbr.nft
add chain inet fw4 pbr_dstnat {}
add chain inet fw4 pbr_forward {}
add chain inet fw4 pbr_output {}
add chain inet fw4 pbr_prerouting {}
add rule inet fw4 dstnat jump pbr_dstnat
add rule inet fw4 mangle_prerouting jump pbr_prerouting
add rule inet fw4 mangle_output jump pbr_output
add rule inet fw4 mangle_forward jump pbr_forward
add rule inet fw4 pbr_forward counter meta mark & 0x00ff0000 != 0 return
add rule inet fw4 pbr_output counter meta mark & 0x00ff0000 != 0 return
add rule inet fw4 pbr_prerouting counter meta mark & 0x00ff0000 != 0 return
add chain inet fw4 pbr_mark_0x010000
add rule inet fw4 pbr_mark_0x010000 counter meta mark set (meta mark & 0xff00ffff) | 0x010000
add rule inet fw4 pbr_mark_0x010000 return
add chain inet fw4 pbr_mark_0x020000
add rule inet fw4 pbr_mark_0x020000 counter meta mark set (meta mark & 0xff00ffff) | 0x020000
add rule inet fw4 pbr_mark_0x020000 return
add rule inet fw4 pbr_prerouting ip saddr { 192.168.0.0/24 } counter goto pbr_mark_0x010000 comment "Isp-To-Wan"
add rule inet fw4 pbr_prerouting ip saddr { 192.168.1.0/24, 192.168.2.0/24 } counter goto pbr_mark_0x020000 comment "Lan-To-Wg"
pbr chains - policies
chain pbr_forward { # handle 1383
}
chain pbr_output { # handle 1384
}
chain pbr_prerouting { # handle 1385
}
chain pbr_dstnat { # handle 1382
}
pbr chains - marking
chain pbr_mark_0x010000 { # handle 1393
}
chain pbr_mark_0x020000 { # handle 1396
}
pbr nft sets
pbr tables & routing
IPv4 table main routes:
default dev wg proto static scope link
XXX.XXX.160.0/22 dev eth1 proto kernel scope link src XXX.XXX.163.140
XX.XX.48.106 via XXX.XXX.160.1 dev eth1 proto static
192.168.0.0/24 dev br-lan.100 proto kernel scope link src 192.168.0.1
192.168.1.0/24 dev br-lan.101 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev br-lan.102 proto kernel scope link src 192.168.2.1
IPv4 table main rules:
29998: from all lookup main suppress_prefixlength 1
32766: from all lookup main
IPv4 table 256 (pbr_wan) routes:
default via XX.XX.160.1 dev eth1
IPv4 table 256 (pbr_wan) rules:
29997: from all sport 443 lookup pbr_wan
30000: from all fwmark 0x10000/0xff0000 lookup pbr_wan
IPv4 table 257 (pbr_wg) routes:
default via 10.2.0.2 dev wg
IPv4 table 257 (pbr_wg) rules:
29999: from all fwmark 0x20000/0xff0000 lookup pbr_wg
Those details then appear when I display again status
pbr chains - policies
chain pbr_forward { # handle 1383
counter packets 324 bytes 31903 meta mark & 0x00ff0000 != 0x00000000 return # handle 2784
}
chain pbr_output { # handle 1384
counter packets 209 bytes 27922 meta mark & 0x00ff0000 != 0x00000000 return # handle 2785
}
chain pbr_prerouting { # handle 1385
counter packets 537 bytes 62166 meta mark & 0x00ff0000 != 0x00000000 return # handle 2786
ip saddr 192.168.0.0/24 counter packets 0 bytes 0 goto pbr_mark_0x010000 comment "Isp-To-Wan" # handle 2791
ip saddr { 192.168.1.0-192.168.2.255 } counter packets 200 bytes 18939 goto pbr_mark_0x020000 comment "Lan-To-Wg" # handle 2793
}
chain pbr_dstnat { # handle 1382
}
pbr chains - marking
chain pbr_mark_0x010000 { # handle 1393
counter packets 0 bytes 0 meta mark set meta mark & 0xff01ffff | 0x00010000 # handle 2787
return # handle 2788
}
chain pbr_mark_0x020000 { # handle 1396
counter packets 202 bytes 19019 meta mark set meta mark & 0xff02ffff | 0x00020000 # handle 2789
return # handle 2790
}
I don’t know why the same setup worked without issue on openwrt 24 but not 25, any ideas?
It is probably not related to your problem but the above rule is unnecessary and can be removed/disabled.
Your default routing is already via the WireGuard interface.
Reboot afterwards or do: service network restart && service pbr restart
and everything is working so not sure what is going on.
To rule out IPv6 I removed IPv6 and everything is still working.
If you want we can take a look at your whole config, in that case start a new thread in the Installing and Using OpenWRT forum and please connect to your OpenWRT device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button
Remember to redact keys, passwords, MAC addresses and any public IP addresses you may have but do not redact private RFC 1918 IP addresses as that is not needed:
service pbr support # works starting with 1.2.1-r93
ip route show
ip -6 route show
ip route show table all
ip rule show
wg show
I recreated my config step by step, it is all working fine until I add a wireguard interface with option listen_port on 443. After rebooting the router it shows the same behaviour as before: no LuCI or internet
Setting the listen port to something else like 14443 fixes it.
Is this something to expect with openwrt 25.12 / pbr 1.2.1-r87 ?
I wanted to take the opportunity to thank you for your very well explained documentation on how to set up a wireguard server on openwrt. I used it years ago and it worked wonders.
Ah! That explains why LuCI and internet aren't working.
If a WG interface has a listen_port configured, pbr treats it as a server and automatically adds an IP rule: from all sport $listen_port lookup pbr_wan
If setting wireguard listen_port to 443, the rule becomes what you previously provided:
This ip rule will directs all traffic with source port 443 to the pbr_wan table.
Since the pbr_wan table routes everything out via eth1, LuCI (and also HTTPS services on the internet) return traffic (source port 443) gets forced out the WAN (eth1) instead of going back to the LAN client. This breaks connectivity to the LuCI web interface, and the internet (other ports are not affected, such as SSH, which runs on source port 22).
Ah! That explains why LuCI and internet aren't working.