No, it should only happen on Turris routers running obsolete OpenWrt 15.05.
Hey. Im using OpenVPN on my router with VPN Policy Based routing (software is amazing btw.) to route couple devices through OpenVPN and everything is working great except port forwarding. I want to power on my device with Wake On Lan from WAN and it's working great only when there is no rule set up (device is not using VPN at this time). When I create rule for device to use VPN, it work's except port forwarding.
I was doing some testing and I discovered that port forward is working when I make rule like this: https://cdn3.imggmi.com/uploads/2019/4/24/42dfbbeef7314280ca6a5f35dccd9474-full.png Port 450 is this WOL service.
I am wondering... Everything is (i think) working fine.Traceroute goes through VPN also HTTP traffic etc. within that range i have set up. Port forwarding is working also fine. Only pings from what i seen are going through WAN but I think this is expected behavior because of Network Layer? Can this affect privacy, DNS leaks or included KillSwitch? Maybe there is any other (proper) way to forward port from WAN while using VPN service?
Thanks and sorry for my English.
I am using davidc502' latest build "OpenWrt SNAPSHOT r9886-399aa0b933 / LuCI Master (f138fc93)" on a WRT3200ACM.
How do I correct this problem?
EDIT: checked my VPR config file and all seems OK. VPR seems to run OK also but just the strange status message.
Will wait for an updated VPR build to see if error remains.
Please confirm versions of both VPR and the luci app you have installed.
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/188.8.131.52' [✓] 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/184.108.40.206 vpn/10.211.1.34 [✓] vpn-policy-routing 0.0.4-6 monitoring interfaces: wan vpn [✓]
Sorry, I should have included it in the first post:
- VPR = 0.0.4-6
- Luci App VPR = git-19.113.55792-3c7b3fa-38
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.
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.
Issue: "Started without PROCD support" - Fixed with VPR Updates to both VPR packages: -7 & -39
@stangri - Thanks for all your hard work!
I've asked for a proper solution of the problem here: Ubus CLI and snapshots.
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.
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.
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.
@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?
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 [✓]
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!
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...
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.
Do not add any rules which would explicitly include router's local IP address.
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.
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.
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.