route-nopull stops pulling all routes, if you only want to stop the redirect gateway then consider using:
pull-filter ignore "redirect-gateway"
But I am not sure if of any of this is necessary for PBR, at least when using WireGuard with PBR you can leave the default route for WireGuard in place.
In my setup (using (Snapshot) PBR just makes two extra tables one routing via WireGuard and the other via WAN.
The difference is who installs the default route. With WireGuard, it's netifd. With OpenVPN, it's the openvpn daemon.
True, so it might be different for OpenVPN vs WireGuard.
After adding route-nopull to the OpenVPN client, the only effect was that, on Luci-PBR, I could see that the WAN is the default gateway. Now, unfortunately, I can't select the MVPN interface in the policies. This problem persists even if I remove route-nopull and reboot the router.
So now, the situation is worse than before 
Curious as I am I did a quick test and indeed it looks like the PBR application copies 0.0.0.0/1 and 128.0.0.0/1, which is added by the OpenVPN client, to the pbr_wan table.
So this table should route via the WAN but it actually does not 
As you already remarked, as a stop-gap add pull-filter ignore "redirect-gateway def1" in the openvpn config.
But then for my OpenVPN provider (Proton) I did not have any default route which is expected, but PBR does not make any route either so i also have to add:
redirect-gateway
So in the end I got it working by adding this to the openvpn.conf:
pull-filter ignore "redirect-gateway def1"
redirect-gateway
After that I needed a reboot.
Maybe it works for others maybe not, no guarantee.
Maybe this is something which could be solved in the PBR code?
SysLog after
/etc/init.d/log restart; /etc/init.d/network restart; /etc/init.d/openvpn restart; sleep 10
openvpn.conf file
client
pull-filter ignore "redirect-gateway def1"
redirect-gateway
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
remote-cert-tls server
ping 10
ping-restart 60
sndbuf 524288
rcvbuf 524288
cipher AES-256-GCM
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
proto udp
auth-user-pass /etc/openvpn/mullvad_client.auth
reneg-sec 0
tun-ipv6
fast-io
remote-random
remote XXXX YYY
remote XXXX YYY
<ca>
...
</ca>
what is interesting, is luci-pbr information:
but still i can't select MVPN as interface for any policy.
Seen that too sometimes.
Try with a reboot.
If that does not help then it might be the ipv6.
For a different package than what's discussed here.
How this now sort of works for me is that you just choose the things (source, destination etc) you want to go via the WAN.
Everything else is already going via the VPN, so you do not need to choose the VPN, (it should be possible to choose the VPN, I have an idea why it is not but the pbr code (/etc/init.d/pbr ?) is somewhat above my pay grade).
ipchicken.com is now going via my WAN (browse to ipchicken.com to see the IP address)
The problem was that the MVPN wasn't set to "bring up on boot". This was odd because traffic was still going through the VPN 
Things have improved somewhat, but not completely.
Here are my current policies:
Here are my current policies:
Now, I'm only having issues with domain names. They're not working correctly. In theory, all "my IP" sites should be showing the WAN IP, but they're showing the VPN IP instead.
I have AdGuardHome ipset selected as Use resolver set support for domains
Let me explain.
By default, I prefer to use VPN for enhanced security and privacy. However, there are some sites, such as my banks and government sites, which I prefer to access via WAN.
I also have a MiBox which streams Disney+ and Netflix. These services don't work over VPN due to geolocation restrictions. I don't mind using them over WAN, but I also have TV Mate on the MiBox, which I prefer to use over VPN.
To address this, I've implemented Policy-Based Routing (PBR) to:
Finally, I have a work notebook that must go through the WAN.
Thanks to:
I managed to resolve the routing problem.
The issue I have now is with domain name resolution to IP addresses. Single domain sites such as whatismyipaddress.com are not resolving correctly because when I check my IP on these sites, they show the VPN IP instead of the WAN IP.
Try with Use resolver set support for domains : Disabled
That is working for me (provided DNS is working normally for you):
root@DL-WRX36:~# nft list table inet fw4
table inet fw4 {
set pbr_wan_4_dst_ip_cfg066ff5 {
type ipv4_addr
flags interval
counter
auto-merge
comment "ipchicken"
elements = { 104.26.8.109 counter packets 0 bytes 0, 104.26.9.109 counter packets 0 bytes 0,
172.67.73.20 counter packets 0 bytes 0 }
}
P.S. I hacked my way around /etc/init.d/pbr, line 1754 seems what is adding the 0.0.0.0/1 and 128.0.0.0/1 to all routing tables, I adapted it so that it no longer does that, it then works with the default Mullvad (and most other providers) which use redirect-gateway def1.
But I am sure that I am overlooking something and there must be an easy solution for this.
upside I learned a lot today 
P.S. It also seems that pushed DNS servers are not used by default, probably have to make up and down scripts for that?
it doesn't work for me. I think it's because i use AdGuardHome as DNS provider.
problably i found an issue:
||Linia 586: Fri May 19 20:19:19 2023 daemon.err AdGuardHome[5730]: 2023/05/19 20:19:19.275074 [error] ipset: adding host ips: adding mail.google.com[142.251.36.69] to ipset pbr_wan_4_dst_ip_cfg096ff5: netfilter query: netlink receive: no such file or directory|
|---|---|
||Linia 601: Fri May 19 20:19:24 2023 daemon.err AdGuardHome[5730]: 2023/05/19 20:19:24.675642 [error] ipset: adding host ips: adding api.whatismyip.com[34.98.116.180] to ipset pbr_wan_4_dst_ip_cfg086ff5: netfilter query: netlink receive: no such file or directory|
First of all, I've ditched the Use resolver set support for domains from AdGuardHome ipset to avoid having iptables and nftables at once. This might create some issues.
The real fun starts when in Use resolver set support for domains I set Disabled. AdGuardHome won't start because there is an error:
Fri May 19 21:57:41 2023 daemon.err AdGuardHome[16505]: 2023/05/19 21:57:41.068053 [fatal] dnsServer.Prepare: preparing ipset settings: open /var/run/pbr.adguardhome.ipsets: no such file or directory
The problem is solved by:
touch /var/run/pbr.adguardhome.ipsets
chmod 777 /var/run/pbr.adguardhome.ipsets
service adguardhome restart
Probably the permissions for the file are too big and this is dangerous but it works 
I don't know what creates the /var/run/pbr.adguardhome.ipsets file, but putting AdGuardHome ipset in luci-pbr as Use resolver set support for domains apparently causes this file to be created and there is no problem with it (but in return there are iptables and nftables).
Anyway, Disabled still won't work, because there is another error Router DNS issue with Adguard installed. The workaround for this is to add a line to /etc/resolv.conf nameserver 1.1.1.1. The comment Router DNS issue with Adguard installed - #12 by mercygroundabyss says it's the doing of peerdns '0'. But not in my case. I have to add nameserver 1.1.1.1 to /etc/resolv.conf. It's possible that AdGuardHome changes this during installation, but in my case, I definitely changed it intentionally. Anyway, this is not the cause, because changing to 1 does not fix the situation. I need to add the nameserver.
Both of the above solutions are not reboot resistant
After the above commands a pbr restart /etc/init.d/pbr restart helps:
Activating traffic killswitch [✓]
Removing routing for 'wan/X.X.X,X' [✓]
Removing routing for 'MVPN/tun0/10.10.0.2' [✓]
Deactivating traffic killswitch [✓]
pbr 1.1.1-7 (nft) stopped [✓]
Activating traffic killswitch [✓]
Setting up routing for 'wan/X.X.X.X' [✓]
Setting up routing for 'MVPN/tun0/10.10.0.2' [✓]
Routing 'tv' via MVPN [✓]
Routing 'tv1' via MVPN [✓]
Routing 'mibox' via wan [✓]
Routing 'my ip' via wan [✓]
Routing 'my ip 2' via wan [✓]
Routing 'gmail' via wan [✓]
Deactivating traffic killswitch [✓]
pbr 1.1.1-7 monitoring interfaces: wan MVPN
pbr 1.1.1-7 (nft) started with gateways:
wan/X.X.X.X
MVPN/tun0/10.10.0.2 [✓]
(I replaced the WAN IP with X.X.X.X)
and we're home. Almost.
nft list table inet fw4: (in fact, tv1 could be removed as it's redundant).
table inet fw4 {
set pbr_MVPN_4_dst_ip_cfg046ff5 {
type ipv4_addr
flags interval
counter
auto-merge
comment "tv"
elements = { X.Y.Z.W counter packets 0 bytes 0 }
}
set pbr_MVPN_4_dst_ip_cfg056ff5 {
type ipv4_addr
flags interval
counter
auto-merge
comment "tv1"
elements = { X.Y.Z.W counter packets 0 bytes 0 }
}
set pbr_wan_4_src_ip_cfg066ff5 {
type ipv4_addr
flags interval
counter
auto-merge
comment "mibox"
elements = { 192.168.1.200 counter packets 0 bytes 0 }
}
set pbr_wan_4_dst_ip_cfg076ff5 {
type ipv4_addr
flags interval
counter
auto-merge
comment "my ip"
elements = { 104.16.154.36 counter packets 0 bytes 0, 104.16.155.36 counter packets 0 bytes 0 }
}
set pbr_wan_4_dst_ip_cfg086ff5 {
type ipv4_addr
flags interval
counter
auto-merge
comment "my ip 2"
elements = { 104.21.89.158 counter packets 0 bytes 0, 172.67.189.152 counter packets 0 bytes 0 }
}
set pbr_wan_4_dst_ip_cfg096ff5 {
type ipv4_addr
flags interval
counter
auto-merge
comment "gmail"
elements = { 142.251.36.133 counter packets 0 bytes 0 }
}
pbr_wan_4_dst_ip_cfg086ff5 refers to the website https://www.whatismyip.com/ (its IP is 104.21.89.158). However, there I see that it shows me the IP from the VPN. Probably some underlying scripts are asking from a different address. I added it just for testing anyway.
Now it's time for streaming tests from my.stream.tv pbr_MVPN_4_dst_ip_cfg046ff5. Here is the tricky part. By default, it should go via VPN on the computer. mibox, because of the aforementioned Netflix and Disney+, got the policy to go through the WAN, although above this policy there is a more detailed one regarding my.stream.tv, which should be first.
So, from a computer that is not a mibox, the traffic goes through I don't know what, because in luci Status > RealTime Graph > Traffic both interfaces tun0 and wan are loaded equally:
It's possible that it's counting that it's going through tun0 but by physical interface, so it counts on both?
Now, Netflix from mibox:
(the peak at the beginning is the start of mibox. You can see that it went through WAN)
And streaming from mibox (I marked the start with a red line):
Here, too, you can see that traffic is being counted on two interfaces.
In summary:
/etc/rc.local with fixes looks:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
echo 'FIX AdGuardHome start.'
touch /var/run/pbr.adguardhome.ipsets
chmod 777 /var/run/pbr.adguardhome.ipsets
service adguardhome restart
echo 'FIX router DNS problem and restart pbr'
echo 'nameserver 1.1.1.1' >> /etc/resolv.conf
/etc/init.d/pbr restart
exit 0
Just out of curiosity, why are you routing gmail over wan?
just for tests.
Glad you got it working.
If you are satisfied mark the thread as solved so that others know
how to do this? it's enough that i checked "Solution" on my post?
Yes excellent now users know that this is solved (and how to do it )
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.