VPN Policy-Based Routing + Web UI -- Discussion

Have you come to a conclusion on this decision? I am still sitting on 0.0.7-1

Yes, you can have local IPs/MACs in ipsets or iptables now. Check the README for the setting.

@stangri

I have upgraded to Davidc502's latest rev and noticed that there is a new menu entry for VPN. This is where the OpenVPN entry now is. Are you considering moving VPR to that same menu; I think it would be appropriate. Just a thought on a cosmetic issue.

OpenWrt SNAPSHOT r10899-1c0290c5cc / LuCI Master (git-19.241.65047-dffe9ca)

Using "Bootstrap" design (skin)

Thanks for bringing this to my attention. It's a new commit to the luci-app-openvpn which brought this up. A lot of people might not have it installed, so I'd prefer to check if this new section exists before adding VPN Bypass/VPR to it.

Please test luci-app-vpn-policy-routing 51.

Tried it and it seems to work OK but the options

option proto_control '0'
option chain_control '0'

have no effect. The 2 columns are always displayed.

VPR is still under the Services Menu.

Oh, thank you for catching it, I'm so used to untyped variables in shell, I forgot Lua is different. Fixed in version 52.

I'll try to install the new luci-app-openvpn (which has its own section) and see what's going on.

Updated to VPR Latest for App and script and get 14 entries of below error in system log but seems to work OK:

VPR = -22 and Script = -52

Tue Sep 3 22:42:28 2019 daemon.notice procd: /etc/rc.d/S94vpn-policy-routing: Device "" does not exist.

You may want to uninstall my luci app, followed by rm -rf /var/luci-modulecache/; rm -f /var/luci-indexcache; followed by the install again to have it show up under VPN.

I don't have a master/19.07 device to test, but when I tested the new luci-app-openvpn app with the new luci app for VPR (mixed with the luci cache flushes) both OpenVPN and VPN Policy Routing were gone from the Services menu.

I can't reproduce that.

Hi everyone,

I struggled getting a Wireguard server (to communicate with my phone) and a Wireguard client (Mullvad) to run at the same time, but where the traffic from the phone is also routed over the Mullvad interface. In another post of mine (Wireguard setup: Mullvad Client + Server for Android) I was told to ask you here.

I checked the mentioned tutorial (https://github.com/stangri/openwrt_packages/blob/master/vpn-policy-routing/files/README.md#local-openvpn-server-scenario-1), but all I read about seems to lead to a setup, where the client is routed via the WAN interface instead the Mullvad one. Did I get this right? So basically I want to connect my phone to my router via Wireguard and then by checking "am.i.mullvad.net" see, that my traffic is routed also over Mullvad.

So I want: Phone (abroad)-> Router -> Mullvad -> Internet

To answer this question finally: is this possible? If yes, I will try to follow your tutorial (and maby make it run for Wireguard), otherwise it would be great if somebody could explain, why this is not possible and what alternatives I would have.
Thank you all!

Noone? I asked Mullvad support, they think it should work somehow, but did not made it very precisely. To start with I tried to route my phone over WAN by PBR routing as mentioned in the tutorial but was also not able to make it run. The phone is not able to surf whatever I tried. As far as I understood this should work.

WG interface for Server is in WAN fw zone
WG interface for Client is in LAN fw zone

I added a rule to route the traffic from port 1234 (my server's port) over WAN like said in the tutorial. I also followed the suggestions in here to set ignored_interface to my server interface and disabled "Route Local IPs" in the server's config. What am I missing? Forcing my TV to WAN works perfectly.

This are my vpn-policy configs:

config vpn-policy-routing 'config'
        option verbosity '2'
        option strict_enforcement '1'
        option dnsmasq_ipset '0'
        option remote_ipset '1'
        option local_ipset '0'
        option ipv6_enabled '0'
        list supported_interface ''
        option boot_timeout '30'
        option iptables_rule_option 'append'
        option iprule_enabled '0'
        option enable_control '0'
        option proto_control '0'
        option chain_control '0'
        option enabled '1'
        list ignored_interface 'wg0'

config include
        option path '/etc/vpn-policy-routing.netflix.user'
        option enabled '0'

config include
        option path '/etc/vpn-policy-routing.aws.user'
        option enabled '0'

config policy
        option interface 'wan'
        option name 'TV'
        option local_address '192.168.100.151'

config policy
        option interface 'wan'
        option name 'Phone'
        option local_port '1234'

Did this with a fresh latest Davidc502 image install and VPR is still under "Services".

Oh, sorry, should be working in 53.

Just a cosmetic issue.

I have 7 OpenVPN Instances, I use 3 routinely and the others for test from time to time.

The ones not enabled show up as 0.0.0.0 in the VPR GUI under "Service Status"

With many OpenVPN Instances the "Service Status" will not display all the instances. It show up to 4 of my Instances (#4 is only partial). #5 to 7 are not displayed.

Is it possible to get a "Word Wrap" of a couple lines for "Service Status" in the VPR GUI?

Thanks.

Sorry, same issue, VPR is still in Services menu after I run your commands and uninstall - reinstall. I confirmed the directory and file were actually removed (deleted).

FWIW - I get the Device Error when I install VPR -22 and I need to revert to -14 to avoid the error. See screenshot of my last install below:

Would it not be better to use some sort of list for this? I mean to stack the interfaces one after another rather than using a text line to display the status.

1 Like

Sounds like a good idea to me.

I third that. Implemented in luci-app-vpn-policy-routing 54.

Works great, thanks.

Upgraded to VPR -24 and the error makes more sense. See screenshot of GUI Update result.

The device errors are the VPNs I have disabled so it is normal, I suppose.

I am not 100% sure of the "Command failed: Not found" error. If it is connected to the Device error then OK, if not, it is something else. Should I be concerned?