I'm not sure I fully understand what you mean. Logs looks OK to me, what seems to be the problem?
When I put in a LAN ip address to bypass WireGuard it just doesn't work mate. I dont know what I'm doing wrong lol.
I unticked the "Create routes for Allowed IPs for this peer" in the WireGuard interface and added the rules to allow ip addresses to use WireGuard aswell and that doesn't work neither. It almost like it doesn't see the WAN or wg0 (WireGuard).
Maybe you can run me though how to work this thing lol. I'm really stumped. I would use namespace virtual eth1.2 to make it work but can't work how to get that working neither
Thanks. 
Uhm, I think two ipsets per interface might not be working as intended, in the vpn-policy-routing 0.0.1-5 I've switched back to iptables for local addresses/devices, see if that helps.
Thanks for quick reply. Any chance of testing out "vpn-policy-routing 0.0.1-5"?
I just tested the "vpn-policy-routing 0.0.1-4 you just pushed and it working for allowing traffic though WireGuard now. But not the bypass yet sadly.
Thanks.
Edit: Tested "vpn-policy-routing 0.0.1-5" and everything is working. You bloody legend!!! keep up the good work.
2 Likes
Your feedback and prompt testing of newer versions are much appreciated!
Nice Plugin! But i have a Problem:
The Remote Port 63000 should go over tun0 but this does not working.
The local adresses i try works well.
There is my output of /etc/init.d/vpn-policy-routing support and /etc/init.d/vpn-policy-routing reload.
Thank you for your help!
root@OpenWRT:~# /etc/init.d/vpn-policy-routing support
vpn-policy-routing 0.0.1-6 running on OscamWRT Chaos Calmer. WAN (IPv4): lan/dev/10.4.4.1. WAN (IPv6): lan/dev6/::/0.
============================================================
Dnsmasq version 2.73 Copyright (c) 2000-2015 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 loop-detect inotify
============================================================
Routes/IP Rules
default 10.4.4.1 0.0.0.0 UG 0 0 0 br-lan
0: from all fwmark 0x10000 lookup 201
0: from all fwmark 0x20000 lookup 202
IPv4 Table 201: default via 10.4.4.1 dev br-lan
IPv4 Table 202: default via 10.8.8.42 dev tun0
============================================================
IP Tables
VPR_CHAIN all -- anywhere anywhere [goto] mark match 0x0/0xff0000
-N VPR_CHAIN
-A VPR_CHAIN -m set --match-set lanroute dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_CHAIN -m set --match-set nordvpntunroute dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_CHAIN -p tcp -m multiport --dports 63000 -m comment --comment service123 -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_CHAIN -s 10.4.4.9/32 -m comment --comment "10.4.4.9" -c 26 1976 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_CHAIN -s 10.4.4.8/32 -m comment --comment "10.4.4.8" -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_CHAIN -s 10.4.4.253/32 -m comment --comment "10.4.4.253" -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
============================================================
Current ipsets
create lanroute hash:net family inet hashsize 1024 maxelem 65536 comment
create nordvpntunroute hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [â]
root@OpenWRT:~# /etc/init.d/vpn-policy-routing reload
Creating table 'lan/br-lan/10.4.4.1' [â]
Creating table 'nordvpntun/tun0/10.8.8.42' [â]
Routing 'service123' via nordvpntun [â]
Routing 'Local IP' via nordvpntun [â]
vpn-policy-routing 0.0.1-6 started on lan/br-lan/10.4.4.1 nordvpntun/tun0/10.8.8.42 [â]Could it be because the 63000 traffic is UDP? If you do: iptables -t mangle -A VPR_CHAIN -p udp -m multiport --dports 63000 -m comment --comment service123 -c 0 0 -j MARK --set-xmark 0x20000/0xff0000 does that help?
No it is definitely tcp.
I test it again und can isolate this problem:
If the Router itself wants to connect to port 63000 it is still not working. => the traffic go over br-lan
If a other device wants to connect to remote port 63000 the policy working well. => the traffic go over tun0
Could therea Problem with my firewall?
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
config zone
option name 'vpnfirewall'
option output 'ACCEPT'
option masq '1'
option mtu_fix '1'
option input 'DROP'
option forward 'DROP'
option network 'nordvpntun'
config include
option path '/etc/firewall.user'
config forwarding
option dest 'vpnfirewall'
option src 'lan'Yeah, the router itself is not affected by these rules. Do you need the router traffic on 63000 to go over VPN?
Yes 
I can't recall the reason why it's done this way, but the chain in the mangle table which I'm modifying does not affect traffic from the router itself. I'll PM you after the New Years if I have something for you to try. If you discover a solution in the mean time -- let me know.
Ok thank you! Merry Christmas to you!
Thank you for sharing your work. It works beautifully..
I just pushed the new build: 0.0.1-8.
Summary of changes:
- Option to ignore specific interfaces (like VPN Server for example)
- Support for Openconnect
- Support for PPTP (please test)
- Support for both TCP and UDP protocol policies (see Additional Settings section of the README)
- Support for FORWARD/INPUT/OUTPUT chains (see Additional Settings section of the README)
- Thanks to support for OUTPUT chain you can now set policies affecting the router itself.
- README now has the list of all "hidden" options, not accessible with Web UI.
Also, I can't recall if it was in this or some other thread, but someone had issues with OpenVPN server not working on their router once OpenVPN client started, this can now be fixed with the newest build. PM me for details (wiki article is coming up).
1 Like
Nice! Thanks for your good work!