Well, with dhcp option 6 you're instructing your clients to use google dns for name resolution, not your dnsmasq, maybe that's why it's not adding IP addresses to ipsets.
I am so stupid. Don't know how I didn't notice this. Thanks for pointing it out.
Dnsmasq domain-based routing works perfectly.
1 Like
No worries, I'm glad we've got it resolved. Thank you for your determination to find out the root of the problem. 
1 Like
Thank you!
Now that I am actually using the domain-based routing, i'll report any minor issues if I encounter any.
Sounds/Looks like this thing is getting pretty flushed out, think it's ready for prime time?
Pretty much. I've also gotten rid of extra dependencies which were derived from VPN Bypass and are no longer required with the new code.
The only thing I'm waiting is for someone with both ISP and VPN IPv6 to test the IPv6 implementation in main package and luci app.
Legacy IP/domains seem to be working fine.
1 Like
are there any VPN providers that offer IPV6 service? Only one I can think of is Perfect Privacy, of which I don't use. I have access to PIA and IPVanish.
@cybrnook, mullvad has ipv6 support (and free trials). I haven't got it to work on lede, but their uk server works well with ipv6 on standard linux. Let me know if it works for you.
@stangri, I see some errors related to ipv6. Looks like some issue with parsing ipv6 addresses ? Maybe it is truncating them ?
/etc/init.d/openvpn-policy-routing restart
destroying table wan/eth0.2/73.82.142.1 ipset=wanroute [✓]
destroying table vpn0/tun0/10.114.0.3 ipset=tun0route [✓]
destroying table vpn0/tun0/[fd38:35d7:d640:72::] ipset=tun0route6 [✓]
openvpn-policy-routing 4.1.4-12 stopped ✓
creating table wan/eth0.2/73.82.142.1 ipset=wanroute [✓]
creating table vpn0/tun0/10.114.0.3 ipset=tun0route [✓]
creating table vpn0/tun0/[fd38:35d7:d640:72::] ipset=tun0route6 Error: inet6 address is expected rather than "[fd38:35d7:d640:72::]".
[✗]
routing 'test' 192.168.1.1/24 to 23.253.100.206 via tun0 [✓]
routing 'Plex Remote Access' 192.168.1.1/24:32400 to ... via wan [✓]
routing 'Local Subnet' 192.168.1.81/29 to ... via wan [✓]
routing 'Local IP' 192.168.1.70 to ... via wan [✓]
routing 'LogmeIn Hamachi' 192.168.1.1/24 to 25.0.0.0/8 via wan [✓]
/etc/rc.common: eval: line 1: raddr::/0: not found
routing 'Plex Media Server IPv6' :32400 to via wan
ERROR: ip6tables -t mangle -I OPR_CHAIN 1 -j MARK --set-xmark /0xff0000 -p tcp -m multiport --sport 32400
[✓]
routing dnsmasq policies ✓
Thank you for checking! I suspect it's square brackets. Can you please run etc/init.d/openvpn-policy-routing support (either with -p so it uploads details to paste.ee or PM me the output) so I can see what exactly has failed. Also, if you have my repo added to your router, please update to -13 build where I've fixed minor errors/output.
Thank you for the paste. The error seems to be coming from iproute when trying to add default route to a tun0 ipv6 table (the other error is from the only policy_ipv6 in the default config which fails if WAN6 is not active, so I'll remove it).
I'll need to consult IPv6 expert to figure out how to overcome this problem.
Had a typo in the IPv6-related code, it's been fixed in 4.1.4-15.
Thanks to the feedback from @buckaroo and great advice from @AndreL I believe I'm pretty close to making everything work with IPv6. I've also squashed a number of bugs reported recently so if you're using my repo, just run opkg update; opkg upgrade openvpn-policy-routing to upgrade to OPR 4.1.4-20.
Is it technically possible to have a routing condition/policy based on bytes transferred (like less/more than 1MB)?
It probably is, but the only way I found would include monitoring counts on various rules which is outside the scope of this project. If you come by simple static iptables rules which just work for what you want to achieve, I'll take a shot at integrating them into OPR.
On a different subject, I would very much like to again ask for freedback/testing from people with both native ISP and tun* IPv6.
I have seen such conditions in QoS rules. I've never written my own iptable rule before so that doesn't help.
After further searching, it seems kmod-ipt-conntrack-extra has connbytes. Connbytes can be for bytes uploaded/dloaded/or both. I hope this is the right direction. Now I'm looking if can be used to set gateway.
Downloaded @cybrnook latest stable build R3286 and followed the instructions in the readme here for custom feeds. Then installed OpenVPN Routing package via GUI.
Works great, just what I needed to allow only some IPs through the VPN.
Thanks @stangri for all your hard work on this OpenVPN Routing project.
1 Like
Have you tried iptables command with connbytes parameter as described here?
Would be great if you could describe the use case so I could try to wrap my head around what the good GUI implementation be.
Can I make a request? Would you be so kind/awesome as to document your findings and methods? You seem to have invested a lot of time and effort, but right now all your knowledge is entangled in your code.
The question on how to route specific IPs/ranges/ports through specific interfaces using iptables is a pretty generic one, and solutions, if they even exist, are not even close to being well-documented. I'm thinking if somebody wants to do a few routes manually, or adapt them to something other than an OpenVPN connection.
A use case is for a streaming LAN device's (as long as) incoming bytes upto 1MB to go thru VPN gateway (--connbytes 0:1000000 --connbytes-dir reply). I could test an iptables command if you could suggest one and I could experiment from there on. I'm curious as to whether it would work - whether it will change states conditionally(?). Better to test before proceeding.
In very broad terms, this package sets up routing tables with default gateways and iptables rules to route marked packets thru them for each valid wan* and tun*/tap* interface, then sets up iptables rules to mark specific packets (according to the policies) so they would end up routed thru specific routing table.
If you run /etc/init.d/openvpn-policy-routing support from the command line you should see the rules/tables.
Maybe the code of vpnbypass package would be easier to follow, but even with the OPR the whole code is inside one init-file. Check out table_create() and process_policy() functions.
Just follow the link above to set up the conditions and at the end add: -t mangle -I OPR_CHAIN 1 -j MARK --set-xmark 0x010000/0xff0000 (0x010000 is for WAN, for tun0 it would be 0x020000 and so on).
You would have to experiment with that, I hope it works.
You can then monitor traffic flows with something like iftop -i tun0.