Policy-Based-Routing (pbr) package discussion

Thanks! Setting masq to 1 indeed fixes the problem.

The funny thing is, my other site have masq=1 so pbr works there. I just forgot to toggle it in my current site :rofl:

1 Like

I need to sleep on it. It's quite complicated to implement. Maybe you'd be better off be either:

  1. resolving domains in question and storing the IP addresses in a file on a router to be picked up by a policy. Restarts should be faster then.
  2. resolving domains in question into non-pbr nftset which wouldn't be flushed on pbr restarts and creating a custom user script to make use of that external nftset.
1 Like

I need to sleep on it. It's quite complicated to implement.

Year, I fully understand. Looking at the size of all the PBR scripts it looks nowhere simple:) But this request should be somewhat popular, no? Or everybody else is okay with barely working vpn passthrough on every restart?)

in a file on a router to be picked up by a policy

Yeah, this seems to be a decent workaround. Can you please point to any examples of such functions for me to inspire on?) I'm not sure where to inject it

Hi, is it normal for pbr to stop itself when editing an existing policy? I didn't notice this behavior until the other day when I wanted to change a domain that got routed, and noticed that I had to manually start PBR after adding the domain. If this is normal, is there any way to change the behavior?

It could be browser related, I noticed that some browsers (also depending on some browser extensions) do not refresh the screen and the GUI still shows "stopped" but pbr is running. After refreshing the screen (F5) you should then see that the GUI shows "running".

You can also check from command line with service pbr status

On another note current PBR is 1.1.8-r31, if you do not have that you might consider upgrading, see: https://docs.openwrt.melmac.net/#Howtouse

1 Like

I went ahead and did a check to see if it was the browser (I use Firefox w uBlock) and used Chromium 138 with no extensions and saw the same behavior (Add a domain to an existing policy -> Save -> PBR stops). I also checked the version and I'm using 1.1.8-r16. I see in the link you provided that the dev is asking to add a repo. While I'm not opposed to doing that step, is there way to verify the binaries from the repo are unmodified from the public source code (Like are the builds reproducible?). If not, I can just deal with it and add the repo. Just curious

The link for 1.1.18-r31 is the official repo which will get backported to OpenWRT releases.

But of course you can wait till the new release is backported to the OpenWRT release

Hello, I have a pbr policy that routes the full subnet (192.168.10.1/24) through a vpn interface. I discovered that I can't adb connect to an Android device on that subnet from the same subnet connected via wifi; is this due to the rule?

For clients connecting on the same subnet there is no routing involved it is simply layer 2, so I do not think this has anything to do with it.

Note there is a config setting in the wifi to prevent wifi clients on that subnet connecting to each other but that is out of scope of this thread.

Apologies for the mistake. I have two subnets; one of them has a PBR policy that routes all traffic through a VPN. In the firewall, that subnet/interface can access another subnet, and vice versa, allowing them to communicate just like I do with other subnets. However, it doesn't work with ADB. Could that be due to the PBR policy?

Disable the PBR and test again

1 Like

Would a remote domain policy rule for a domain like: z-site.com work? It seems to not work for me, and i thought maybe because of the '-' in the name?

Update: Working! I also have AdlbockFast which was actually blocking that site.

Upgrade to the latest 1.1.8-r31, Stan and I have been working on the domain names :slight_smile:

1 Like

And I confirm that is working very good and I say thanks guys!

1 Like

Is there a workaround to ensure that PBR starts correctly after a router reboot?

It normally does on its own.

No, not really. I have a policy to route 192.168.20.1/24 over WAN, but if I restart the router, this policy stops working and isn't enforced until I manually restart PBR, at which point it does work.

I think @egc is also aware of this.

how are others solving the race condition leaking with vpns? is it possible to solve?

i am using OpenWrt 24.10.2 r28739-d9340319c6 / LuCI openwrt-24.10 branch 25.186.44806~9ceef01 and on boot, it is possible for traffic to reach the wan before pbr boots, so not using the vpn

the solution i had for this was to instead change the default path from wan to being one of the vpn nodes so the vpn node becomes the default route - now this does work, but it introduces another race condition

where when the vpn's are starting up, they wont go out via wan but instead go out via the default route so you get nested vpn tunnelling

client > vpn 1 (default route) > vpn 2 (desired real vpn endpoint)

the real desired routing should be

client > wan > vpn 2 (desired real vpn endpoint)

i've tested this out when rebooting and its pretty random which end up being bound to wan and which dont (as the initator of the wireguard interface)

its visible in

root@openwrt:~# ip route show table all
default via X.X.X.X dev eth0 table pbr_wan
192.168.0.0/20 dev eth1 table pbr_wan proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_wan proto kernel scope link src 192.168.20.1

default via VPN1 dev VPN1 table pbr_VPN1
192.168.0.0/20 dev eth1 table pbr_VPN1 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN1 proto kernel scope link src 192.168.20.1

default via VPN2 dev VPN2 table pbr_VPN2
172.17.0.0/16 dev docker0 table pbr_VPN2 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 table pbr_VPN2 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN2 proto kernel scope link src 192.168.20.1

default via VPN3 dev VPN3 table pbr_VPN3
172.17.0.0/16 dev docker0 table pbr_VPN3 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 table pbr_VPN3 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN3 proto kernel scope link src 192.168.20.1

default via VPN4 dev VPN4 table pbr_VPN4
172.17.0.0/16 dev docker0 table pbr_VPN4 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 table pbr_VPN4 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN4 proto kernel scope link src 192.168.20.1

default via VPN5 dev VPN5 table pbr_VPN5
172.17.0.0/16 dev docker0 table pbr_VPN5 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 table pbr_VPN5 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN5 proto kernel scope link src 192.168.20.1

default via VPN6 dev VPN6 table pbr_VPN6
172.17.0.0/16 dev docker0 table pbr_VPN6 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 table pbr_VPN6 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN6 proto kernel scope link src 192.168.20.1

default via VPN7 dev VPN7 table pbr_VPN7
172.17.0.0/16 dev docker0 table pbr_VPN7 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 table pbr_VPN7 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN7 proto kernel scope link src 192.168.20.1

default via VPN8 dev VPN8 table pbr_VPN8
172.17.0.0/16 dev docker0 table pbr_VPN8 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 table pbr_VPN8 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 table pbr_VPN8 proto kernel scope link src 192.168.20.1

default dev VPN3 proto static scope link

VPN1 via X.X.X.X dev eth0 proto static
VPN8 via X.X.X.X dev eth0 proto static
VPN4 via X.X.X.X dev eth0 proto static
VPN5 via X.X.X.X dev eth0 proto static
VPN2 via X.X.X.X dev eth0 proto static

X.X.X.X/X dev eth0 proto kernel scope link src X.X.X.X
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/20 dev eth1 proto kernel scope link src 192.168.1.1
192.168.20.0/24 dev eth1.20 proto kernel scope link src 192.168.20.1

VPN7 dev VPN3 proto static scope link
VPN6 via X.X.X.X dev eth0 proto static
VPN8 via X.X.X.X dev eth0 proto static

local VPN8 dev VPN8 table local proto kernel scope host src VPN8
local VPN1 dev VPN1 table local proto kernel scope host src VPN1
local VPN6 dev VPN6 table local proto kernel scope host src VPN6
local VPN4 dev VPN4 table local proto kernel scope host src VPN4
local VPN2 dev VPN2 table local proto kernel scope host src VPN2
local VPN7 dev VPN7 table local proto kernel scope host src VPN7
local VPN3 dev VPN3 table local proto kernel scope host src VPN3
local VPN5 dev VPN5 table local proto kernel scope host src VPN5

local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1

local X.X.X.X dev eth0 table local proto kernel scope host src X.X.X.X
broadcast X.X.X.X dev eth0 table local proto kernel scope link src X.X.X.X

local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown

local 192.168.1.1 dev eth1 table local proto kernel scope host src 192.168.1.1
broadcast 192.168.15.255 dev eth1 table local proto kernel scope link src 192.168.1.1

local 192.168.20.1 dev eth1.20 table local proto kernel scope host src 192.168.20.1
broadcast 192.168.20.255 dev eth1.20 table local proto kernel scope link src 192.168.20.1

unreachable fdf6:XXXX:XXXX::/48 dev lo proto static metric 2147483647 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium

i've obfuscated it a bit but you can see

VPN1 via X.X.X.X dev eth0 proto static
VPN8 via X.X.X.X dev eth0 proto static
VPN4 via X.X.X.X dev eth0 proto static
VPN5 via X.X.X.X dev eth0 proto static
VPN2 via X.X.X.X dev eth0 proto static

thats correct, but

VPN7 dev VPN3 proto static scope link

thats wrong and going down the wrong path

The best way to make sure lan clients are not leaking out of the wan is using the firewall to block traffic of those lan clients going out of the wan.

2 Likes

Installed 30505 today to one of my routers....Have been trying to reinstall pbr -r31 today but no luck installing the key to melmac site...http error 404...
Have the urls changed?

root@OpenWrt:~# echo 'https://apk.openwrt.melmac.ca/packages.adb' > /etc/apk/rep
ositories.d/apk.openwrt.melmac.ca.list
root@OpenWrt:~# wget https://apk.openwrt.melmac.ca/apk.openwrt.melmac.ca.pem -O
/etc/apk/keys/apk.openwrt.melmac.ca.pem
Downloading 'https://apk.openwrt.melmac.ca/apk.openwrt.melmac.ca.pem'
Connecting to 185.199.108.153:443
HTTP error 404
1 Like