no problem just tinkering
Thank you.
This seem to be working. I tested my ISP tv (a device that need to be out of VPN) and now works.
Tomorrow I will check more devices.
Much appreciated
1 Like
PBR 1.2.2-r8 fixed the missing Service Gateways for me…I had tried renaming to lower case and adding to supported Interfaces. PBRs after r45 but still were missing the Gateways…With PBR 1.2.2-r8 they’re back and lowercase not required. Hoo-Ray!!!
Version 1.2.2-r8 - Running (fw4 nft file mode).
Service Gateways
wan/eth1/100.64.0.1
WGLAX
WGLASVEGAS
WGSANJOSE/10.14.0.2 ✓
OVPN/tun0
WGSFO
1 Like
No problem tinker away 
I have 2 VPN tunnels running in my router.
In my PBR configuration, I have:
list supported_interface 'nord wg0 ovpnclient0 ovpnclient1tcp ovpnclient2tcp'
How does PBR decide which one is used as the default?
I’d like mine to use nord as the default, but it keeps using wg0.
PBR does not decide what the default is, that depends on your Network setup e.g. what the default route is in the main table.
But PBR does not care and does not actually do anything with a "default route". After all it is you who decide what routing rule you make 
Technically the "default" route is the route traffic takes if you do not subject said traffic to a policy rule.
1 Like
I probably used the wrong terminology. Let me try again.
In my setup, all traffic go through the VPN tunnel unless I configure a rule in the PBR to route it otherwise. I seem to have forgotten where I configured this. What happens is that if PBR is down for any issue, my Internet access goes down.
Now, with two VPN tunnels in place, I need to have pbr use the ‘nord’ interface by default. Then I can manually route other traffic via wg0 if needed.
How do I do this?
Thanks in advance.
That is configured in the interface how to do that is explained in the PBR read.me
If PBR is disabled then it should not route anything and all traffic will take your default route so in your case via the VPN
If a VPN is not working and you have a PBR rule via that non working VPN then it depends on the PBR strict enforcement setting.
If it is set to strict then PBR will take care there is an unreachable route via the VPN so no traffic.
If not set to strict then it will not make a rule ergo the route is via your configured default route.
Provided you are using the latest 1.2.2-r8
2 Likes
I am on 1.2.2-r8.
Having two tunnel interfaces configured exactly the same, how does PBR decide which one to use first?
The first one takes precedence that is why you can move the rules up and down
The explanation about the policy/rules is clear. That’s not where my mind it clogged.
My issue is on having multiple Tunnels and the selection of the default one.
I have the below:
config interface 'WGNORD'
option proto 'wireguard'
option private_key 'wA4FXXXX='
list addresses '10.5.0.2/32'
list dns '103.86.99.100'
list dns '103.86.96.100'
option mtu '1420'
option multipath 'off'
option delegate '0'
config wireguard_WGNORD
option description 'NordVPN'
option public_key '0/x2PdXXXX='
list allowed_ips '0.0.0.0/0'
option persistent_keepalive '25'
option endpoint_host 'us8372.nordvpn.com'
option endpoint_port '51820'
option route_allowed_ips '1'
config interface 'LINODE'
option proto 'wireguard'
option private_key '8AEXXXXX='
list addresses '10.96.111.2/24'
list dns '9.9.9.9'
list dns '149.112.112.112'
option mtu '1420'
option multipath 'off'
option delegate '0'
config wireguard_LINODE
option description 'LINODE'
option public_key 'rZ+QvXXXXX='
option preshared_key 'js8vXXXXX'
list allowed_ips '0.0.0.0/0'
option persistent_keepalive '25'
option endpoint_host '45.33.X.X'
option endpoint_port '51820'
option route_allowed_ips '1'
What I am wondering about is why PBR is choosing LINODE as the default instead of the WGNORD:
PBR does not choose a default route I already explained that earlier, it is you who choose the default route at the interface level.
The default route can be seen with:
ip route show
But that is outside the scope of this thread although it is mentioned in the PBR read.me
For those of you who experience or are afraid of leakage of traffic via the wan while (re)starting of PBR or when interfaces go up and down see:
Note be sure to enable strict enforcement in the PBR app also
1 Like
Sorry for borked 24.10 merge everyone and thanks again to @egc for supporting everyone thru these turbulent times. 
Test users wanted to test 1.2.2-r9
This is a release with some new functionality.
It incorporates the stop-wan-leak which should minimise potential WAN leaks.
When strict-enforcement is enabled this will automatically enable stop-wan-leak.
When executing service pbr restart you can see when forwarding is disabled and enabled again.
It adds a trigger on Network config changes which can be useful if you use enable/disable interfaces in the Network, if you make use of this you probably should increase the00 procd_reload_delay in the config file to e.g. 5
It adds compatibility with the new luci-proto-openvpnimplementation in Master branch.
If you are going to use this then always set the device option (option dev)
Please test this build even if you do not use any of these newly implemented additions.
You can download and install it for APK (25.12 and Master branch) with:
cd /tmp
wget -O pbr.apk https://github.com/mossdef-org/pbr/releases/download/v1.2.2-9/pbr-1.2.2-9_openwrt-25.12_noarch.apk
wget -O luci-app-pbr.apk https://github.com/mossdef-org/luci-app-pbr/releases/download/v1.2.2-9/luci-app-pbr-1.2.2-9_openwrt-25.12_noarch.apk
service pbr stop
apk del luci-app-pbr pbr # opkg remove luci-app-pbr pbr
mv /etc/init.d/pbr /etc/init.d/pbr-old >/dev/null 2>&1 # backup old pbr in case it is not removed
apk add --allow-untrusted ./*.apk # opkg install luci-app-pbr pbr
service pbr start
For IPK (24.10 branch)
cd /tmp
wget -O pbr.ipk https://github.com/mossdef-org/pbr/releases/download/v1.2.2-9/pbr-1.2.2-9_openwrt-24.10_all.ipk
wget -O luci-app-pbr.ipk https://github.com/mossdef-org/luci-app-pbr/releases/download/v1.2.2-9/luci-app-pbr-1.2.2-9_openwrt-24.10_all.ipk
service pbr stop
opkg remove luci-app-pbr pbr
mv /etc/init.d/pbr /etc/init.d/pbr-old >/dev/null 2>&1 # backup old pbr in case it is not removed
opkg install ./*.ipk
service pbr start
THANKS
2 Likes
Hi there!
I managed to spare some time to test the new 1.2.2 tree (r8), and i’m happy to say everything works properly, with pppoe and auto wan_6 interface spawning. All my previous issues are solved.
Using from all lookup main suppress_prefixlength 1 in the rules was a genius idea, props for that.
Thank you very much for your testing and confirmation 
After further testing i have only one note, that may be worth documenting:
If “auto” ipv6 configuration is used on a pppoe device, using the automatically spawned wan_6 interface, it’s mandatory to pre-create the wan_6 interface in the /etc/config/network config like this:
config interface 'wan_6'
option proto 'none'
If you are not doing this, then the pbr_wan ipv6 routing table will not get created, and ip rules like the incoming rule for the wireguard server ( from all sport 51820 lookup pbr_wan ) will not work.
Have you set the uplink_interface6 to wan_6 in the config?
Yes.
root@HAWAII:~# cat /etc/config/pbr | grep uplink
option uplink_interface6 'wan_6'