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?

Sorry, this was a routing configuration issue from my vpn settings.

    option route_nopull '1'
    option route '0.0.0.0 0.0.0.0 vpn_gateway [metric_number]'

did the trick.

Policy-based routing working 100% with multiple tunnels.

1 Like

Including domains? I know it may sound like a silly suggestion, but if you haven't yet -- try rebooting the router to make sure all the tables properly reset and then get re-created on boot.

If you're using version past 3.3.1 -- the domains policies are defined differently in config file.

Just to clarify -- you did that on tun0 or tun1 config?

On both. No default vpn routing settings are applied if you do that.
I haven't tried domain-based routing, but will try now that i've sorted my routing table out and let you know.

rebooted multiple times during debugging, nothing to do with resetting or anything. It was openvpn enforcing routing without the settings I posted earlier.

I am using 3.3.1-5 and deleted the config file after uninstallation of previous version.

Also- in general, the domain-based routing editing through the luci-app is still funky. Just tried deleting a domain rule, save and apply, went to /etc/config/dhcp, and it was still there.

Yeah, while the current implementation of domains-based routing works when the policies are pre-set sucks when it comes to editing them, I'm seeking the feedback from better minds on how to improve it.

Has nothing to do with luci app -- it's how the openvpn-policy-routing handles the reloads.

Hope you get it sorted. Just tried the domain-based again: didnt work.

However, this leads me to question. Is policy-based routing supposed to suppress domain-based routing?

As far as I understand things -- domain-based routing is higher priority than policies. You can however, resolve domain and add all of its IPs into regular policy to test.

In version 3.3.5 I got rid of relying on dnsmasq for domains ipsets and domains ipsets are now managed internally. Because of this, please run: sed -i '/ipset/d' /etc/config/dhcp; /etc/init.d/dnsmasq/restart before upgrading.

There're two options: to have ipset grab just the first IP for domain, you don't have to do anything with your existing config, but overall domain-based routing could be unreliable (also, ipset doesn't seem to like domains with a dash in them, like lede-project.org). If you want to resolve each domain name and insert all of its IPv4 addresses to ipset, you need to do:

uci set openvpn-policy-routing.@domain-policy[0].resolve='1'
uci commit openvpn-policy-routing

before or after upgrade. If you have bind-dig installed (opkg update; opkg install bind-dig), overall resolution of the domains is 5-6 times faster than relying on busybox'es nslookup. Unless I find a fast native solution to resolve domain names, I'm contemplating adding bind-dig as a required package, even tho it requires libopenssl which is pretty heavy.

The domain-based policies should now affect all connected devices in the network irrelevant of dnsmasq configs. You can however specify individual ipsets in dnsmasq configs instead of openvpn-policy-routing config and to be honest dnsmasq's handling of ipsets is more elegant and efficient, especially for large lists.

There's a small change in luci app as well, so please upgrade it.

You know what, I kept the code to handle domain-based policies inside the openvpn-policy-routing, but in the latest luci-app I just switched to editing the dnsmasq's ipsets.

It works quite well for me, so please test this, if that works (or at least if this isn't worse) than having opevpn-policy-routing manage domain-based policies, I'll probably remove the domain-based routing from opevpn-policy-routing altogether. I cannot envision a situation where OpenVPN will be present on the router, but dnsmasq will not be.

[quote="stangri, post:39, topic:1422"]
I cannot envision a situation where OpenVPN will be present on the router, but dnsmasq will not be.
[/quote]Well, some people use unbound for DNS and isc-dhcp or odhcpd for DHCP (also ipv4), or other alternatives to dnsmasq. But yes, dnsmasq is the default.

1 Like

I'm trying to test this but I can't get my openvpn route to have metric 20. Here is my config

config openvpn 'ukvpn'
        option enabled 1
        option nobind '1'
        option client '1'
        option reneg_sec '0'
        option verb '1'
        option persist_tun '1'
        option persist_key '1'
        option remote_cert_tls 'server'
        option dev 'tun-usvpn'
        option proto 'udp'
        option ca '/etc/openvpn/ca1.crt'
        option cert '/etc/openvpn/client1.crt'
        option key '/etc/openvpn/client1.key'
        option tls_auth '/etc/openvpn/static1.key'
        option route_metric '20'
        option route_nopull '1'
        option route '0.0.0.0 0.0.0.0 vpn_gateway 20'
        option remote 'xx.xx.xx.xx'
        option port '443'
        option cipher 'AES-128-CBC'
        option comp_lzo 'yes'
        option resolv_retry 'infinite'
        option key_direction '1'

But starting openvpn results in

default         10.8.0.1        128.0.0.0       UG    0      0        0 tun-ukvpn
default         xx.xx.xx.xx   0.0.0.0         UG    10     0        0 eth1.2
10.8.0.0        *               255.255.255.0   U     0      0        0 tun-ukvpn

I am expecting to see metric 20 on the tun-ukvpn interface but not getting it. The vpn itself work but it does not allow me to do what I need.