VPN Policy-Based Routing + Web UI -- Discussion

stangri · 2019-04-25T02:01:38.933Z

Please confirm versions of both VPR and the luci app you have installed.

ahmar16 · 2019-04-25T02:15:19.246Z

I have the same issue and I am running OpenWrt SNAPSHOT r9901-6e7e2f4421 / LuCI Master (f138fc93) on BT HomeHub 5A with minimal config.

root@AhmarRouter:~# opkg list-installed *vpn-policy-routing
luci-app-vpn-policy-routing - git-19.113.55792-3c7b3fa-38
vpn-policy-routing - 0.0.4-6

Although it seems fine with SSH:

root@AhmarRouter:~# service vpn-policy-routing stop
vpn-policy-routing 0.0.4-6 stopped [✓]
root@AhmarRouter:~# service vpn-policy-routing start
Creating table 'wan/182.176.1.48' [✓]
Creating table 'vpn/10.211.1.34' [✓]
Routing 'Microsoft' via vpn [✓]
Routing 'Hub' via vpn [✓]
vpn-policy-routing 0.0.4-6 started on wan/182.176.1.48 vpn/10.211.1.34 [✓]
vpn-policy-routing 0.0.4-6 monitoring interfaces: wan vpn [✓]

FCS001FCS · 2019-04-25T09:43:50.095Z

stangri:

Please confirm versions of both VPR and the luci app you have installed.

Sorry, I should have included it in the first post:

VPR = 0.0.4-6
Luci App VPR = git-19.113.55792-3c7b3fa-38

image1768×487 46.6 KB

stangri · 2019-04-25T15:14:29.330Z

@ahmar16 -- thank you for confirming @FCS001FCS's earlier report.

It must have something to do with luci API to access ubus in the snapshot.

I'll try to test the snapshot on my router sometime in early May and fix this.

FCS001FCS · 2019-04-25T20:51:07.892Z

stangri:

It must have something to do with luci API to access ubus in the snapshot.

I don't know if it matters but I use the basic "Bootstrap" theme for the GUI.

+++++++++++++++++++++++++++++++++++
EDIT: Maybe it is linked to the permissions issue in https://forum.openwrt.org/t/buggy-builds-luci-statistics-error-while-showing-graphs/35547/23?u=fcs001fcs

I also had the Statistics problem and reinstalled it to coorect the problem.

Just a thought.

FCS001FCS · 2019-04-27T10:21:30.315Z

stangri:

It must have something to do with luci API to access ubus in the snapshot.

Issue: "Started without PROCD support" - Fixed with VPR Updates to both VPR packages: -7 & -39

@stangri - Thanks for all your hard work!

image1797×492 46.7 KB

stangri · 2019-04-27T23:34:52.118Z

I've asked for a proper solution of the problem here: Ubus CLI and snapshots.

stangri · 2019-04-29T10:11:32.092Z

I've migrated to storing the run-time data in TMPFS rather than PROCD instance, seems to be running fine on snapshot, please let me know if you run into any issues.

SlotTech · 2019-04-29T14:43:09.208Z

So I'm trying to set this up to send my dns requests to a remotely hosted pi hole server over a vpn connection.

I can get the vpn up and running fine (I think) as I can connect to the pi hole web interface.

I cannot get my dns requests to be sent over the vpn to the pi holer server.

I running ver 18.06.2 and I downloaded the latest policy routing packages yesterday.

I need some help as I'm getting no where expect totally messing up my openwrt install and having to start over from scratch.

Any help would be greatly appreciated.

Thanks
edit: below is my config, that currently doesn't work. For supported interfaces, I tried wan as a test it was orignally set to tun0.

pbr1.JPG878×642 53.8 KB

pbr2.JPG777×812 72.8 KB

SlotTech · 2019-05-01T13:41:00.170Z

@stangri Can you help me out. Below is the output you request for troubleshooting help. I'm trying to route dns request to my remote pi hole server. The vpn is up I just cannot get dns to route to the pi hole.
I'm clearly doing something wrong somewhere I just don't know where, can you point me in the right direction?

Thank you

content of /etc/config/vpn-policy-routing 
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 boot_timeout '30'
	list supported_interface 'tun0'
	option enabled '1'

config policy
	option chain 'PREROUTING'
	option name 'pihole'
	option remote_port '53'
	option proto 'udp'
	option interface 'wan'



output of /etc/init.d/vpn-policy-routing support
	
vpn-policy-routing 0.0.5-0 running on OpenWrt 18.06.2.
============================================================
Dnsmasq version 2.80  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         45.x.x.x      0.0.0.0         UG    0      0        0 eth0
IPv4 Table 201: default via 45.x.x.x dev eth0
IPv4 Table 201 Rules:
32729:  from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via 10.8.0.2 dev tun0
IPv4 Table 202 Rules:
32728:  from all fwmark 0x20000 lookup 202
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -p udp -m multiport --dports 53 -m comment --comment pihole -c 259 17788 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -m set --match-set vpn 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
============================================================
IP Tables FORWARD
-N VPR_FORWARD
============================================================
IP Tables INPUT
-N VPR_INPUT
============================================================
IP Tables OUTPUT
-N VPR_OUTPUT
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create vpn hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]


output of /etc/init.d/vpn-policy-routing reload

Creating table 'wan/45.x.x.x' [✓]
Creating table 'vpn/10.8.0.2' [✓]
Routing 'pihole' via wan [✓]
vpn-policy-routing 0.0.5-0 started on wan/45.x.x.x vpn/10.8.0.2 [✓]
vpn-policy-routing 0.0.5-0 monitoring interfaces: wan vpn [✓]

Dewey · 2019-05-02T06:17:26.837Z

Hi @stangri et al,

I have your policy routing installed on my router - first off, works great, thanks!

However, I'm having an issue with my DNS setup; specifically where I am unable to resolve certain websites - namely: www.amazon.com and a few others I've found so far. The bulk do work though, ie no problem with the likes of www.google.com etc. And I can't for the life of me work out why, but I have narrowed the issue down to something related to when I installed this policy routing service.
Note: No device, either computer or phone can resolve amazon when using the router.

So I did a clean install to see if there was a problem, or if I could pinpoint where the issue was arising, and here are my findings:

With a clean install (of OpenWRT 18.06) with the router taking DNS from my ISP; amazon resolves
Install/Enable openvpn (tun0), with everything forwarded through the VPN interface and putting DNS servers (my VPN company's and google's) on my WAN interface; amazon resolves
Install/Enable VPN Policy-Based Routing, with setup;
- 1st Rule: IP address based policy (10.0.0.101/32) sent to the VPN interface, amazon resolves on this device
- 2nd Rule: All other connections (10.0.0.1/24) sent to the WAN interface, amazon doesn't resolve on any of these devices

I can't pinpoint any further as to where the issue is coming from, and its really strange that most websites do resolve but only a few don't.

I've been trying many options for quite a few days now with no luck, would really appreciate any insights you have, and happy to post up any configs/logs you think might help!

Thanks, D

dk4dk4 · 2019-05-02T18:40:51.416Z

The IP of the URL probably changes (cloud based app (AWS, Azure, etc)) later on after you added the rule. When you add the URL in VPR the IP is cached and then later on the cloud IP changes online making you unable to resolve. I had to add multiple IPs for a URL in the rule in order to get around.. Perhaps this will help...

cybrnook · 2019-05-02T19:17:16.239Z

Like the master mind jedi knight @dk4dk4 stated, it's likely a dynamic IP.

Do a dump of VPR/PBR's rules and see what IP it was using for Amazon. Then, do an nslookup against Amazon to see if the IP changed, bet it did.

stangri · 2019-05-02T21:57:36.432Z

Dewey:

2nd Rule: All other connections (10.0.0.1/24) sent to the WAN interface, amazon doesn't resolve on any of these devices

Do not add any rules which would explicitly include router's local IP address.

SlotTech · 2019-05-03T10:57:32.513Z

Does anyone know where I'm going wrong with my config? I can't be the only one trying to do something like this.

I can get my remote dns requests working with a simple port forward but not policy-based routing. I'd like to use the policy-based routing simply because I can disable strict mode, that way if the pi hole or vpn goes down I still have working dns and working internet.

Or is this out of the scope of what vpn policy-based routing can do?

See 5 posts above for my config.

Thanks

ahmar16 · 2019-05-03T14:29:04.948Z

I think you maybe doing it wrong. I am not an expert on this but I think you should also setup the local port in the VPR config. According to your config everything on the 192.168.1.1/24 should go through port 53 on the WAN side which seems wrong to me.

If a device wants to access DNS it will possibly do it through port 53 on the LAN side. So in your case assuming 192.168.1.1 is your local network you need to specify the local port and not the remote port. Right now you're redirecting everything to port 53 including SSH and that would make the device inaccessible. Again I may be wrong about this.

SlotTech · 2019-05-03T14:49:20.416Z

Thanks @ahmar16 I'll give it a try. I had tried port 53 local and remote and a bunch of other stuff I can't remember. I didn't try what you suggested though. This is above my skill level, so I'm kinda lost at this point.

I'll let you know how your suggestion works out.

SlotTech · 2019-05-03T15:34:51.953Z

@ahmar16 I tried it out an unfortunately that didn't work. No traffic at all to the pi hole.

Thanks for the suggestion though.

Hopefully someone else has some ideas??

This is my current config

Capture.JPG1044×802 64.5 KB

Dewey · 2019-05-04T05:18:49.993Z

Hi @stangri,

Ok, I changed this second rule to exclude the router (which is infact 10.0.0.1); The rule is now 10.0.0.128/25 which covers the IP range 10.0.0.129-254 and I've adjusted my dhcp leasing to match. However, all devices connected to my router in this range are still exhibiting the same issue; navigate to google works, amazon not

vpn-policy-routing: config

config policy
option chain 'PREROUTING'
option local_address '10.0.0.50/32'
option interface 'openvpn'
option proto 'tcp udp'
option name 'vpn'

config policy
option chain 'PREROUTING'
option interface 'wan'
option name 'wan_reserve'
option local_address '10.0.0.64/26'
option proto 'tcp udp'

config policy
option chain 'PREROUTING'
option interface 'wan'
option proto 'tcp udp'
option local_address '10.0.0.128/25'
option name 'wan_lease'

config vpn-policy-routing 'config'
option verbosity '2'
option ipv6_enabled '0'
option strict_enforcement '1'
option boot_timeout '30'
option dnsmasq_enabled '1'
option enabled '1'

vpn-policy-routing: status

This text will be hidden
root@openwrt:~# /etc/init.d/vpn-policy-routing status
vpn-policy-routing 0.0.5-0 running on OpenWrt 18.06.2.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Dnsmasq version 2.80 Copyright (c) 2000-2018 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC no-ID loop-detect inotify dumpfile
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Routes/IP Rules
default 10.8.1.1 128.0.0.0 UG 0 0 0 tun0
default 42-2-XXX-XXX.st 0.0.0.0 UG 0 0 0 eth1
IPv4 Table 201: default via 42.2.XXX.XXX dev eth1
IPv4 Table 201 Rules:
32753: from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via 10.8.1.1 dev tun0
IPv4 Table 202 Rules:
32752: from all fwmark 0x20000 lookup 202
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 10.0.0.50/32 -m comment --comment vpn -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 10.0.0.50/32 -m comment --comment vpn -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 10.0.0.128/25 -m comment --comment wan_lease -c 3562 630245 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 10.0.0.128/25 -m comment --comment wan_lease -c 3570 630604 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 10.0.0.64/26 -m comment --comment wan_reserve -c 641 100199 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 10.0.0.64/26 -m comment --comment wan_reserve -c 642 100401 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -m set --match-set openvpn 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
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
IP Tables FORWARD
-N VPR_FORWARD
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
IP Tables INPUT
-N VPR_INPUT
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
IP Tables OUTPUT
-N VPR_OUTPUT
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create openvpn hash:net family inet hashsize 1024 maxelem 65536 comment
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Pls let me know any other outputs I can provide to help trouble shoot this further. Thanks!

@dk4dk4 & cybrnook Thanks for your input, but I believe there might be some confusion. I'm not using dynamic IP rules or domain name rules in VPR, its a simple local IP rule that directs a certain machine (via its IP address) over the VPN, while all other local IP traffic goes over the WAN.

Cheers, D

Dewey · 2019-05-04T05:19:59.294Z

Hi @shaneog,

Did you ever resolve this? I appear to be having a similar issue??

Thx, D