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

I just want to confirm @dziny statement. The "pppoe-wan" interface name is setup automatically by LEDE on my setup as well and has always been like this.

Hello, I have a question regarding simultaneous use of openvpn client and openvpn server on my router. Currently I have installed and set up dd-wrt for my router, but it's still beta and since there's a stable lede version for my router I consider changing.
Right now I have openvpn client set up and one device (homeserver) go through the vpn tunnel.
Also a openvpn server is set up to connect to my devices from outside my lan.
Now if I do so, I can reach all my devices but the one device (homeserver) which goes through vpn tunnel.
(In dd-wrt theres a field called policy based routing where you can enter the desired ip)
I assume with your packages I can archive the same but how would I be able to reach that one device (homeserver) that connects through vpn tunnel to my vpn provider?
DD-Wrt Forums coldn't really help me, i just read that the vpn provider probably force-changes some gateway on the homeserver and technically I CAN reach the homeserver from outside/vpn tunnel but I can’t get any response because oft hat.
...I don't know if anyone at all understood what I'm trying to archive...

Should be fixed in build -13 of the OPR and the ICMP thingy is editable from WebUI in luci-app build -20 (set it to Default/No Change).

Answered above -- no.

Not sure I understood what you're trying to achieve but you can try setting specific local port to go to WAN interface -- that's how Plex Server can still be accessed from WAN even if by default the Plex Server Host is using VPN to connect outside.

Yeah, I think you got it. I only want the homeserver via vpn client to be connected to my vpn provider.
If I set it up like this and connect to my vpn server, the homeserver isn't reachable, all other devices are.
..You mean determine the lan port on my router where the homeserver is connected and set it "to go to" Wan interface?
Do you happen to know where the needed setting is?

I'm having trouble with the OpenVPN Policy-Based Routing web UI The web UI uses the all caps 'WAN' as a choice for interface. When I Save & Apply, the changes are saved to the config file as option interface 'WAN'. However when the openvpn-policy-routing service runs, I get this error:

ERROR: openvpn-policy-routing 5.0.1-13 unknown policy interface (WAN)!

When I edit the config file by hand to replace all 'WAN' with 'wan' everything works. Where should I look to get the UI to use the lowercase 'wan'?

1 Like

Ryan, thank you for the report and investigating the cause. This has been fixed in luci-app-openvpn-policy-routing_git-17.248.63230-2545566-21_all.ipk.

This has been fixed in luci-app-openvpn-policy-routing_git-17.248.63230-2545566-21_all.ipk.

Tested. Works. Thank you for the quick response.

If you know what services/ports do you need access to on your home server, you can define them in WAN policy.

@rcmarotz @stangri I think that might have been the problem I was describing up above! I'll have to test it out. I was doing my configuration in Luci and did notice the caps. However, I have multiple router builds. ONE of them does not report errors with unknown interface WAN, it shows it starts ok, the others have been having that problem. I hadn't thought of changing case in the config. I'll give the new pkg a try (as well as editing the config.). Is that on the custom repository for updating yet?

I have a secondary issue, on the one that isn't showing that problem. Maybe I'm just using it wrong. I created a guest wlan interface with the intention of using that interface (192.168.2.1) without access to the VPN. I configured a OVPR rule to send local 192.168.2.0/24 to WAN, but it appears to still be going to the VPN. It's possible that's still a case sensitivity issue, but that particular setup isn't complaining about unknown policy interfaces.

Have you tried achieving this with firewall config file -- just don't create a forwarding from guest to vpn, only create a forwarding from guest to wan?

Does anybody here have a writeup of how to go from a fresh install to working with this package? I have tried 2 times now and have been unsuccessful in getting it to work how I want. I always end up with dns issues. Last night I had it working in one part of the house where I have access to the console (monitor+keyboard) and I seemed to have gotten 1 computer to go through the vpn and everything else through the wan. Well I shut down the system and moved it to the main network location and when I fired it up again it failed. I ended up losing access to the wan when the VPN was up.

I use torguard as a vpn due to having exit geolocations that are actually in the city the server is in. There is no specific writeup for LEDE/openwrt so I take the DD-WRT and transfer the information to a LEDE compatible format.

I use https://wiki.openwrt.org/doc/howto/vpn.openvpn as a source to get the vpn working (which it does) but then trying to integrate OVPR it goes all haywire.

Anybody know of a better location for setting up VPNs than the one I posted? I feel like there might be some incompatibility between that setup guide and OVPR.

@stangri Good question, I hadn't done that as I was largely trying to play with OVPR. I set up that test and....seemed to have no internet access through the WAN on the guest. Which shouldn't be surprising for a full tunnel which should be redirecting through the tun0 interface. But I thought that's what OVPR was for, to offer a way around that default routing on a policy based criterion?

So right now I have several issues:
1: OVPR doesn't seem to route around a full tunnel? What configuration would you suggest at this point to enable OVPR the environment it needs to route?

2: The case sensitivity issue in Luci doesn't appear to be related. Both with all caps and all lower case, I keep getting the "unknown policy interface (wan)" {or (WAN)} error, despite that the Luci config sees the interface fine. You suggested the default route for 0.0.0.0 goes to the tunnel though I don't see anything specific in the networks config at all for that interface, which implies it's OpenWRTs default? What should I be looking at for this issue (which may relate to both issues?)

3: Inconsistency. I have 4 nearly identical router builds (two are going to be used for a bridge, one for a different network, and one for experimentation of configs.) OVPR seems to be behaving differently on different builds. On one I get the "unknown policy interface (wan)", on one I get "unknown policy interface (wan)" AND "unknown policy interface (myvpn)". It finds no interfaces (but found them in the Luci config.) On one everything is working normally, both interfaces are detected correctly. And I don't think I looked at the 4th one. All 4 builds are almost identical with the exception that things may have been installed/configured/started in different order sequence between each. One may have had OVPR installed before OpenVPN was installed, one may have had the VPN configured while the other did not have the VPN configured when OVPR was installed and configured. Order of operations seems to have a detrimental impact on OVPR. Is there a "proper" way I should install it? I don't mind deleting the VPN and/or removing the packages and starting from scratch to test it. How do I get a "clean" install of OVPR with proper routing tables in place the way OVPR wants to see them to initialize correctly?

What do you mean by "full tunnel"?

You're either setting yourself or pulling from OpenVPN server the routing information which prevents OPR from identifying the WAN interface. I'm currently testing a version of OPR which can still try to identify the WAN interface properly even when default routing is going to a VPN tunnel, I'll post it in when it's ready.

They must not be identical enough. :wink:

When using Luci and/or editing the config manually tunnel does not have to be up/active, however if it's still not up/active when you run the /etc/init.d/openvpn-policy-routing you will get unknown interface errors. Having said that, the fact that it cannot find both wan and vpn is definitely unexpected.

Now, regarding the "clean" install and "proper" routing -- that would depend on the routing entries your server sends down and wherever you accept them or not.

Currently OPR depends on the default route (genmask '0.0.0.0' in route) being set for WAN interface only. But like I said I'm working on some changes to that.

I am running the latest stable version of CHAOS CALMER (15.05.1, r48532) on a D-Link DIR-825 rev. B1. I have first installed and configured openvpn. All traffic was properly routed via the tunnel. Then I set route_noexe to remove the default route to the tunnel.

I manually (command line) added a default tunnel route for a new routing table with a rule that maches my local IP. Everything was fine and only my local IP was going over the tunnel all other traffic used the WAN interface. But of course I wanted to automate this with the help of stangri's package.

Now the openvpn-policy-routing 5.0.1-15 package + the corresponding LUCI package enter the stage. Install works as described. I get the following errors, but I guess these are not relevant for the policy routing package anyway:
Package libtins version v3.5-1 has no valid architecture, ignoring. Package noddos version master-1 has no valid architecture, ignoring.

I bring up the tunnel again and start the policy. I can see in the logs that everything is fine and the policy has setup a custom route to the VPN. BTW: Is there a manual on how to use and troubleshoot the package properly? I only found the readme that explains how to install it.

The effect of the policy routing service on the source IP that I have listed in the policy rule is a total block. I cannot access the Internet nor the Tunnel nor my router interface until I stop the policy again.

I'd appreciate hints on what is going on under the hood of this package and what I could to to track down my problem. I also cannot find any references to the source IP in the list of active iptables rules. How does the detection and marking of packages work?

It may be worth mentioning that I have custom firewall rules and that I put 'iptables --flush forwarding_lan_rule' at the beginning to rebuild all custom rules from scratch when restarting the firewall.

Thanks!

Tunnel gateway routing has to be set before policies targeting that tunnel can work. As of now, OPR does not alter the default routing table.

You can either set the tunnel gateway routing manually and then run OPR or you can accept routing from OpenVPN server and configure OPR to route local netmask to WAN and only single IP to OpenVPN tunnel.

The OpenVPN server does not push any routes. The standard OpenVPN client
script configures a default route to the tunnel after the tunnel is up. But
this is not what I want so I disabled it. I need to keep the default route
to my WAN inferface and I want OPR to setup a table based default route to
the tunnel just for specific source IPs (or other packets matching the
policy). For this I created exactly one policy that matches the local
source IP and that points to the tunnel.

Can you please elaborate what you mean by "configure OPR to route local
netmask to WAN and only single IP to OpenVPN tunnel"? This is what I
actually tried to do. I must admit that I am a bit lost on what OPC
actually does and how it interacts with the tunnel start and stop scripts
and the routing tables under the hood.

OPR does not change the default routing table. The default routing for the VPN tunnel has to be set up outside of OPR. If you disable exec/pull, you have to set up routing manually. You can then specify the policies for WAN/VPN routing, as in 192.168.1.1/24 for WAN and 192.168.1.119 for VPN.

It works by creating a new chain in the mangle table and within that chain by changing packets gateways based on policies.

I added a LAN policy for WAN with a /24 mask as suggested. This soft bricked my router as it did not accept any packets after that. I had to do a failsafe recovery and revert the config. Sorry to ask again but what type of route do I have to add manually and when? If OPR adds new routing tables based on policies how am I supposed to know in advance which routes to put for which table? And after the policy is activated I am locked out can cannot change the routing any more.

A section in the Readme that explains how to configure OPR and the routing tables would really help.

Oh, my bad, very sorry, that range included the router itself.

The routing for the tunnel gateway has to be set up outside of OPR. Whatever the OpenVPN client does to set up the routes or whatever you did manually to make sure the tunnel works -- it has to be set up outside of OPR.

Thanks for the clarification. Maybe I should explain better where I am
coming from. In another forum I read a post fom a guy that had issues with
script security for his OpenVPN client. The recommended solution in that
thread for someone that "does not want to mess with start or stop scripts"
was OPR. I am also on CC 15.05 release that cannot run scripts, because
script security is not implemented in LUCI. My workaround was to run my
policy routing script manually as part of my tests. I (at that time)
assumed that OPR would replace the scripts and interface with OpenVPN
directly.

I have now "reverse engineered" what OVP does and found out that it creates
new routing tables with IDs from 201 upwards. Iptables rules mark the
packet based on the policy and then the marker is matched to a routing
table ID. So what I have to do is to find out the relation between the rule
and the marker and the routing table ID. Then I have to manually add routes
for each routing table ID. Unfortunately, no word about this in the Readme.

So I have now learned that OPR will not solve my problem, it will "only"
give me more powerful policies with a nice GUI for it. If you have an idea
how I can patch my CC release version to support custom VPN start/stop
scripts I would really appreciate. The only solutions at the moment seem to
be either to ditch LUCI and do it outside the config management or to move
to a trunk version that does not have these limitations. Both is not
acceptable for my requirements so I am still stuck.