VPN Policy-Based Routing + Web UI - ARCHIVE #1

Community Builds, Projects & Packages
384

Maybe it was suggested to complement regular OpenVPN routing set up with OPR, but I hope not to replace it, as OPR doesn't do that.

The /etc/init.d/openvpn-policy-routing support shows pretty much everything OPR changes in your router.

You don't have to. Like I've suggested before -- let OpenVPN do its job creating the tunnel route and the policies will work automagically.

No, sorry, and I'm not sure that this thread is the best place to seek this help as it has to do with OpenVPN and not the OPR.

385

Well, it did not work out for me. I tried to let OpenVPN create the routes
but I always ended up being blocked or bricked. I really appreciate the
work done, but as a user and not a developer I want to read a comprehensive
how-to, install, configure and then start using a new module. It took 5
minutes to setup OpenVPN and after three evenings of trying to understand
what OPR needs and how it works, the policy routing part it is still not
working. The good thing is, that while doing this, I have now found a way
that works for me. I take advantage of the fact that the custom firewall
rules in LUCI accept shell commands. And the firewall is reloaded each time
the tunnel is up. This script now works for me with route_noexec, not very
fancy but I can live with it (and without a down script):

client=10.0.0.4

tunnelif="$(ifconfig | grep -A 1 'tun0' | tail -1 | cut -d ':' -f 2 | cut
-d ' ' -f 1)"

#match client IPs into table vpn (delete first to avoid duplicates)
ip rule del prio 10
ip rule add from $client table vpn priority 10

#Setup default route for the tunnel interface in table vpn
ip route add default via $tunnelif dev tun0 table vpn

ip route flush cache

#Ensure that the client cannot not use the Internet without a VPN
iptables --flush forwarding_lan_rule
iptables -A forwarding_lan_rule -s %client -o pppoe-wan -j REJECT

Thanks again for the support provided.

1 Like
386

Hi Strangri, I have a new (small) issue, not sure if related to OPR or not (though generally OPR now works fine in the latest versions! really happy, so thanks!); I'm unsure if it's been addressed before, because this thread is now too long to read through!

If I lose wan connectivity for whatever reason (ISP drop, for testing I unplug the phone cable [adsl], etc), openvpn can't reconnect. 2 errors pop-up: cannot resolve vpn.server.domain.name.com, and "TLS Error: TLS key negotiation failed to occur within 60 seconds". Both of which I believe simply indicate that openvpn can't contact the server. (note that if the disconnect happens within a certain time frame, it doesn't use the domain name, but rather reuses the stored IP address, so its not a DNS issue, since it is attempting to use an IP)

Restarting the openvpn service fixes the issue, no need to restart router.

Restarting OPR doesn't fix the issue, so I'm assuming OPR not the issue.

Any thoughts on what this might be?

387

Could very well be OPR-related. Have you tried adding "vpn.server.domain.name.com" to a WAN policy?

388

openvpn-policy-routing - 5.0.1-16
I use route-nopull in openvpn configs but
0.0.0.0/1 via 10.128.23.192 dev tun1
128.0.0.0/1 via 10.128.23.192 dev tun1
appear in "ip r" output. This seem to be OPR as when OPR disabled this entries are absent.
What I'm trying to do is to connect to a number of tunnels and be able to route LAN devices via different tunnels using OPR. So pulling routes isn't a good idea as router itself will go through last connected tunnel.
With OPR enabled and openvpn route_nopull router itself can't reach Internet.
Adding router IP into OPR config with interface WAN don't do the job. Adding LAN net to OPR with interface WAN allows LAN to reach Internet.

389

Just tested 5.0.1-15 and it works like it should
The only difference I see with 5.0.1-16 is

          if ! is_wan "$iface"; then
                  route add default netmask 128.0.0.0 gw $gw4 >/dev/null 2>&1
                  route add -net 128.0.0.0 netmask 128.0.0.0 gw $gw4 >/dev/null 2>&1
          fi
390

Oops, that 5.0.1-16 shouldn't have made it to the repo, it's a mistake. I was testing that piece of code and decided against it.

391

Updated my WRT3200ACM today and had to revert to 5.0.1-15 as
@amatsumara noted above. I installed -16 and then copied over -15 with Filezilla.

Working fine now.

Maybe you should remove -16 as it may confuse novice OPR users.

392

Quick Question:
Is there another/easier way to do the following:
Route just one Ip through vpn tunnel, rest untouched to inet.
Right now I guess one simply puts every device in the policies list with interface wan except the one to go through vpn tunnel.
I don't mind doing so, just asking if there's another way that is recommended.

393

You don't need to put every device to the policies list but just one you need go through tunnel. If device not listed in OPR it goes via WAN by default.

394

Hmm.. I can't confirm this... I first set up openvpn client, after that of course all devices did go through vpn tunnel. Then installed stangris packages and activated them.
Still all devices go through vpn by default.
Maybe it's a setting in my openvpn client conf?

395

Sorry, I thought everyone use route-nopull option in openvpn. You can set route-nopull to stop setting default route pushed by openvpn server then specify just few IPs in OPR. That's what for OPR was intended to be used I think.

396

Actually I tried that, I kept it in mind from a previous dd-wrt setup :grin:
But if I set route-nopull I have no inet connection at all.
Openvpn states the following errors:

Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])

In wan interfaces earlier I set dns servers, I thought this may have been the problem. But taking them away and setting it to use the provided dns servers leaves me with no inet.

397

Those are not really errors but just a result of the route-nopull option in OpenVPN.

From my OPR experience:

I suggest your disable OpenVPN and OPR and reboot. This should get you back to the normal ISP internet WAN connection.

If this works OK, then enable the OpenVPN VPN with the route-nopull option set. You should still have normal access through your ISP via WAN even with the VPN active due to the route-nopull option.

Check the Status-Routes-Active IPv4-Routes table at each step to see what is baseline and what changes at each step.

Then enable OPR with all set to go through WAN. If this works (internet access), then setup a static IP to go through the VPN.

It should then go through the VPN.

You may need to set the DNS settings to the VPN Service DNS IP to ensure you are not leaking DNS but then all DNS requests will go to that DNS. I have not figured out how to selectively direct DNS to the VPN.

One thing to check is that you have DNS entries in the "DNS forwardings" or in your WAN settings "Use DNS servers advertised by peer" as the route-nopull option will stop the VPN service setting up any DNS for the link. I think it can be done manually but I do not know how.

Hope this helps.

1 Like
398

Thank you, I thought it was automatically removed from the repo with my script, but I checked and it wasn't so I killed it manually.

Correction: it goes to default routing. In my case, I want majority of traffic over VPN so I let OpenVPN client set up default routing going to VPN. It might not be the case on other routers tho.

399

Configuration like

config policy
        option local_addresses '192.168.1.182'
        option interface 'tunnel0'
        option comment 'vagrant0'

config policy
        option interface 'wan'
        option comment 'vagrant0'
        option local_addresses '192.168.1.182'
        option remote_addresses '<very strict bank IP>'

seem not to work. In this example I'm trying to route PC from LAN to Internet via tunnel in exception of some set of IPs/nets like strict banks or services like Netflix who block known VPN providers.
Currently I found such workaround:

iptables -t mangle -N OPR_BYPASS
iptables -t mangle -I PREROUTING -j OPR_BYPASS
iptables -t mangle -A OPR_BYPASS -j RETURN

Then insert into this chain my exception:
iptables -t mangle -I OPR_BYPASS -s 192.168.1.182/32 -d '<very strict bank IP>' -m comment --comment vagrant0 -j MARK --set-xmark 0x10000/0xff0000

Maybe it's a good idea to move more specific rules to the end of OPR_CHAIN after ipset matches? Or maybe I'm doing it wrong?

400

Alex,
Ever since I've allowed to mix and match domain names and IP addresses/ports, it became quite difficult to enforce the proper order of policies (as I don't want to end up creating a new ipset for each domain and clutter the iptables with a lot of rules).
Please try the -17 build, I've made modifications to the policies ordering, so it may work for you. I may have to revise it again in the future tho.

401

I've had some time to reflect on that, the only way to enforce the proper ordering of rules is when ipsets are not used at all. I will implement that in the future build.

402

Yes, tried -17 build. ipset matches now go first and more specific rules last. Thanks a lot!

403

Thx, I will try that. Is there a way to set a delay for these 2 to start? I mean it's not important since normally you don't start your router every day, but it would be nice.

I have 2 more questions:
How can I update the OPR version?

Also, I'd like to iplement some sort of killswitch. Like if the vpn connection between my specified device(s) cannot be established or breaks up the devices should not be able to connect to the internet at all. It would be perfect if these ip(s) then automatically will try to establish the vpn connection again.
Using dd-wrt I could get the first part to work by using these firewall rules:

iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan2 -j DROP
iptables -I INPUT -i tun0 -j REJECT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

This might be off topic but I thought I'll ask beforehand if maybe this OPR package already has such kill switch included.
If not it would be a suggestion of mine. The above rules are a bit crude, I noticed that they "break up" all access to the internet for all devices, even if they don't go trough vpn tunnel. Also there is no retry happening, I had to restart the vpn client manually each time a breakup happened.