VPN Policy-Based Routing + Web UI -- Discussion

I could try building an image manually from Jan 18th (day before switch to fw4). What packages do you use, vpr and wireguard?

I have a couple of problems with pbr,

I'm trying to have separate VPN zones, where clients have access ONLY to their respective VPN and can't fail back to LAN or another VPN.

I also want to be able to passthrough the VPN server itself to wan so that a client that roams from 4G to wifi can continuing using its own self managed VPN (eg, the ip of the VPN server should route though Wan)

I've tried adding the VPN server host name to pbr (pass through wan) and then adding a firewall rule to allow forward --> wan with the same ipset from pbr (found using ipset list)

Dnsmasq ipset integration is also set up.

However this has a few problems:

  1. The openvpn client will cache the VPN server IP (that it retrieved from 4G), so the Dnsmasq ipset never kicks in, and thus the route/firewall is not updated, and the client can't connect (and vpn through vpn doesn't work either)
  2. Every time pbr restarts, it clears the ipset, and pbr restarts when the VPN comes up, so it clears the VPN server IP from the list at startup...

I'm not really sure what the answer is here, I could disable ipset support, then pbr would manually add the route after doing a dns lookup at startup, but then there'd be no ipset for the firewall rule to attach to, so the packets to wan from the client side would be rejected.

Maybe an option to backup the ipsets or not drop them at restart would help? Or an option to force a lookup at startup even when using Dnsmasq and ipsets? Though lookup at startup would not help when I want to do a whole domain eg *.domain.com

There might be a bug that the following code does not exclude IPv6 LLA

pbr_get_gateway6() {
	local iface="$2" dev="$3" gw
	network_get_gateway6 gw "$iface" true
	if [ -z "$gw" ] || [ "$gw" = '::/0' ] || [ "$gw" = '::0/0' ] || [ "$gw" = '::' ]; then
		gw="$(ip -6 a list dev "$dev" 2>/dev/null | grep inet6 | awk '{print $2}')"
	fi
	eval "$1"='$gw'
}

Maybe change the line inside the if-block to:

		gw="$(ip -6 a list dev "$dev" 2>/dev/null | grep inet6 | grep -v -e ' fe80:' | awk '{print $2}')"

Not an IPv6 expert, but if the NAT6 is running on the router (which is one of a few scenarios where VPR can actually work with IPv6), would the LLA not be a legit IPv6 address for an interface?

You code is right. IPv6 LLA can be used as default gateway.

Thank you again Paul!
So if I were to add other endpoints (peer2) to my existing "Surfshark VPN" interface, I've noticed that my router will default to the last endpoint added. Can you point me in the right direction for learning more about this uci script and how/if it interacts with a [vpn-policy-routing 0.2.1-13] set as VPN default route.

Thank you and no rush.
Bill

Hello everyone :slight_smile:

Thank you very much!
I set up several rules for different VPN and everything works for my local network clients.
I want all VPN rules to work even when my phone is connected to the internet via a mobile network. To do this, I put a Shadowsocks server on my home OpenWRT-router and my mobile phone is a client for my home Shadowsocks server.
The problem is that VPN Policies do not work for clients connected via Shadowsocks. That is, the traffic of clients connected via Shadowsocks does not go to VPN Policy-Based Routing.
Can I somehow fix this?

A quick search of the forum Shadowsocks VPN Policy-Based Routing

The quoted post is about the Shadowsocks client.
I have a question about the interaction of VPN Policies with Shadowsocks server.

Shadowsocks server I believe rewrites Iptables.

Not sure if re-starting vpn-pbr following Shadowsocks server startup would help.

You might also consider going this route:

I'm not an expert, but I think the first line of the documentation you recommended shows that it's not my situation:
If the OpenVPN client on your router is used as default routing (for the whole internet)

My default route to the WAN, and only some sites need to go through the VPN.

Restarting vpn-pbr after starting Shadowsocks server had no effect.

Go down one then:

Thanks a lot for trying to help.
I'm really quite new to this subject.

Could you briefly describe your idea, and tell me where in the documentation you see the solving of my problem.

I contacted the Shadowsocks developer and he said ss-server traffic should be marked in the OUTPUT chain. For local network clients, it's PREROUTING. The other thing is, those traffic initiated by ss-server will have router local address as source address.
Maybe this will help to understand the cause of the problem?

The path you specified assumes that SS traffic is "seen" for VPN-pbr. And this, unfortunately, is not so.

Everything worked out!
The answer of the SS developer helped:
...ss-server traffic should be marked in the OUTPUT chain. For local network clients, it's PREROUTING. The other thing is, those traffic initiated by ss-server will have router local address as source address.

pbr reloading very slow after OpenVPN down and up

Fri Apr 15 22:10:27 2022 daemon.notice netifd: Network device 'tun0' link is down
Fri Apr 15 22:10:27 2022 daemon.notice netifd: Interface 'openvpn' has link connectivity loss
Fri Apr 15 22:10:27 2022 daemon.notice netifd: Interface 'openvpn' is now down
Fri Apr 15 22:10:27 2022 daemon.notice netifd: Interface 'openvpn' is disabled
Fri Apr 15 22:10:28 2022 daemon.notice netifd: Interface 'openvpn' is enabled
Fri Apr 15 22:10:28 2022 daemon.notice netifd: Network device 'tun0' link is up
Fri Apr 15 22:10:28 2022 daemon.notice netifd: Interface 'openvpn' has link connectivity
Fri Apr 15 22:10:28 2022 daemon.notice netifd: Interface 'openvpn' is setting up now
Fri Apr 15 22:10:28 2022 daemon.notice netifd: Interface 'openvpn' is now up
(NOTHING IN BETWEEN HERE)
Fri Apr 15 22:55:37 2022 daemon.notice netifd: wan (5200): udhcpc: sending renew to server ...
Fri Apr 15 22:55:37 2022 daemon.notice netifd: wan (5200): udhcpc: lease of ... obtained from ..., lease time 7200
Fri Apr 15 23:27:54 2022 user.notice pbr: Reloading table 'openvpn/tun0/...' [✓]
Fri Apr 15 23:55:37 2022 daemon.notice netifd: wan (5200): udhcpc: sending renew to server ...
Fri Apr 15 23:55:37 2022 daemon.notice netifd: wan (5200): udhcpc: lease of ... obtained from ..., lease time 7200
Sat Apr 16 00:21:47 2022 user.notice pbr: Reloading table 'openvpn/tun0/... ' [✓]
.....
Sat Apr 16 00:55:59 2022 user.notice pbr: service started with gateways: wan/eth2/... wan2/pppoe-wan2/... [✓] openvpn/tun0/...

The usual loading time for my pbr setting is less than a minute. But the reloading after openvpn down and up takes more than two hours. When an interface is down and up and I try to start pbr, it always says that another app is using iptables. When this happens, I used to restart openwrt but I supposed that it is not the correct way to do. I wonder whether any one can give a solution. Thanks.

Regarding the problem I reported 4 days ago. I found the following comment from https://serverfault.com/questions/805718/iptables-another-app-is-currently-holding-the-xtables-lock:

This answer suggests the possibility of delays caused by slow DNS lookups, which can be avoided by including -n in the iptables command line. Perhaps you can use strace or ltrace to investigate what the active iptables process is doing (pid 1526 in your output), or at least check, via something like ps -fp $(pidof iptables), whether the iptables command includes -n.

In the referred url, I found the following:

iptables -L by default will try to resolve IP addresses to hostnames.

I have a small iptables ruleset on this one system here, but it does take a while to get through even that small list because of the rules.

By using iptables -L -n, it displays everything numerically and skips IP resolution and port service common name display. It should also display faster. (The -n option tells it to show numerical entries for everything and will NOT try and resolve IPs. The downside is, ports will also be displayed numerically, rather than http for port 80 for example.)

I am not sure whether using iptables -L -n will solve the problem, or it may couse more issues.

Hello, I'm using DDNS and detecting WAN IP using HE URL but the router itself uses the VPN connection instead of WAN (VPN is the default) thus reporting the wrong IP. Can anyone help me make the policy? I already tried adding the domain/ASN.

You need to use the OUTPUT chain for this.

1 Like

Thanks that did it!