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

Understood but I tested from an static IP that should have gone through a VPN and it did not work. I will test again tonight.

@stangri

Tested again and OPR 5.0.1-5 does not work for me but OPR 5.0.1-1 works fine.

See PM for a link to the "support -d" output for working setup (OPR 5.0.1-1) then 2 files for OPR 5.0.1-5 on reboot and then reload.

Maybe it is something unique to my setup that you can point out to me.

Yo @stangri

I just upgraded from a very old build that was working- except It stopped recognising new websites I've been adding.

The latest build 5.0.1-5 totally breaks the remote addresses function for me.

I am using your new config format, deleted ipset etnries in dhcp file, and the result is that basically hbonow.com doesn't work. I have to add every single sub domain that hbonow.com loads..

Is there a workaround for this?

I tried uci set openvpn-policy-routing.config.ipset_enabled=0; uci commit;

I get this:
uci: Entry not found
uci: Entry not found
uci: Entry not found
uci: Entry not found
uci: Entry not found
uci: Entry not found
uci: Parse error (invalid command) at line 2, byte 0

and still. same behaviour.

Help?

Post/PM OPR config file.

Rushed 5.0.1-5 out, everything is fixed in 5.0.1-7.

Correction- I am running 5.0.1-7.

Let me know if you want me to test anything :slight_smile: I can certaintly do so tonight and over this weekend!

Got your PM, I don't see anything abnormal in there. Can you try removing both luci-app and OPR, backing up current config, updating opkg and installing OPR + luci app and re-creating config again?

I'll also reply privately.

So I've tested a few options by going back and forth between them and I do like using dnsmasq-full's support of ipset for two reasons:

  1. It speeds up the start up time dramatically because dnsmasq resolves domain names in its ipsets in the background/on request.
  2. It affects all third-level domains for domain in policy. So if domain.com is set in the policy, all of *.domain.com will be routed thru the same policy.

Because by default only dnsmasq included in LEDE (and not dnsmasq-full) you have to opt into using dnsmasq by OPR. If the dnsmasq use is not enabled in OPR, it can create policies thru iptables and/or its own ipsets (a bit slow to start as it resolves each individual domain on start).

I have updated both OPR and its Luci app to reflect the changes. If you're using my repo, run: opkg update; opkg upgrade openvpn-policy-routing luci-app-openvpn-policy-routing.

1 Like

@stangri

With the latest version of OPR 5.0.1-12, When I have my local lan set to go through the wan interface I can no longer access the router via web interface.

@stangri @jvquintero1021 I can confirm this issue. Syslog shows to following error for every policy rule routing to wan interface:
user.notice openvpn-policy-routing [10454]: ERROR: service unknown policy interface (wan)!

This is my first time using this package, but I'm guessing the last changelog showing the update to use interface names instead of device names has something to do with this.

Edit: On second thought I just re-read and realized this may be a different issue! Oops! Your issue is worse, my issue just means policy-routing doesn't actually do anything. :slight_smile:

@stangri

I guess a little more info i could provide, im just not sure what will help in t/s my problem but I am able to set individual IP address to go through wan. The Issue is when I try to use 192.168.1.1/24 as my local address. That is the default subnet for my router. I have another subnet 10.0.0.1/24 that I am able set it to go through the tun0 interface.

Can you try excluding the 192.168.1.1 from the range by moving your devices higher in the last octet and creating a different policy?

The way OPR detects WAN interface is dependent on the default routing set up before you start OPR. This error probably means that your default route for 0.0.0.0 is set to go to the VPN tunnel, making OPR unable to discover WAN interface.

Once OpenVPN policy routing is enabled, pinging the router or any host on the internet from inside LAN stops working. If I disable the ping starts working again. Ping interface is set to WAN in openvpn policy routing config. Traceroute also stops working.

If I login directly into the router, traceroute and ping works fine but not from devices in LAN network.

Not sure what else to check. Below is the config.

root@router:~# cat /etc/config/openvpn-policy-routing

config openvpn-policy-routing 'config'
option ipv6_enabled '1'
option ipset_enabled '1'
option strict_enforcement '0'
option enabled '1'
option dnsmasq_enabled '1'
option icmp_interface 'wan'
option verbosity '2'

config policy
option interface 'VPN_1'
option comment 'Reddit'
option remote_addresses 'reddit.com'

Any help would be appreciated.

Hmm, interesting, wan does show up in the LuCi config screen however, so OPR seems to be aware of its existence at least in the LuCi tool, but maybe it's just scanning the interface list in there?

I'll have to figure out what might be going wrong with the default route. I just realized I have two identical router builds in progress, and on one OPR has this problem, and on the other it doesn't. Yet both builds are nearly the same and are connecting to the same VPN with the same settings. Neither are accepting pull in the OVPN setup. Any tips for what to look for?

Might be the wrong place for this but I wanted to leave the idea of a future feature suggestion if you're ever extending OPR: mime type policy. I was using as a test youtube separation (no reason for video to go through the tunnel after all), and realized that youtube.com/youtu.be filtering doesn't actually work on the video streams that come from Google's myriad of IP ranges for Youtube (and/or other services.) So there's no way to filter it without Docs also going over WAN which should be going over VPN (and even then no way to really policy out all of Google's IPs.) It occurred to me mime type filtering would be super helpful here, though I also realize that involves a whole different depth of connection filtering and probably won't happen. But I wanted to leave the suggestion all the same!

I did also notice this when I try to do a reload

Creating table 'wan/eth1.2/100.37.4.1/::/0' ip: RTNETLINK answers: File exists
[✗]
Creating table 'tun0/tun0/10.68.10.5/fe80::c651:2c6a:fcc9:1' [✓]
Routing 'Plex Local Server' via wan [✓]
Routing 'Plex Remote Servers' via wan [✓]
Routing 'WAN' via wan [✓]
Routing 'VPN' via tun0 [✓]
openvpn-policy-routing 5.0.1-12 started tun0/tun0/10.68.10.5/fe80::c651:2c6a:fcc9:1 ✓

Maybe this has something to do with it. As for excluding 192.168.1.1, I am able to individually assign IP's to go through what ever interface I want whether its WAN or TUN*, as well as any other subnet as long as its not the default subnet the router is using.

So for example:

LAN subnet: 192.168.1.1/24 - In OPR I can assign individual IP's to go through wan, but not the 192.168.1.1/24 subnet itself. Keep in mind that when I do try to set 192.168.1.1/24 as a policy after submitting save & apply the actual policy is working as my LAN devices now go through the WAN interface, But i'm unable to access the LUCI web interface. Still able to access the router via SSH.

VPN subnet: 10.0.0.1/24 - This subnet I use on a separate WLAN interface for devices I want to automatically connect to the VPN. If I set this as a OPR policy to go through the TUN* interface that is working perfectly fine.

I'm seeing 2 issues with the latest version.
Fist I'm getting an error when creating wan table

root@LEDE:~# /etc/init.d/openvpn-policy-routing start
Creating table 'ukvpn/tun0/10.8.0.1/::/0' [✓]
Creating table 'atvpn/tun1/10.22.100.13/::/0' [✓]
Creating table 'wan/pppoe-wan/84.16.59.41/::/0' [✗]

Also all policies that use wan are not working even though

Routing 'horizonTV' via wan [✓]

they seems to be created.
Second issue is that after openvpn-policy-routing is started the router is unable to ping any device on my default 192.168.0.1/24 network. Similarly, the router is no longer pingable within the network. If it stop the openvpn-policy-routing it goes away. I think this is something already mentioned above.

Also is there a place I can get the old v4 version?

Martin, remove the dash from the interface name, ipset doesn't like dashes
and for some reason I thought they were not allowed in the interface names
as well. I'll fix it in the next build.

As far as icmp issue, I wanted to test it a bit more before making any
changes, but for now you can manually remove icmp setting from the config
file in ssh session. Sadly using web ui app will bring it back which I will
also fix.

I'm away from home until after a labour day, I'll address all issues when I
get back.

The thing is the dash is added automatically to the interface name, it's not me my doing it. Whenever you have pppoe pr pppoa connection lede will assign it name pppoe-wan or (wan2) etc. Similar thing with connection over 3g dongle, it's lede name will be 3g-wan. Don't think I can change it.