I forced install your luci-app version and now config is working but I am still getting errors on netflix file. I allowed execution of the file with chmod +x and then executed it manually on terminal and it did not produce any errors but when I restart VPBR it shows following:
root@AhmarRouter:~# service vpn-policy-routing restart
Creating table 'wan/pppoe-wan/182.185.128.1' [✓]
Creating table 'openvpn/tun0/10.246.60.237' [✓]
Routing 'Hub' via openvpn [✓]
[✗]
vpn-policy-routing 0.3.2-4 started with gateways:
wan/pppoe-wan/182.185.128.1 [✓]
openvpn/tun0/10.246.60.237
ERROR: Error running custom user file '/etc/vpn-policy-routing.netflix.user'
vpn-policy-routing 0.3.2-4 monitoring interfaces: wan openvpn [✓]
im sorry if my english is bad but i have issue
so i was using openvpn for long time go, but the problem is i can access some web like "e-banking, ecommercie etc"
i cant access web like that from other country with "openvpn"
so can i use vpn-policy for separate traffic when i access web like that use my local isp and the other use tunnel openvpn?
how to configure it?
thanks
@stangri Thanks for this package and for keeping it maintained.
Some observations from my experience:
I started out trying to configure VPN Policy Based Routing on a 18.06 image for my router with a bunch of packages pre-installed (like wireguard.) I spent DAYS trying to figure out why nothing worked as expected and then scrapped everything and flashed a clean 19.07.6. With a clean install, I added only wireguard and PBR and everything was so easy and worked as expected! For those who find inexplicable problems. know that it might be caused by a spanner in the works somewhere outside this package itself.
After the initial success, I installed mwan3, and then things starting behaving strangely. Just having the package installed, without configuring it caused unexpected behavior. After I removed mwan3, expected functionality was restored. I'll have to figure out how to configure that at a later time (I want to use an LTE dongle for backup connectivity, )
My pretty simple use case:
Route all traffic for all connected devices through a WG interface as default (with a peer in country A.)
Exclude a few sites from WG that need to access the net directly.
Have a 2nd WG interface with a peer in country C, for a few sites that need access from that geolocation, and as backup in case the first peer is down or slow.
I'm posting relevant snippits of my configs below just for others who are trying to do the same. I guess nothing earth-shattering here, but took me some time to figure out.
config interface 'Wireguard'
option proto 'wireguard'
list addresses '<redacted>'
option private_key '<redacted>'
config wireguard_Wireguard
option public_key '<redacted>'
option description 'HK1'
option persistent_keepalive '25'
list allowed_ips '0.0.0.0/0'
list allowed_ips '::/0'
option endpoint_host '<redacted>'
option route_allowed_ips '1'
config interface 'WireguardTW1'
option proto 'wireguard'
list addresses '<redacted>'
option private_key '<redacted>'
config wireguard_WireguardTW1
option public_key '<redacted>'
option description 'TW1'
option persistent_keepalive '25'
list allowed_ips '0.0.0.0/0'
list allowed_ips '::/0'
option endpoint_host '<redacted>'
/etc/config/vpn-policy-routing
/etc/config/vpn-policy-routing
config policy
option interface 'wan'
option name 'Google Cloud'
option dest_addr '<redacted>'
#exclude traffic to this domain from the WG tunnel
config policy
option dest_addr 'youtube.com'
option interface 'WireguardTW1'
option name 'YT TW test'
#sends traffic for this site to a separate WG peer
config policy
option interface 'wan'
option enabled '0'
option name 'MBA'
option src_addr '192.168.1.9'
#reroutes traffic from an entire device, which has been given persistent LAN ip, (currently marked disabled)
I would say just be careful and take your setup slow, one step at a time. Personally I build my own images, I include Wireguard and MWAN3 in my build by default and I use VPR. All is working as expected for me, couldn't be happier. First thing is to make sure it's all disabled before you start, then setup WG, make sure zones are correct. Then setup MWAN3 for balance or fail over (I used both but settled on failover), then at the end setup your VPR rules.
Good advice. Do you do anything different with VPR rules when you are using MWAN3? in the VPR doc it mentioned changing -append mode to -insert or for compatibility, but didn't see much else.
Nope, most is default except for me turning on a few visual options like enable/disable and and show protocol. Seems to be working pretty good for me. I am using IP based routing at the moment and the target for those devices is a WG tunnel, I haven't started with pointing to specific WAN interfaces as I am using my setup as a failover, not a load balance.
Oh interesting. I have it setup so that traffic goes through WG by default, but with MWAN installed, traffic was routed through the naked WAN inexplicably. Unless I tried to access sites that are blocked my country and then that traffic would be routed through WG.
I am a new user of vpn-policy-routing and was looking for some help. I was hoping to have a vpn setup as default for all devices and then bypass specific device ip addresses to route directly through the router. I have tried following the wiki but I am unable to get my laptop to route through the openvpn connection and instead only routes through the current router default setup. I have just reset my setup and have only added files/packages relevant to vpn-policy-routing and have not touched/edited any of the wan/lan settings. Either a point to a previous post that deals with this issue or a simple tip would be greatly appreciated. I cannot see an attach button for the message so I am including the text instead for the files where I have added the portions from the wiki.
/etc/config/firewall
config zone
option name 'vpnclient'
option network 'vpnclient'
option input 'REJECT'
option forward 'ACCEPT'
option output 'REJECT'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'vpnclient'
config zone
option name 'vpnserver'
option network 'vpnserver'
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option masq '1'
config forwarding
option src 'vpnserver'
option dest 'wan'
config forwarding
option src 'vpnserver'
option dest 'lan'
config forwarding
option src 'vpnserver'
option dest 'vpnclient'
config rule
option name 'Allow-OpenVPN-Inbound'
option target 'ACCEPT'
option src '*'
option proto 'tcp'
option dest_port '1194'
/etc/config/network
config interface 'vpnclient'
option proto 'none'
option ifname 'ovpnc0'
config interface 'vpnserver'
option proto 'none'
option ifname 'ovpns0'
option auto '1'
/etc/config/openvpn
config openvpn 'vpnclient'
option config '/etc/openvpn/us8040udp.ovpn'
option enabled '1'
config openvpn 'vpnserver'
option port '1194'
option proto 'tcp'
option server '192.168.200.0 255.255.255.0'
/etc/config/vpn-policy-routing
config vpn-policy-routing 'config'
option verbosity '2'
option strict_enforcement '1'
option src_ipset '0'
option dest_ipset 'dnsmasq.ipset'
option ipv6_enabled '0'
list supported_interface 'vpnclient'
list ignored_interface 'vpnserver wgserver'
option boot_timeout '30'
option iptables_rule_option 'append'
option iprule_enabled '0'
option webui_chain_column '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 enabled '1'
option webui_enable_column '1'
option webui_protocol_column '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'
config policy
option name 'OpenVPN Server'
option interface 'wan'
option proto 'tcp'
option src_port '1194'
option chain 'OUTPUT'
option enabled '0'
config policy
option interface 'vpnclient'
option src_port '1197'
option name 'laptop'
option src_addr '192.168.1.230'
Note that my vpn provider gives a .ovpn configuration file where I have made a couple changes to mimic the edits mentioned in the wiki needed for the /etc/copnfig/openvpn file. Specifically I added these lines to the ovpn configuration file:
dev_type tun
dev ovpnc0
proto udp
remote <redacted> 1197
pull-filter ignore "redirect-gateway"
If you need general guidance with OpenVPN setup, it's outside of the scope of this thread, but for your needs, you need to remove pull-filter ignore "redirect-gateway" from ovpn file.
Ah, okay. I think I was misunderstanding how your package works. I was able to re-setup my old OpenVPN and can now control my policy routing successfully. Thank you.
Just installed vpn-policy-routing 0.2.1-13. My intention is using WAN by default and routing some specific devices (such as NAS) as well as remote domains over Wireguard tunnel (provider is Mullvad).
How can I get this behavior? Tunnel is currently set as default.
I expected VPR to work out of the box, but I only get connection refused when trying to route the most remote domains over WAN. WAN device is a FritzBox.
Here are some outputs below:
vpn-policy-routing support
# /etc/init.d/vpn-policy-routing support
ERROR: DNSMASQ ipset support is enabled in vpn-policy-routing, but DNSMASQ is either not installed or installed DNSMASQ does not support ipsets!
vpn-policy-routing 0.2.1-13 running on OpenWrt 19.07.0. WAN (IPv4): wan/dev/192.168.254.253.
============================================================
Dnsmasq version 2.80 Copyright (c) 2000-2018 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify dumpfile
============================================================
Routes/IP Rules
default * 0.0.0.0 U 0 0 0 WGINTERFACE
IPv4 Table 201: default via 192.168.254.253 dev eth0.2
192.168.10.0/24 dev eth1.10 proto kernel scope link src 192.168.10.1
192.168.67.0/24 dev br-Home proto kernel scope link src 192.168.67.1
192.168.254.0/25 dev br-Guest proto kernel scope link src 192.168.254.1
192.168.255.0/28 dev eth1.1 proto kernel scope link src 192.168.255.1
IPv4 Table 201 Rules:
32705: from all fwmark 0x10000/0xff0000 lookup 201
IPv4 Table 202: default via 10.65.167.191 dev WGINTERFACE
192.168.10.0/24 dev eth1.10 proto kernel scope link src 192.168.10.1
192.168.67.0/24 dev br-Home proto kernel scope link src 192.168.67.1
192.168.254.0/25 dev br-Guest proto kernel scope link src 192.168.254.1
192.168.255.0/28 dev eth1.1 proto kernel scope link src 192.168.255.1
IPv4 Table 202 Rules:
32704: from all fwmark 0x20000/0xff0000 lookup 202
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 192.168.67.0/24 -d 87.248.33.19/32 -p udp -m multiport --sports 0:65535 -m multiport --dports 0:65535 -m comment --comment Test -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.67.0/24 -d 87.248.33.19/32 -p tcp -m multiport --sports 0:65535 -m multiport --dports 0:65535 -m comment --comment Test -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
============================================================
IP Tables FORWARD
-N VPR_FORWARD
============================================================
IP Tables INPUT
-N VPR_INPUT
============================================================
IP Tables OUTPUT
-N VPR_OUTPUT
============================================================
Current ipsets
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]
May it depend on dnsmasq-full not being installed? I've omitted this because not sure about a correct out-of-the-box behavior.
More on option dest_addr in vpn-policy-routing: Entering this domain name as it is causes web page to be loaded. Entering FQDN (with "www.") causes connection to be refused. Other domains such as duckduckgo.com get me a direct connection refusal.
Hi Team,
I was wondering if you ignore DNS ports in VPR as I was recently trying to route 53 and 853 over my WG tunnel and noticed neither will route via VPR. They always go WAN (default in my case).
