As the VPNBypass package was well received but was lacking ability to explicitly route specific traffic via OpenVPN tunnel instead of bypassing it, I've written a policy-based routing service.
Both vpn-policy-routing and luci-app-vpn-policy-routing are available from my repo: https://stangri.github.io/openwrt-repo/. After adding this custom repo to your router, you can install and upgrade both vpn-policy-routing and luci-app-vpn-policy-routing from the command line or Web UI like any other package.
If you have any problems, be sure to include the config file, as well as output of the service when it's being started/reloaded and the output of /etc/init.d/vpn-policy-routing support.
Thanks to feedback from @hnyman I've managed to re-organize both luci app and how the service works internally. I've also added a screenshot to the README so you can see what you're getting yourselves into.
From version 3.1 supports strict enforcement of policies when their gateway is down (resulting in network unreachable for affected policies).
Could be used if you want to ensure that the specific policy (I've only tested it with a single local IP) is routed thru specific gateway and has no connectivity when that gateway is down.
So openvpn-policy-routing seem to be reloading just fine on OpenVPN changes, so that seems to be working.
In 3.3 I've added support for domain-based routing and tweaked luci-app-openvpn-policy-routing.
Major changes in README (including the new screenshot) as well.
I consider it polished enough to send a PR to be published in the official repo/feed as soon as I get feedback from others (preferably with multiple OpenVPN tunnels).
Just installed openvpn-policy-routing (and its luci-app) on 17.01RC2 on a wrt1900acsv2.
Source port/ip routing is working.
Domain-based routing does not work no matter what I try. It's as if I don't have anything defined. Websites are still accessed per source ip/port policy.
@nidstigator, hey, thanks for testing it. I believe you've used vpnbypass in the past -- did you by any chance configure ipsets in dnsmasq when you were using it? If, with the openvpn-policy-routing stopped, you have any conflicting ipset entries in /etc/config/dhcp you have to remove those (those ending with /vpnbypass). If it turns out that was the source of the problem, I can add removal of these old ipsets into openvpn-policy-routing.
Can you modify your first rule to be /netflix.com/hbonow.com/whatismyip.com/tun0route and visit whatismyip.com 20-30 seconds after openvpn-policy-routing reload?
After the service is loaded, can you do grep ipset /etc/config/dhcp (actually, do it with the service stopped and service loaded, the result should be different) -- verify that it has exactly the same domain rules as you have in the openvpn-policy-routing config.
Also, please give it like 20 seconds after the openvpn-policy-routing reloads, as it restarts dnsmasq in background, it doesn't wait for dnsmasq to restart to report openvpn-policy-routing has started.
Not really, there're a few steps you can take to help me figure out what might be source of the problem.
Please post results of opkg list_installed | grep dnsmasq .
Please post results of grep ipset /etc/config/dhcp with service stopped and then results of the same command with service loaded.
Can you modify your first rule to be/netflix.com/hbonow.com/whatismyip.com/tun0route and visit whatismyip.com 20-30 seconds after openvpn-policy-routing reload?
Also -- do I take it that things worked well for domains with vpnbypass? Have you removed vpnbypass?
The multiple rules found in /etc/config/dhcp are due to your luci-app adding a rule to /etc/config/dhcp everytime i edit a rule, and not deleting them once i delete them using the app.
I might have pre-maturely pushed the domain-supporting version which didn't clean things up, but I've updated it shortly after. Sorry about that.
When you do /etc/init.d/openvpn-policy-routing stop, does it display destroying domain routes.. [OK]?
