VPN Policy-Based Routing + Web UI -- Discussion

VPN Policy-Based Routing is a service supporting multiple types of VPN Connections (Openconnect, OpenVPN, PPTP and Wireguard) allowing you to create policies to use either VPN tunnel or WAN as a gateway. More information (requirements, full features list, etc.) on the service is available in the README.

Gateways/Tunnels

  • Any policy can target either WAN or a VPN tunnel interface.
  • L2TP tunnels supported (with protocol names l2tp*).
  • Openconnect tunnels supported (with protocol names openconnect*).
  • OpenVPN tunnels supported (with device names tun* or tap*).
  • PPTP tunnels supported (with protocol names pptp*).
  • Wireguard tunnels supported (with protocol names wireguard*).

IPv4/IPv6/Port-Based Policies

  • Policies based on local names, IPs or subnets. You can specify a single IP (as in 192.168.1.70) or a local subnet (as in 192.168.1.81/29) or a local device name (as in nexusplayer). IPv6 addresses are also supported.
  • Policies based on local ports numbers. Can be set as an individual port number (32400), a range (5060-5061), a space-separated list (80 8080) or a combination of the above (80 8080 5060-5061). Limited to 15 space-separated entries per policy.
  • Policies based on remote IPs/subnets or domain names. Same format/syntax as local IPs/subnets.
  • Policies based on remote ports numbers. Same format/syntax and restrictions as local ports.
  • You can mix the IP addresses/subnets and device (or domain) names in one field separating them by space (like this: 66.220.2.74 he.net tunnelbroker.net).

DSCP-tag Based Policies
You can also set policies for traffic with specific DSCP tag. On Windows 10, for example, you can mark traffic from specific apps with DSCP tags.

Getting help
If things are not working as intended, please include the content of /etc/config/vpn-policy-routing and the output of /etc/init.d/vpn-policy-routing support with your post, as well as the output of /etc/init.d/vpn-policy-routing reload with verbosity setting set to 2. If you don't want to post the /etc/init.d/vpn-policy-routing support output in a public forum, there's a way to have the support details automatically uploaded to my account at paste.ee by running /etc/init.d/vpn-policy-routing support -p. You need to have the following packages installed to enable paste.ee upload functionality: curl libopenssl ca-bundle. WARNING: while paste.ee uploads are unlisted, they are still publicly available.

How to install
Both vpn-policy-routing and luci-app-vpn-policy-routing are available from official OpenWrt repositories. My repo: https://repo.openwrt.melmac.net/ may have newer/bleeding edge versions.

The old thread which grew too long and has too much of the no longer relevant information is kept here.

23 Likes

Changes in vpn-policy-routing 0.0.1-11:

  • service can detect active OpenVPN tunnels with device names different from tun* or tap*.
  • /etc/init.d/vpn-policy-routing status is an alias for /etc/init.d/vpn-policy-routing support.

Changes in luci-app-vpn-policy-routing 7:

  • Web UI can detect active OpenVPN tunnels with device names different from tun* or tap*.
  • Configuration is split into Basic and Advanced tabs.
  • All internal settings can be configured with Web UI.

If you have my repo added to your router, run the following commands to upgrade to latest:
opkg update; opkg upgrade luci-app-vpn-policy-routing vpn-policy-routing

If someone is using it with IPv6 both on WAN6 and the VPN tunnel -- please let me know.

Did you change something important? I'm having issue that the order in which policies are set is not respected. Here is an example

config policy
        option gateway 'wan'
        option comment 'horizonTV'
        option remote_addresses 'horizon.tv'
        option interface 'svkvpn'

config policy
        option comment 'Samsung'
        option local_addresses '192.168.8.162'
        option interface 'usavpn'

then the device 192.168.8.162 will not respect the first policy and will use usavpn for everything. Charging order of these policies will not fix the issue. This used to work several versions ago I had this working just fine.

Martin,

because I'm using a mix of ipsets and iptables rules there's no strict order of policies, but the domain policies (ipsets) should have higher priority than the ip address policies (iptables rules).

Can you post/PM me the output of /etc/init.d/vpn-policy-routing status?

Also, you can try to disabling use of both dnsmasq and ipset from WebUI and see if that helps. Just reload the service manually from CLI to make sure it takes effect and check the status.

@dziny saves the day (again!). I've accidentally reversed the order of the iptables rules which resulted in iptables rules having higher priority than ipsets. This has been fixed in vpn-policy-routing 0.0.1-12. The detailed description of priorities is posted in the Policies Priorities section of the README.

Thanks for this most excellent service.

Having a couple of issues. First, I get this message when attempting to enable DNSMASQ in Web GUI:
55 AM
Not sure what fields the error message is referring to. In any case, the service cannot be enabled.

Second, I am having trouble successfully implementing policies at level of domain name. I am trying to allow Netflix to work on all devices but for some reason that service is still sensing the VPN.

I'm a total noob so please forgive any, well, noobness. Also, please let me know what output I might provide in order to assist you. Thanks!

Which version of vpn-policy-routing do you have installed? Can you post the /etc/config/vpn-policy-routing please?

Known issue -- I don't know how they are doing it. My suggestion is to put the devices you want to use Netflix in a policy routing them thru WAN.

Version 0.0.1 I think.. I followed instructions, including requirements, here. Added your custom repos.

/etc/config/vpn-policy-routing output:

config policy
        option interface 'wan'
        option comment 'Domains'
        option remote_addresses 'netflix.com'

config policy
        option interface 'wan'
        option comment 'Local IP Addresses'
        option local_addresses '192.168.1.213 192.168.1.227'

config vpn-policy-routing 'config'
        option verbosity '2'
        option dnsmasq_enabled '0'
        option strict_enforcement '1'
        option udp_proto_enabled '0'
        option forward_chain_enabled '0'
        option unput_chain_enabled '0'
        option output_chain_enabled '0'
        option ipv6_enabled '0'
        option ipset_enabled '1'
        option enabled '1'
        list MULLVAD_VPN_dscp ''

Hmmm...so, for example, by local ip like I've done?

Also, I noticed one other thing that seemed odd that may or may not be related: when removing dnsmasq and installing dnsmasq-full, I got an error telling me that the original dhcp config file would not be changed but a new file called "dhcp-opkg" would be created. Is this normal?

Please try removing this line from config file: list MULLVAD_VPN_dscp '' -- did you add it manually or was it added by Web UI? If you can recall how it might have been added to the config it would greatly help me!

Yes, exactly.

Yes, that is perfectly normal.

It wasn't added by me. My guess is via web UI. I have been poking around the config files just to try and understand what's going on in there, but I have never changed anything. Unfortunately, I can't recall whether it was there from the very start or added more recently...

In any case, removing it in the config file and then attempting to enable DNSMASQ via Web UI seems to add the line back in again. However, it then occurred to me to try enabling DNSMASQ with the config file itself and this works and is reflected in the Web UI without any errors.

Any sense of why list MULLVAD_VPN_dscp ' ' is being added at this point? I assume I can keep it removed?

1 Like

I am having the same issue as @Ion where I cannot enable DNSMASQ through Web UI. Can confirm trying to enable via the Web UI does nothing and gives the same error. And enabling via config file works. I noticed at the bottom of the Web UI, under DSCP tagging it has 1 WAN DSCP tag and 2 TUN0 DSCP tags. Even deleting the dscp tag from the config file, it still shows the 2 TUN0 DSCP tags in Web UI.

1 Like

@Ion, @jvquintero1021 -- thank you for the reports guys, I think I know why it's been happening and it's been fixed in luci-app-vpn-policy-routing 9.

To upgrade (with my repo added to your router) run: opkg update; opkg upgrade luci-app-vpn-policy-routing.

Please manually remove the empty DSCP line from the config file before using the new version of Web UI.

So I just updated, did it the full proof way and deleted both vpn-policy-routing and luci-app-vpn-policy-routing, and I deleted the config file as well. Reinstalled both packages and reconfigured my settings, you did manage to fix the duplicate TUN0 DSCP tags that were showing under DSCP tagging, however I still can't enable DNSMASQ via the Web UI. Same as before I can only enable it via the config file.

Enabling via the Web UI still gives the same "One or more required fields have no value!" error and DNSMASQ will not enabled.

Same thing on this end

Can you post/PM me the content of /etc/config/vpn-policy-routing? I cannot achieve the error with the default settings from package, it will be easier for me to hunt down what's causing an issue if I had your config.

@Ion -- ditto.

PS. Please also send the output of: opkg list-installed | grep vpn-policy-routing.

config file /etc/config/vpn-policy-routing

config vpn-policy-routing 'config'
    option verbosity '2'
    option ipv6_enabled '0'
    option ipset_enabled '1'
    option strict_enforcement '1'
    option udp_proto_enabled '0'
    option forward_chain_enabled '0'
    option unput_chain_enabled '0'
    option output_chain_enabled '1'
    list ignored_interface 'vpnserver'
    option enabled '1'
    option dnsmasq_enabled '0'

config policy
    option comment 'Plex Remote Servers'
    option gateway 'wan'
    option remote_addresses 'plex.tv my.plexapp.com'
    option interface 'wan'

config policy
    option comment 'VPN Access'
    option interface 'pia'
    option local_addresses 'x.x.x.x'

config policy
    option gateway 'wan'
    option local_addresses 'x.x.x.x/24'
    option interface 'wan'
    option comment 'LAN Subnet'

config policy
    option comment 'Guest Subnet'
    option local_addresses 'x.x.x.x/24'
    option interface 'pia'

config policy
    option comment 'OpenVPN Server'
    option interface 'wan'
    option local_ports '1194'

config policy
    option comment 'OpenVPN Clients'
    option local_addresses 'x.x.x.x/24'
    option interface 'pia'

Output of "opkg list-installed | grep vpn-policy-routing"

luci-app-vpn-policy-routing - git-18.018.53029-cf1af79-10
vpn-policy-routing - 0.0.1-13

Looks like input chain option is misspelled, "option unput_chain_enabled" should probably be "option input_chain_enabled"

Thanks, I fixed that in luci-app-vpn-policy-routing 11 which I'm pushing to repo right now. Otherwise I'm at loss -- I've used your exact config file and tried to enable dnsmasq and it worked fine.

Sorry for the delay:

config policy
        option interface 'wan'
        option comment 'Domains'
        option remote_addresses 'hulu.com netflix.com'

config policy
        option interface 'wan'
        option comment 'Local IP Addresses'
        option local_addresses '192.168.1.213 192.168.1.227'

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


luci-app-vpn-policy-routing - git-18.018.53029-cf1af79-9
vpn-policy-routing - 0.0.1-13

Note: Following this output, I upgraded to luci-app-vpn-policy-routing 11 and retested. I'm still getting the error message and /etc/config/vpn-policy-routing remains unchanged as far as I can tell (i.e. input still spelled unput). The error message isn't the end of the world for me; it doesn't seem to affect overall functionality. I have no doubt you will get to the bottom of it eventually.

On another note: domain policy routing is now working for me (with the exception of netflix and hulu as we know). It seems to have started working correctly when I uninstalled vpnbypass service (had both to see if one worked better than the other for me). Coincidence or were they conflicting?

Idk how else I can help. I even went as far as reinstalling openwrt just now and re-configuring everything and still same issue.

like @Ion said no big deal it'll probably get fixed at some point without us even knowing. Must be something getting overlooked, for now at least we can still enabled via the config file.

Thanks anyway @stangri

I just did the same. I complete fresh install of LEDE, but I can't enable DNSMASQ from LUCI.

1 Like