VPN Policy-Based Routing + Web UI -- Discussion

One small annoyance I've been facing recently: when I reboot it seems that VPR starts up faster than my wireguard tunnels, default being WAN when VPR starts. That combined with strict enforcement makes internet inaccessible until I manually restart VPR. I fixed this with a sleep/VPR restart in local startup, but just wondering if there is a more elegant way of solving that?

Hi. Any idea why is not working? Openwrt 21.02.0 x86:

Wed Sep 29 07:25:18 2021 user.notice vpn-policy-routing [22278]: Creating table 'wan/eth5/xxxxxxxxxx' [✗]
Wed Sep 29 07:25:19 2021 user.notice vpn-policy-routing [22278]: Creating table 'VPN/10.2.0.6' [✗]
Wed Sep 29 07:25:19 2021 user.notice vpn-policy-routing [22278]: service monitoring interfaces: wan VPN [✓]
Wed Sep 29 07:25:19 2021 user.notice vpn-policy-routing [22278]: ERROR: Failed to set up 'wan/eth5/xxxxxxxxxxx [✓]' ERROR: Failed to set up 'VPN/10.2.0.6' ERROR: failed to set up any gateway!
config vpn-policy-routing 'config'
        option verbosity '2'
        option strict_enforcement '1'
        option src_ipset '0'
        option dest_ipset '0'
        option ipv6_enabled '0'
        list ignored_interface 'vpnserver wgserver'
        option boot_timeout '30'
        option iptables_rule_option 'append'
        option procd_reload_delay '1'
        option webui_enable_column '0'
        option webui_protocol_column '0'
        option webui_chain_column '0'
        option webui_show_ignore_target '0'
        option webui_sorting '1'
        list webui_supported_protocol 'tcp'
        list webui_supported_protocol 'udp'
        list webui_supported_protocol 'tcp udp'
        list webui_supported_protocol 'icmp'
        list webui_supported_protocol 'all'
        option resolver_ipset 'dnsmasq.ipset'
        option enabled '1'

config include
        option path '/etc/vpn-policy-routing.netflix.user'
        option enabled '0'

config include
        option path '/etc/vpn-policy-routing.aws.user'
        option enabled '0'

0.3.2-20 has been working great for me:

https://github.com/stangri/repo.openwrt.melmac.net/raw/60633b93804a77a15f49da77c27adb7f37c12ef9/luci-app-vpn-policy-routing_0.3.2-20_all.ipk

https://github.com/stangri/repo.openwrt.melmac.net/raw/60633b93804a77a15f49da77c27adb7f37c12ef9/vpn-policy-routing_0.3.2-20_all.ipk

Is there a way to automatic restart the vpn policy-based routing service when there is a service error?
With a script perhaps?

It may lead to a restart loop if you do automatically restart on error, but recent versions should properly set exit code upon success or failure.

2 Likes

I want to Routing youtube/facebook Traffic via VPN Tunnel. How? Please guide me

I have not updated in a few months and had the following experience:

I updated to OpenWrt 21.02.0 Stable - Kernel Version 5.4.143 today.

VPBR 0.3.5-3 did not allow the Netflix or Amazon Custom User Files to run. It produced an error for both. I tried using some older User Files but same issue.

I reverted to 0.3.3-20 but the 2 VPNs I have setup were not recognized and it produced errors that my policies did not have a valid gateways assigned. The VPN setup was OK in the latest 0.3.5-3 version.

I then reverted to the version (0.3.4-8) (both IPKs) I was using prior to updating OpenWRT and all is working fine now.

Just wanted to let the community know of my experiences in case it may assist someone in their issues.

I will wait a while and try a future VPBR version to see if the issues have been resolved, at least for my setup.

1 Like

I'm very short on time in September/October.

Anyone on 19.07 can try a bunch of 0.3.2 and post 0.3.2 versions and confirm what's the latest version which reliably works on 19.07?

I can then revert the 19.07 to that version, 21.02 to 0.3.4-8 and continue development for 21.02 and master in the different package.

Thanks!

honourable mention from Mr Van Tech Corner himself!

3 Likes

Anyone still having issues with the 0.3.x version, could you please try the 0.3.4-8 kindly linked by @megit above?

I had this same problem because (you probably won't believe this) I didn't have a wireless network on the VPN. As soon as I turned one on, it started perfectly. I can hardly believe it myself, but it took me hours (and several restores from backups) until I figured it out. I hope this works for you. If so, let us know because I'm still scratching my head over this.

Hi, ToasterDEV
Sorry for the delay. Might we want to check if the ipset
PIA_US_Texas is effectively populated by running the command ipset --list PIA_US_Texas via ssh terminal or placing ipset --list "$TARGET_IPSET" > /tmp/ipsetontarget before the line rm -f "$TARGET_FNAME" ? This shall show us if the script is working as it should. You might also want to check the original script on which that "file is heavily based on". As far as I understand, the script populates the desired ipset and vpn-policy-based-routing will route the traffic to the target_ipset's interface. @anon50098793's posted video will probably help.

Sorry for not giving more precise instructions; I am not familiarized with that specific scenario.

"vpn-policy-routing 0.3.5-7 running on OpenWrt 19.07.8." (r11364-ef56c85848) works fine (at least for me) since previously reported.

1 Like

Hello fefu!
Don't worry, it seems I was able to get things to work with version 0.3.4-8. For the moment, I'm able to reliably route things through VPN-PBR when concerned with the custom user files, the only problem I have currently is that I'm unable to actually get to the websites that are being routed.

If I disable the custom .user file, the website loads correctly, and I'm able to ping it without issue

❯ ping vrv.co

Pinging vrv.co [65.9.148.128] with 32 bytes of data:
Reply from 65.9.148.128: bytes=32 time=11ms TTL=246
Reply from 65.9.148.128: bytes=32 time=9ms TTL=246
Reply from 65.9.148.128: bytes=32 time=10ms TTL=246
Reply from 65.9.148.128: bytes=32 time=10ms TTL=246

Ping statistics for 65.9.148.128:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 9ms, Maximum = 11ms, Average = 10ms

However, if I enable the file the addresses become unreachable

❯ ping vrv.co

Pinging vrv.co [65.9.148.62] with 32 bytes of data:
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.

Ping statistics for 65.9.148.62:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

I'm not sure if this is down to the FORWARD or OUTPUT handling of the IPSET, but perhaps changing this would let me actually connect to the websites as intended. Even still, I have no idea on how I would begin doing that.

Thanks for the help, and I'll keep you posted if I find out anything new on regards to this problem.

Also, I forgot to add. The VPN itself seems to have an active connection according to the following pings

root@OpenWRT-RPi / > ping -I ovpnc0 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=56 time=83.024 ms
64 bytes from 1.1.1.1: seq=1 ttl=56 time=76.887 ms
64 bytes from 1.1.1.1: seq=2 ttl=56 time=79.509 ms
64 bytes from 1.1.1.1: seq=3 ttl=56 time=76.174 ms
64 bytes from 1.1.1.1: seq=4 ttl=56 time=79.368 ms
64 bytes from 1.1.1.1: seq=5 ttl=56 time=76.833 ms
^C
--- 1.1.1.1 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 76.174/78.632/83.024 ms
root@OpenWRT-RPi / > ping -I ovpnc0 vrv.co
PING vrv.co (65.9.148.37): 56 data bytes
64 bytes from 65.9.148.37: seq=0 ttl=236 time=123.035 ms
64 bytes from 65.9.148.37: seq=1 ttl=236 time=118.630 ms
64 bytes from 65.9.148.37: seq=2 ttl=236 time=121.277 ms
64 bytes from 65.9.148.37: seq=3 ttl=236 time=117.918 ms
64 bytes from 65.9.148.37: seq=4 ttl=236 time=119.879 ms
64 bytes from 65.9.148.37: seq=5 ttl=236 time=121.628 ms
^C
--- vrv.co ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 117.918/120.394/123.035 ms

Took a leap into 0.3.4-8 and can report it seems to be working well, as expected.

1 Like

Any change with the Netflix custom user file, does it work now?

Sadly, 0.3.4-8 was never merged into packages as there was a very heated discussion about the version numbers which was never resolved: https://github.com/openwrt/packages/pull/15815.

So I can't downgrade by cherry-picking commit to master like I just did with 19.07.

I'll try to create a new downgrade PR.

1 Like

I am having some problems adapting the NetFlix Custom User File for setting up 2 other Custom User files to route the German ARD and ZDF IP ranges to a VPN IP Set ("2_DEU_VPN_F" = an OpenVPN VPN Interface on tun2).

I made the following changes to the NetFlix Custom User File creating 2 additional Customer User Files that should run when VBR starts up.

ARD:

TARGET_IPSET='2_DEU_VPN_F'
TARGET_ASN='43623'

ZDF:

TARGET_IPSET='2_DEU_VPN_F'
TARGET_ASN='43354'

The problem is that when I only select one of these 2 Custom User files it all works fine. When I try to run both of them, the second one generates an error in VBR and the IP Set is not setup for the second Custom User File.

Any ideas on what I am doing wrong and how to get this to work?

It may be failing to download the second file if the selected DB_SOURCE is blocking fast consecutive downloads or it may be producing an invalid file for ipset to import.

I've just pushed a commit to my source repo which may make it a bit easier to debug: https://github.com/stangri/source.openwrt.melmac.net/blob/d5263efb9f6ebfa5f7ef0a84073c2abe635e55f1/vpn-policy-routing/files/vpn-policy-routing.netflix.user

Then change the user file from:

if [ -s "$TARGET_FNAME" ]; then
	if awk -v ipset="$TARGET_IPSET" '{print "add " ipset " " $1}' "$TARGET_FNAME" | ipset restore -!; then
		_ret=0
	fi
fi

rm -f "$TARGET_FNAME"

to:

if [ -s "$TARGET_FNAME" ]; then
	if awk -v ipset="$TARGET_IPSET" '{print "add " ipset " " $1}' "$TARGET_FNAME" | ipset restore -!; then
		_ret=0
		rm -f "$TARGET_FNAME"
	fi
fi

(or just delete the line rm -f "$TARGET_FNAME") and if the $TARGET_FNAME file exists and non-zero after vpr is restarted, set the variables on CLI and try to import it to ipset (with awk -v ipset="$TARGET_IPSET" '{print "add " ipset " " $1}' "$TARGET_FNAME" | ipset restore -!) and see what ipset error is.

Hi everyone, I'm very new to these networking...

I'm running OpenWRT 21.02 on a small x86 box.
The latest version on the repo (0.3.5-1) doesn't work for me either (ERROR: failed to set up any gateway!) but manually installing 0.3.4-8 works.
I was able to route my Guest network through NordVPN gateway but on my network there is another DS-Lite (ipip6 tunnel) interface that I also want to route a range of IP on my main LAN network through (it is much faster than PPPoE connection here in my region).

Is it possible at the moment since I didn't see any option to select that DS-Lite interface?

Thing is if I set the DS-Lite interface as the default gateway then all outbound traffic would go through it but then I couldn't connect to the PPPoE ip address out from the internet, pinging the IP would also not returning anything, and my personal self hosted websites become inaccessible.

Thanks!