VPN Policy-Based Routing + Web UI - ARCHIVE #1

Please PM me the output of /etc/init.d/openvpn-policy-routing support.

PS. You may want to obfuscate your PPPoE login/pass in a previous post.

After setting up IPv4 port based routing to separate the VPN tunnel and have it route traffic on a different subnet as my LAN how can I make it so that the clients on the VPN tunnel can still communicate with the clients of the LAN?

Not sure I understand (or can help even if I understood) you correctly. But if you want VPN "users" to have access to LAN clients, why separate them into a different subnet?

Again, not sure if I personally can help out, but maybe other community members can -- I'd encourage you to post dhcp, network and openvpn-policy-routing configs.

My LEDE Version is:

Model: Linksys WRT1900AC
Firmware Version: LEDE Reboot 17.01-SNAPSHOT r3442-5b0b27e / LuCI lede-17.01 branch (git-17.152.82987-7f6fc16)
Kernel Version: 4.4.71

I am having issues with OPR not reloading when a Tunnel is activated. I have a 2 PIA OpenVPNs setup, NLD and UK. They are tun0 and tun1 respectively. The are linked to interfaces myvpn and myvpn1 respectively. So: NLD=tun0=myvpn and UK=tun1=myvpn1

The problem is that most times on boot it takes too long for the VPNs to come up and OPR is already triggered before the VPNs are finished and initialized. This causes OPR not to setup correctly and nothing works. If I manually Save&Apply on the OPR Luci App it will, after some seconds, work as it should.

I tried adding sleep 90 to the start-up but it does not work correctly. I think it interferes with procd but I am not sure.

Can I add something to the OPR initd file to reload or restart OPR on tun0 and tun1 connectivity? Maybe a custom trigger event?

Some sys logfile extracts that may help:
Sat Jun 24 16:02:08 2017 daemon.notice netifd: Interface 'myvpn1' is enabled
Sat Jun 24 16:02:08 2017 daemon.notice netifd: Network device 'tun1' link is up
Sat Jun 24 16:02:08 2017 daemon.notice netifd: Interface 'myvpn1' has link connectivity
Sat Jun 24 16:02:08 2017 daemon.notice netifd: Interface 'myvpn1' is setting up now
Sat Jun 24 16:02:08 2017 daemon.notice netifd: Interface 'myvpn1' is now up
Sat Jun 24 16:02:08 2017 daemon.notice openvpn(PIA_UK_London_AES128)[1806]: Initialization Sequence Complete

Edit - Added: Did some hit&miss tests and changed the OPR start sequence from 94 to 99 and put the following in rc.local:

sleep 80
/etc/init.d/openvpn-policy-routing reload

exit 0

The workaround seems to work sometimes but is not always OK on reboot but most times OPR works.

I have a request which is probably not difficult to fix.
I have decided to roll openvpn policy-based routing in the second location and I have encountered the following issue. I have two wans in this location which are called wan and wan2. Both work and have entries in the routing table
default xx.xx.xx.xx 0.0.0.0 UG 10 0 0 pppoe-wan
default yy.yy.yy.yy 0.0.0.0 UG 20 0 0 eth0.2

Until now I was using mwan3 to handle them, I was applying a very simple routing rule, my main network 192.168.0.1/24 went out by default though wan (wan2 serves as failover) while the guest network 192.168.2.1/24 went out by default though wan2 (wan serves as failover).

I plan to configure 1-2 openvpn links as well. The trouble is that I only see wan in luci-app-openvpn-routing there is no wan2. I also see tun0 tun1 adapters I have already configured. But the second wan is missing. I think this is due to the fact the author has not anticipated the scenario of more than one wan port. But it seems to me it should be fixable without too much difficulty.... I'm happy to troubleshoot any testing versions.... Thank you.

The author certainly did not. :wink: I use LEDE's built-in network_find_wan function to obtain the name of the (first) WAN interface. I'm not sure if there's another function to iterate over all available WAN interfaces or what is the alternative approach to get the names of all WAN interfaces. If there is, it still wouldn't be an easy fix, but it would be a doable fix. :wink:

There must be a way I guess since that's what mwan3 is doing. I wish I knew more than that:)

Did some more hit-miss testing and realised that OPR was not the issue but OpenVPN.

It seems the routing table was getting messed up so I set "route_nopull" (Don't pull routes automatically) check box in OpenVPN and it seems to improve my situation.

I still need to "reload" OPR at 30 secs to get a good setup but that is OK for me at the moment.

Hello, I just wanted to see if I understand correctly, and it may not do it. If I have restricting that when my VPN is down and it can't route, and I have 2 VPNs.... both of which say port 80 goes to (tun0, then tun1) and I order them to the vpn I want it to go through first... Say tun0, then if that is down it goes to the next rule which has the same port (80) to try tun1, will the VPN Policy Routing do that? So if I have 2 different rules, both having port 80 go out (one with tun0, one with tun1) that it will try them in the order I put them? Or can I not do this. I just want it to try 1 first, if that is down, go out the second, and if both are down, to not go out (restrictive and not go anywhere). Thanks!

Hi, I am using the openvpn-policy-based routing and is working very well in general terms, however I have two tunnels and the script only runs when the first tunnel establishes the connection. I have to manually stop and start the service and the routes are working fine for both tunnels. This is a small problem when the router looses power, since it will reboot and only the routes assigned to whatever tunnel starts first will be active.
Thanks!

Yeah, I've removed some code which had to do with the service restart on various events which I thought was redundant and looks like at certain events the service doesn't get reloaded. I'll look into it within the next few weeks.

I got Netflix working, including mobile, by doing the following:

Under Domain-based Policies (dnsmasq), I set:
/amazonaws.com/netflix.com/nflxext.com/nflximg.com/nflxvideo.net/plex.tv/plexapp.com/whatsmyip.org/wanroute

This worked sometimes, but after 24h or so it would stop working. I noticed that I could generally fix it by re-applying the settings (which restarts the service). So I added the following to Scheduled Tasks, and it seems to work 100% of the time now:

30 6 * * * /etc/init.d/openvpn-policy-routing reload

1 Like

@stangri

Just a suggestion for novices like me.

Could you add a log type page to the OPR LUCI GUI to output the "/etc/init.d/openvpn-policy-routing support" command? Maybe with the "-d" option also?

It would make it easier and quicker to check that all is working OK.

Also, maybe a "reload" button on the main OPR LUCI GUI page?

Just a few thoughts.

1 Like

Thanks for this info. I am trying to do this also. Will test in a couple of weeks when I have some time to try it.

Probably my fault -- I'm guessing the service doesn't get reloaded from time to time, I'll look into it.

Brilliant suggestions, both of them. I'm not creating the page from scratch, I'm using Luci's provided API to map the page to the service settings, so I'm not sure if what you're asking is easily achievable, but I'll have a look at it once I figure out the reliable service reloading and IPv6 (hopefully).

Speaking of IPv6, good news/bad news kind of deal -- I'm finally home and set up the he.net's 6in4 tunnel on wan6 to experiment with, so hopefully there will be some progress now. However I'll be gone for a few more weeks soon, so I don't expect much happening until August.

I've updated some of the service reload triggers code and the way interfaces are processed in 4.1.5-8, so hopefully service will now be properly reloaded on the VPN/WAN interface reloads and also help me test IPv6.

If you have my repo added to your installation just run: opkg update; opkg upgrade openvpn-policy-routing.

Did you manage to find a vpn provider with proper ipv6 support ? I'm not sure if such a thing exists yet. Mullvad had some initial support, but it doesn't work if you set up the router as the vpn client.

Thanks for bumping this.

I'm between two trips, so all I've had time for was to set up 6-in-4 he.net tunnel as wan6, but the moment I start OpenVPN client on my router I lose all IPv6 connectivity.

I probably need a policy to send all IPv6 traffic to WAN, but I really didn't have much time to investigate further. I need a significnatly dumbed-down intro to IPv6 to finalize the code. When I get back in a few weeks I'll try to borrow/read an IPv6 book at a local library.

Btw, just some unrelated point. How closely tied is this to openvpn ? Can openvpn be switched out ? Mullvad has some initial support for wiregurad. It would be nice if this stuff works with wireguard.

There's just one line of code which detects if an interface is a VPN tunnel or not:
is_vpn() { if [ -f "/sys/devices/virtual/net/$1/tun_flags" ]; then return 0; else return 1; fi; }

If wireguard interfaces have the same tun_flags file OPR should work OOB. If not, but there's another way of detecting wherever an interface is a wireguard interface, I can add that in.