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

are you adding the target at the end?

example:
Added support for routed domains in format /domain1.com/domain2.com/gwroute where gwroute could be wanroute, tun0route, etc.

yes, had:
/netflix.com/hbonow.com/tun0route
/showip.net/wanroute

Logs (restarting openvpn && reapplying settings for openvpn-policy-routing):

http://pastebin.com/1UsxiR31

@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.

Thanks for responding.
I have used mwan3 1-2 months ago, and gave up on it due to issues with recent builds of LEDE. (won't detect tun0 interfaces)

Like you said, I had some leftover ipset rules in dhcp file.

However, deleting these, reloading service with your rule, I don't see any rules being added /etc/config/dhcp.

Tried disabling-enabling service and still nothing.

Any ideas?

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?

Never mind, figured it out:

I uninstalled your packages, cleared up all ipset rules from /etc/config/dhcp, and reinstalled your package.

Added: /netflix.com/hbonow.com/whatismyip.com/wanroute, reloaded service.

grep ipset /etc/config/dhcp outputs:
list ipset '/netflix.com/hbonow.com/whatismyip.com/wanroute'

tried visiting above sites, they still go through tun0 (where I want them to go through wan)

Also, I have never used vpnbypass.

Observation:

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]?

If not, just install the current version from https://github.com/stangri/Files

1 Like

here is the output of /etc/init.d/openvpn-policy-routing stop :
destroying table wan/eth0/82.29.57.1 TID=200 FW_MARK=0x010000 IP_SET=wanroute [OK]
destroying table VyprVPN/tun0/10.2.28.241 TID=201 FW_MARK=0x20000 IP_SET=tun0route [OK]
destroying domain routes. [OK]
removing policy routes... [OK]
service stopped
Command failed: Not found

Can you do this: VPN Policy-Based Routing + Web UI - ARCHIVE #1

Thanks for finding this out, I'll have a look at the app later today.

Also I am using the latest build from 9 hours ago.

Stopping the service from command line does delete the rules from /etc/config/dhcp.

stopping it from the luci-app does not.

Also, domain-based routing still not working here.. made sure the only rule in /etc/config/dhcp is the only one i mentioned earlier!

opkg list_installed | grep dnsmasq :
dnsmasq-full - 2.76-6

(using command line to stop/start service):
grep ipset /etc/config/dhcp (before start):
list ipset '/netflix.com/hbonow.com/whatismyip.com/tun0route'

grep ipset /etc/config/dhcp (after stop):
(blank)

modifying the rule to /netflix.com/hbonow.com/whatismyip.com/wanroute (with no other rules, domain or ip-based) still get the vpn ip when visiting whatismyip.com.

like I said, never used vpnbypass before

Grasping for straws here until I have more time to investigate -- I've noticed you have two DHCP ranges in dnmasq config -- is domains-based routing not working for both of them?

Maybe it's dnsmasq not liking ipset with number in the name, let me test locally and get back to you.

Hey man! You're right. The other DHCP range I have defined (for my guest isolated wifi network) applies the domain-based routing correctly... at least from what I tested so far.

Huh? how come?

1 Like

Whew, thank you so much for testing and finding this bug! It's because I'm only adding the ipset rules to the last dhcp.dnsmasq config, that's why. Which in retrospect is not the brightest idea I've had yesterday.

Since the dnsmasq entries are not named, it would be hard to create a sensible UI to target a specific dnsmasq entry with ipset rules, so a choice would be adding ipset rules to first one, last one or all.

I'll introduce a setting for targeting only first dnsmasq entry, last dnsmasq entry or all dnsmasq entries a bit later, for now I've pushed the build which targets first. Would it solve the problem for now?

PS. I've also fixed the bug you've found earlier with luci app duplicating the ipset entries on update. luci-app is innocent, install the new openvpn-policy-routing ipk.

I've pushed 3.3.1 with a bit more elegant handling of different dnsmasq configs. It now properly allows you to target first or last one (targeting all is not supported).

Sadly, to make the 3.3.1 future-proof (so that in the future you could have multiple different policies targeting different dnsmasq configs) I've had to make it config-incompatible with any previous version, so before installing 3.3.1 remove your current config file: rm -f /etc/config/openvpn-policy-routing .

Or just add the following lines to /etc/config/openvpn-policy-routing manually before/after upgrade:

config domain-policy
	option dnsmasq 'first'

3.3.1 also requires updated luci-app-openvpn-policy-routing.

PS. 3.3.1-3 understands openvpn-policy-routing.@domain-policy[0].dnsmasq set to first, last, -1 or a number and validates dnsmasq section with this number exists before trying to insert ipsets.

1 Like

Huge thanks to @dibdot who shared a great tip on more reliably obtaining WAN gateway on boot. From 3.3.3 forward openvpn-policy-routing should reliably start on boot.

The only piece of code I'm not quite happy with is how integration with dnsmasq is handled for ipsets.

Hi there! thanks for the update.
I still can't get it to work on any device connected to eth1 (br-lan), but still works on the other isolated interface.

However, I stopped trying today. I decided to revert to policy-based for now and occasionally try the domain-based routing.

I have an issue that I cannot seem to be able to solve.

I have two tun interfaces, tun0, tun1. No matter what I try, cannot get any policy to the tun1 interface to work. I have tested the tun1 interface on its own (only tun1 up, tun0 down and openvpn-policy-routing shut down), and the connection works.

However, when I try to specify a subnet to go through tun1, the subnet doesn't have any internet connectivity.

Here are some log info:

Mon Feb 13 15:56:38 2017 user.notice openvpn-policy-routing [18007]: creating table wan/eth0/82.29.57.1 TID=200 FW_MARK=0x010000 IP_SET=wanroute [OK]
Mon Feb 13 15:56:38 2017 user.notice openvpn-policy-routing [18007]: creating table VyprVPN/tun0/10.2.28.189 TID=201 FW_MARK=0x20000 IP_SET=tun0route [OK]
Mon Feb 13 15:56:38 2017 user.notice openvpn-policy-routing [18007]: creating table PIAUK/tun1/10.3.10.5 TID=202 FW_MARK=0x40000 IP_SET=tun1route [OK]
Mon Feb 13 15:56:38 2017 user.notice openvpn-policy-routing [18007]: routing 'LAN' via wan (192.168.1.1/24 to ...) [OK]
Mon Feb 13 15:56:39 2017 user.notice openvpn-policy-routing [18007]: routing 'Guest' via wan (192.168.3.1/24 to ...) [OK]
Mon Feb 13 15:56:39 2017 user.notice openvpn-policy-routing [18007]: routing 'US' via tun0 (192.168.4.1/24 to ...) [OK]
Mon Feb 13 15:56:39 2017 user.notice openvpn-policy-routing [18007]: routing 'UK' via tun1 (192.168.5.1/24 to ...) [OK]
Mon Feb 13 15:56:39 2017 user.notice openvpn-policy-routing [18007]: routing 'XboxPort2' via tun0 (192.168.6.1/24 to ...) [OK]
Mon Feb 13 15:56:39 2017 user.notice openvpn-policy-routing [18007]: service started with gateways: wan/eth0/82.29.57.1 VyprVPN/tun0/10.2.28.189 PIAUK/tun1/10.3.10.5

Any ideas where the culprit might be?