VPN policy based routing possible?

For some reasons I’ve stopped receiving e-mail notifications on new posts from this forum.

If you have any questions, please head to the OpenWrt forum (follow the direct link in the README on github), just make sure to indicate you’re running VPR on a TOS device.

PS. No, nobody has reached out.
PPS. If anyone has a use case for the Tor-related policies or the policies affecting the local interface (for example you’ve created the guest network you want to route via specific tunnel), please let me know. While Tor code isn’t quite ready, I believe the interface-targeting policies code is ready, I need testers.

It is not working since a while with wireguard as causing a kernel panic and subsequent reboot loop https://github.com/stangri/openwrt_packages/issues/24

The above mentioned kernel panic is still present with TOS 3.10.8 / kmod-wireguard 4.4.161+0.0.20180918-…2-1 / kernel 4.4.161-0a333a8e606ab056173befac424900d2-1

Odd, I am not having any issues or kernel panics with wireguard and routing. ** replaced for my IP to be hidden

Creating table 'wan/**.**.22.1' [✓]

Creating table 'VPSCLOUD/' [✓]

Routing 'DREAMLINK1' via VPSCLOUD [✓]

Routing 'DREAMLINK2' via VPSCLOUD [✓]

Routing 'HTTP' via VPSCLOUD [✓]

Routing 'HTTPS' via VPSCLOUD [✓]

Routing 'TELNET' via VPSCLOUD [✓]

Routing 'SSH' via VPSCLOUD [✓]

Routing 'IPTV1' via VPSCLOUD [✓]

Routing 'IPTV2' via VPSCLOUD [✓]

Routing 'IPTV3' via VPSCLOUD [✓]

Routing 'SSH2' via VPSCLOUD [✓]

Routing 'CL' via wan [✓]

vpn-policy-routing 0.0.2-28 started on wan/**.**.22.1 VPSCLOUD/ [✓]

vpn-policy-routing 0.0.2-28 monitoring interfaces: wan VPSCLOUD [✓]


I would head over to the strangri forum he mentioned. He is pretty helpful (he helped me personally on a different router) when I had issues.

Indeed, and he is aware of the issue. But I am not sure whether he is still maintaining the code. The github repo does not indicate much activity lately and even his activity in the OpenWRT (formerly LEDE) forum seems to have ceased.

you named the wireguard interface VPSCLOUD, as in

config interface 'VPSCLOUD' ?

And all outbound tcp traffic (port 80 aka http / port 443 aka https), except CL is routed through the wireguard tunnel?

Is the remote VPN endpoint provided by a VPN service provider or your own controlled/setup server?

Hello, yes, my wireguard is called VPSCLOUD. Only name I could think of at the time LOL.

You are correct, ports 80/443/22/23 are through the Wireguard interface as is IPTV which uses certain ports. CL is a game, that also uses a certain port, but added just to make sure it goes out the wan, really isn’t needed as all traffic that is not specified goes out the wan interface.

I currently use a cloud VPS server (Ubuntu 18) for wireguard. I have used Mullivad services before, and it works with them as well. I use a VPS with Kamatera now, but did use Digital Ocean as the VPS server at one time, both you can destroy when needed, took me about 15-20 minutes to setup on a new server.

I made a .sh file on the router, that switches out the policy and routes everything through wan if I need it. Sometimes when I purchase things, some places do not like VPNs. I am unsure of your problem however and why you are getting a kernel panic. Are you able to bring the interface up at all, without the policy routing? I manually edit my policy file, I don’t use LuCI to edit the ports on the router for the policy routing. The only “issue” I see is the manual reloading of the policy routing, but have a cron that does that after boot (after 3 minutes) that does this for me.

Strange issue you have.

Here is my interface. If you need help I will try my best, but it is working here:
http://prntscr.com/l6wwwp (admin, hope it is ok to post a screenshot, please delete if not ok).


So do I

Yes, the wg iface is up and running, the VPS is accessible and all traffic from TO can be routed through it, with no issues and it is inexplicable to me why VPBR is causing the kernel panic but it does, as soon as activating any traffic rule for the wg iface. It is causing this

alert kernel[]: [ 4591.684808] Unable to handle kernel paging request at virtual address 312f736d
alert kernel[]: [ 4591.692084] pgd = ea5a4000
alert kernel[]: [ 4591.694796] [312f736d] *pgd=00000000
emerg kernel[]: [ 4591.698432] Internal error: Oops: 5 [#1] SMP ARM

General VPBR config

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option udp_proto_enabled '1'
	option strict_enforcement '1'
	list ignored_interface 'guest'
	list ignored_interface 'tun'
	option dnsmasq_enabled '0'
	option ipset_enabled '1'
	option enabled '0'

Just discovered what is apparently the culprit for the kernel panic - a potential conflict with a SQM instance enabled on the wg iface

config queue
	option debug_logging '0'
	option qdisc 'fq_codel'
	option enabled '1'
	option interface 'wg0'
	option download '90000'
	option upload '19000'
	option verbosity '0'
	option qdisc_advanced '0'
	option script 'piece_of_cake.qos'
	option linklayer 'none'
1 Like

This been fixed in the latest release 0.0.2-31

1 Like

Using TOS 3.11.1 and vpn-policy-routing 0.0.2-34, I configured this routing policy:

config vpn-policy-routing 'config'
        option verbosity '2'
        option ipv6_enabled '0'
        option ipset_enabled '1'
        option dnsmasq_enabled '0'
        option strict_enforcement '1'
        option enabled '1'

config policy
        option interface 'wan'
        option name 'DMZ HTTPS Server'
        option local_ports '443'
        option remote_addresses ''
        option remote_ports '0-65535'
        option local_addresses ''

The two rules for WAN and VPN are correctly created in the routing policy database:

$ ip rule
32752:  from all fwmark 0x20000 lookup 202
32753:  from all fwmark 0x10000 lookup 201

but the firewall rule to mark IP packets coming from is not set. Looking at /var/log/messages, there is this error:

2018-12-28 00:43:49 notice [3138]: ERROR: iptables -t mangle -I VPR_PREROUTING 1 -j MARK --set-xmark 0x010000/0xff0000 -s  -p tcp -m multiport --sport 443 -d  -p tcp -m multiport --dport 0:65535 -m comment --comment DMZ_HTTPS_Server

When I run manually the iptables command reported in the error, I get:

iptables v1.6.1: multiple -p flags not allowed
Try `iptables -h' or 'iptables --help' for more information.

Since ‘0-65535’ covers all ports such can be omitted (deleted thus) and the error should be gone.

Seems that ipt does not like/accept the -p flag twice (sport | dport) in the same rule.

@stangri vpn-policy-routing 0.0.7-15 seems to have introduced a bug of sorts

Whilst the other report seems to be on a OpenVPN node my node with WG is exhibiting the same issue

/etc/init.d/vpn-policy-routing restart

vpn-policy-routing 0.0.7-15 stopped [✓]
Creating table ‘wan/xxx.233.237.160 peer xxx.46.104.107’ [✗]
Creating table ‘wg0/’ [✓]
Routing ‘oc-ssh’ via wan [✓]
Routing ‘oc-vps-cp’ via wan [✓]
Routing ‘oc-vnc’ via wan [✓]
Routing ‘stv’ via wan [✓]
Routing ‘1750e’ via wan [✓]
Routing ‘dvb-c’ via wan [✓]
Routing ‘to.lan’ via wg0 [✓]
vpn-policy-routing 0.0.7-15 started on wg0/ with errors [✗]
ERROR: Failed to set up ‘wan/xxx.233.237.160 peer xxx.46.104.107’
vpn-policy-routing 0.0.7-15 monitoring interfaces: wan wg0 [✓]

What is the status of this?

Is the vpn-policy-routing (https://github.com/stangri/openwrt_packages/tree/master/vpn-policy-routing) package now working with latest Turris OS (4.0.1)?

If so, is there any remaining reason why the repo is not added to the list of repo’s queried by Turris OS luci ?

(Just trying to understand if it’s a good idea for me to do that manually on my system or if there are remaining things that need to be fixed to make it stable. I’d like to do IP source address based routing for my Android Set Top Box.)

It is an external repo and not included in OpenWrt. The package source features an extensive README of how to get things rolling.

When I try to update to the newest VPN PBR routing I get the following error. Does somebody else have the same issue?

Blockquote ## Error from 2019/11/15 13:37:clock430:
Updater failed:
inconsistent: Package luci-app-vpn-policy-routing requires package luci-compat that is not available.

1 Like

I can confirm this currently being exhibited on a TOS4.x node. For some reason the package luci-compat would seem to be absent at the upstream [1] repo and thus not being available throuhg the TOS repo either.
Probably best to lodge a package request with upstream development.

[1] https://downloads.openwrt.org/releases/18.06.5/packages/arm_cortex-a9_vfpv3/

I have the same problem. Assuming that this will be fixed in a future release, is there a way to work around this?

I keep getting several emails per day notifying me that “luci-compat” is not available.
As I understood it, luci-compat has been added in a recent openwrt upgrade?

I tried to manually upgrade luci-app-vpn-policy routing with
opkg --nodeps install luci-app-vpn-policy-routing
but that didn’t help.

switch to the HBT branch or compile the package and install it locally.

1 Like

As @anon50890781 advised you might want to use HBT branch (RC) by using switch-branch hbt or you may try HBK. Why this happened, you can take a look here:

1 Like