What does the 'support' show?
I gave up and switched to using IPs in my policy.
Now my issue is that I have rules in iptables to allow incoming HTTPS traffic to hit my server that is normally routed through VPN these work if I disable this policy routing service and let tun0 be default for everything but when I enable it I loose ability to connect from internet.
here is support command
vpn-policy-routing 0.0.2-4 running on OpenWrt SNAPSHOT. WAN (IPv4): wan/dev/xx.xx.x.xx.
============================================================
Dnsmasq version 2.80test2 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 xx.x.0.1 128.0.0.0 UG 0 0 0 tun0
default xx.xx.xx.xx 0.0.0.0 UG 0 0 0 pppoe-wan
IPv4 Table 201: default via x.x.x.xx dev pppoe-wan
IPv4 Table 201 Rules:
32687: from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via x.x.xx.x dev tun0
IPv4 Table 202 Rules:
32686: from all fwmark 0x20000 lookup 202
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 192.168.1.115/32 -m comment --comment Pixel2 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.1.135/32 -m comment --comment NUC -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.1.72/32 -m comment --comment Laptop -c 128 15826 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -m set --match-set vpn0 dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m set --match-set wan dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create vpn0 hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Unfortunately, I can't get it to work.
I've excluded my laptop from the VPN tunnel.
Everything works except for Netflix. I can perfectly browse any website.
I've put in the same configuration as you did (on WRT3200ACM tough)
From a wireshark trace, I can see that a TCP re-transmission is happening. So either the SYN package is not being send out, or the SYN-ACK is not returning properly.
Any suggestions?
Thank you in advance!
Not enough info. Rules? Which device hosts the server? BTW, VPR does not change default routing in any way.
I have fixed my issue finally. It was a simple configuration error on the firewall. I'm not certain this is the safest / most secure, but I can now successfully route specific devices around my VPN.
Here is a screenshot of my firewall config so that it may help others.
@stangri, thank you for all your assistance!
Hello, I wrote before about simultaneous use of vpn client and server, which did not work for me.
Now I started again from scratch and again I'm getting desperate because it isn't working.
I configured everything exactly like it is stated here and here.
In vpn-policy-routing I specified the device I want to go through vpn tunnel to vpn provider (torguard in my case). The device is odroid hc-2.
Also vpnserver interface is ignored like stated in the wiki ..etc..
Right now connecting to my vpn server, I can reach every device in my lan, also by hostname despite of the odroid hc-2 IP 
In vpn client config I have opiton nobind enabled.
Proto of both client and server is tcp.
Can anyone help? 
Hey, fellow odroid user!
If your default routing is thru WAN and you use VPR to specify which devices go thru VPN tunnel, I think it's expected that those (VPN tunnelled) devices are not accessible via VPN Server.
I have sort of opposite config -- my default routing is thru VPN, I use VPR to set up exclusions and last I checked I could connect to any device via VPN Server.
Maybe someone more knowledgeable about iptables could suggest a better solution.
Ok, I always thoughtthis wiki exists to solve this exact issue because it also states to use the option nobind.
How else could one use both server and client? Have all tunneled to vpn provider?
It may have to be reworded/appended for various default routing options.
Do you know someone or another place to ask? I posted my issue here before but unfortunately didn't get any response.
I've updated the information service stores in ubus, hence I've updated the WebUI to better reflect the status of the service and show any errors (if any occurred) and also made a minor improvement in service start/stop usability in WebUI.
I would appreciate feedback.
Just updated VPR packages and now see the new service status window in WebUI. however the status is not reflecting that VPR is enabled. I verified that option enabled '1' is set in in config file and my policys are running. Just not getting what I assume should show "Service enabled/started". instead it always shows "Service disabled/stopped"
Please confirm the version of main package by running opkg list-installed | grep '^vpn-'.
Also, can you post the output of: ubus call service list "{\"name\": \"vpn-policy-routing\"}" (omit your IPs if you want).
PS. Which device/OS is that happening on?
So I'm switching VPN providers (to get incoming port forwarding) but in switching back and forth, somehow my VPR became and stayed broken even when I went back to my old VPN provider. Here's the info asked for in the README:
config vpn-policy-routing 'config'
option verbosity '2'
option ipv6_enabled '0'
option ipset_enabled '1'
option dnsmasq_enabled '0'
option strict_enforcement '1'
option VPN_U_dscp '16'
option enabled '1'
status output:`vpn-policy-routing 0.0.2-20 running on LEDE 17.01.4. WAN (IPv4): wan/dev/192.168.1.1.
============================================================
Dnsmasq version 2.78 Copyright (c) 2000-2017 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
============================================================
Routes/IP Rules
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
IPv4 Table 201: default via 192.168.1.1 dev eth0
IPv4 Table 201 Rules:
32763: from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via 10.200.0.69 dev tun0
IPv4 Table 202 Rules:
32762: from all fwmark 0x20000 lookup 202
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -m set --match-set VPN_U dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m dscp --dscp 0x10 -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m set --match-set wan dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create VPN_U hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]
reload:
Creating table 'wan/192.168.1.1' [✓]
Creating table 'VPN_U/10.200.0.69' [✓]
vpn-policy-routing 0.0.2-20 started on wan/192.168.1.1 VPN_U/10.200.0.69 [✓]
vpn-policy-routing 0.0.2-20 monitoring interfaces: wan VPN_U [✓]
Thanks for any suggestions
Oh, as a troubleshooting step, I uninstalled and reinstalled VPR. This gave me 4 "uci setting doesn't exist" or something similar. I'm not sure if that is expected.
How is it broken?
Definitely not expected.
It won't direct packets, and it doesn't obey the strict rule setting - packets destined for the VPN, when the VPN is not up, still go out the main internet path.
Can you suggest how I might go about fixing this?
I should mention, that some months ago, I did observe VPR not obeying the strict rules in the case of the tunnel being down. I'm afraid I don't recall what I did to fix it, might have just been a reboot, restart, etc. So this is not completely down to changes I may have made just today.
thanks
Yes, start with providing better details.
I've given my logs as suggested, and remedied my poor (sorry) "it's broken" description, I'm afraid I don't know what else might help. I'm very motivated to get this fixed, please point out where I'm lacking here.
thanks
When the tunnel is up -- what exactly isn't working?
When the tunnel is down -- please post the "reload" and "status" outputs.