Thank you, that did it for me! Now the wg tunnel no longer becomes WAN. Sadly, I must have misconfigured something as I don't receive anything from the tunnel. I see the traffic sent, but received stays 0 B in wg show.
I had the same problem. I gave up after a while and it suddenly worked after upgrading to LEDE 17.01.4. It was probably the outdated WireGuard version.
1 Like
Ah, I must have something odd going on with my config.
I have this set up as a LuCi command:
sed -i -e s/wan/WAN/g /etc/config/openvpn-policy-routing
Which I run after adjusting the OPR LuCi config. This gets it working straight away.
Thanks again.
I've fixed this completely now.
I think I must have created my original wan interface with the name WAN in upper-case:
This is my /etc/config/network
config interface 'WAN'
option proto 'pppoe'
option ifname 'eth1'.....
So to fix, I edited your OPR LuCi Lua cbi model, and replaced all instances of
value("wan","WAN")
with...
value("WAN","WAN")
This pushes the correct key to the OPR config file for my router.
All good now - thanks again for your time & code.
The UI might require horizontal scrolling as it is, I wouldn't want to overload it with another column.
If you have time to experiment, run the reverse sed (replace all WAN with wan in OPR config only, not in the network config), enable verbose logging and please PM me the output of both 'reload' and 'support' commands as well as full OPR config.
@Michael123 How did you get OPR working with wireguard?
My goal is to route everything through the wireguard interface, except some exceptions I enter in OPR.
- What did your firewall forward config end up looking like?
- Do you check Route Allowed IPs?
If I uncheck Route Allowed IPs, then nothing is routed through the wireguard interface.
edit:
Did you check Route Allowed IPs? That sets the WireGuard interface as default route. I have it unchecked and WireGuard is only used for policies with WIREGUARD as interface and not WAN.
What OPR policies are you using? Are you only routing certain known traffic through wireguard?
Currently none because the policies for Netflix aren't working. Sometimes I select the IP of a single device to route it through WireGuard.
If you want to route everything through WireGuard you could try a policy with an IP like 192.168.1.0/24 in the Local addresses/devices field. Add a comment, set the interface to WireGuard and leave the rest empty. That would route 192.168.1.1 - 192.168.1.254 through WireGuard. With the default setting DHCP assigns 192.168.1.100 - 192.168.1.250, but you can't get that range. See IP Calculator online how subnets are calculated.
Let me know if you are able to get an exception for Netflix working. See my other post.
My advice on netflix. Have a look here at
https://forum.openwrt.org/viewtopic.php?id=54048
Option 3 - DNS logging
You need to capture (log) all DNS requests when your computer is connecting to netflix and make sure all those gets redirected. It's very likely that you'll see dns requests to clouflare and other sites apart from just neflix.com.
1 Like
What is the order of priority of the OPR rules? Does the first matched rule take effect or the last?
I tried setting the remote address" to 0.0.0.0/0 routed through Wireguard, but that didn't work. I'll try it with the local address rule next.
Having a great time with this tool.
Is there a way to apply the policy to specific mac addresses?
I''ve got a 'default VPN' set up for all devices, but would like to allow certain devices to access the wan directly, no matter what IP (static or dhcp) they have. At the same time, I don't want to allow other 'guest' devices to steal the IP of a trusted device and be able to access the wan. The only way round this I can think of is to apply policies to the mac addresses.
I think the routing is done on IP address level not on the level of mac addresses. But what you could to is to assign permanent IP address to the given mac address. It is done in /etc/config/dhcp For example:
config host
option ip '192.168.1.10'
option mac '40:B4:CD:xx:xx:xx'
option name 'kindle-ecxxxx'In terms of "stealing IP address", if you are worried about security create an untrusted guest network and have untrusted guests limited to it.
1 Like
If you don't enable ipset, then top matched has priority. If you do enable ipsets, then ipset rules (domains, local device names) have priority over any iptables rules. If you want strict priority you can either disable ipset or use the 'policy-routing' package.
Follow @dziny's advice above.
Actual for openvpn-policy-routing_5.0.1-17_all.ipk
Just noticed in log while building lede image with imagebuilder:
imagebuilder/lede-imagebuilder-17.01.4-x86-64.Linux-x86_64/build_dir/target-x86_64_musl-1.1.16/root-x86/usr/lib/opkg/info/openvpn-policy-routing.postinst-pkg: line 13: uci: command not found
So it tries to execute uci commands on build machine. Would be nice to have some checks on $IPKG_INSTROOT like here https://wiki.openwrt.org/doc/devel/packages#packaging_a_service or even use /etc/uci-defaults
Thanks Alex -- it was a typo in the Makefile, should be fixed in 5.0.1-18.
To better reflect support of both OpenVPN and Wireguard, I've changed the package name to vpn-policy-routing. The new package (and accompanying luci package) has been published to my repo already. If you have my repo added to your router, follow commands below to upgrade to the newer package:
opkg update
opkg remove luci-app-openvpn-policy-routing openvpn-policy-routing
opkg install vpn-policy-routing luci-app-vpn-policy-routing
The installation script for the initial release will convert your openvpn-policy-routing config to vpn-policy-routing config.
There will be no more updates to openvpn-policy-routing package anymore, all the development has moved to vpn-policy-routing.
1 Like
Is anyone using ddns-scripts with either OPR or the new VPR package? I'm facing some issues. 
as soon as i enable the policy based routing service, the inter-VLAN traffic (for example, VLAN 100 to VLAN 200) dropped immediately. I could get the inter-VLAN working by restarting the firewall service, Any idea?
PC1 on VLAN100 can ping the default gateway of PC2 on VLAN200, which is another interface on the same router. However, when PC1 was trying to reach PC2, traceroute showed that the traffic was forwarded to the VPN tunnel.
Pinging 192.168.255.1 with 32 bytes of data:
Reply from 192.168.255.1: bytes=32 time=1ms TTL=64
Reply from 192.168.255.1: bytes=32 time=72ms TTL=64
Reply from 192.168.255.1: bytes=32 time=73ms TTL=64
Reply from 192.168.255.1: bytes=32 time=5ms TTL=64
Reply from 192.168.255.1: bytes=32 time=136ms TTL=64
Tracing route to 192.168.255.215 over a maximum of 30 hops
1 44 ms 3 ms 1 ms 192.168.1.1
2 219 ms 216 ms 213 ms 10.110.14.1
3 217 ms 379 ms 215 ms 116.193.159.73
4 * * * Request timed out.
i figured it out.
ip route add 192.168.0.0/24 dev eth1.200 src 192.168.0.1 table no_vpn_provider
ip route add 192.168.255.0/24 dev br-USER_WLAN src 192.168.255.1 table no_vpn_provider
ip rule add from 192.168.0.0/24 table no_vpn_provider priority 0
ip rule add from 192.168.255.0/24 table no_vpn_provider priority 0
I got the idea from here - https://superuser.com/questions/1152318/policy-routing-for-openvpn-server-client-on-the-same-router
1 Like
Here some logs for you mate. I cannot get WireGuard and PPPoE to see the WAN. Not sure what's going on.