seems to have taken
root@LEDE:~# ip6tables -t mangle -I OPR_CHAIN 1 -j MARK --set-xmark 0x020000/0xff0000 -d 2620:f9::/48
root@LEDE:~#
I sent you a PM with the output of "support" and "support -d".
I think I just need a route and a firewall entry to allow access to/from 192.168.5.1 but I do not have enough knowledge to figure this out correctly. I suppose some other newbies may be in the same situation.
Explanation of my setup/problem from prior post 209
Fixed in 4.1.4-23.
Firstly thanks so much for this package - it's saved me a huge headache in trying to setup my own firewalling and routing for my UK-USA OpenVPN setup.
I'm having a small problem though. Traffic is mostly routing correctly, but it appears that if a device is matched in the luci policy interface that it's unable to contact the gateway directly. In other words, if I set a specific computer on the internal network in the policy it can no longer see the luci interface. This appears to be the case regardless of which gateway is selected. Is this the intended behaviour?
The main issue this causes is that I don't appear to be able to use the router for e.g. DNS forwarding. Is there something obvious I'm missing?
Unfortunately my router currently only supports the padavan firmware + entware and canât use these packages. Assuming you arenât planning to support that environment, could you perhaps share a few links that explain at bare minimum how I would need to configure the various underlying tools to route through VPN based on domain name?
Not sure I quite understand what the problem is and what might be causing it without seeing the /etc/config/dhcp and the /etc/config/openvpn-policy-routing.
I'm not familiar with that firmware at all. If it has uci, iptables and sourced function scripts, maybe you can ask for guidance of using OpenWrt PROCD init scripts on that firmware forum and try copying just the openvpn-policy-routing.init file from my github as /etc/init.d/openvpn-policy-routing on your router.
I'm trying to get rid of the annoying procd: Not starting instance openvpn-policy-routing::instance1, command not set log entry in the most recent LEDE, so I've removed some PROCD-related code in 4.1.4-24, I hope it wouldn't affect the triggers set in the script to react to changes in any interface or firewall or config file changes, please let me know if OPR stops reacting to those changes on your router (especially on stable releases).
Understood! My /etc/config/dhcp:
config dnsmasq
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option domainneeded '1'
list address '/tinyproxy.stats/192.168.70.1'
list server '208.67.222.222'
list server '208.67.220.220'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
option ra_management '1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
There are also static host definitions below this but nothing controversial. My openvpn-policy-routing:
config policy
option comment 'iPad'
option gateway 'tun0'
option local_addrs '192.168.70.187'
config openvpn-policy-routing 'config'
option verbosity '2'
option enabled '1'
option strict_enforcement '0'
config policy
option comment 'Roku'
option local_addrs '192.168.70.102'
option gateway 'tun0'
In this configuration the iPad for example is unable to see the luci page served at 192.168.70.1.
Weird, I can access Luci from the machines which are routed via either tun0 (default in my case) or wan no problem.
Are you sure you haven't hardcoded your VPN provider DNS server in the iPad IP config? If not, maybe try inserting a rule with remote_addrs '192.168.70.1' and 'wan' gateway at the top?
NAT Loopback / reflection via the WAN does not seem to be working and just seems to time out, external access from outside the LAN is fine to servers behind the nat, could anyone offer any advice?
here is an output from support
openvpn-policy-routing 4.1.4-22 running on LEDE 17.01.0. WAN (IPv4): wan/195.166.130.252.
Dnsmasq version 2.76 Copyright (c) 2000-2016 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 lo0.central10.p 0.0.0.0 UG 0 0 0 pppoe-wan
default 10.7.7.1 0.0.0.0 UG 20 0 0 tun0
32760: from all fwmark 0x20000 lookup 201
32761: from all fwmark 0x10000 lookup 200
IP Tables
OPR_CHAIN all -- anywhere anywhere [goto] mark match 0x0/0xff0000
-N OPR_CHAIN
-A OPR_CHAIN -s 192.168.254.0/24 -c 128 15994 -j MARK --set-xmark 0x10000/0xff0000
-A OPR_CHAIN -s 192.168.254.106/32 -c 1 60 -j MARK --set-xmark 0x20000/0xff0000
-A OPR_CHAIN -m set --match-set wanroute dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A OPR_CHAIN -m set --match-set tun0route dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
IPv6 Tables
OPR_CHAIN all anywhere anywhere [goto] mark match 0x0/0xff0000
-N OPR_CHAIN
Current ipsets
create wanroute hash:ip family inet hashsize 1024 maxelem 65536
create tun0route hash:ip family inet hashsize 1024 maxelem 65536
create wanlist list:set size 8
add wanlist wanroute
create tun0list list:set size 8
add tun0list tun0route
and a route print
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default lo0.central10.p 0.0.0.0 UG 0 0 0 pppoe-wan
default 10.7.7.1 0.0.0.0 UG 20 0 0 tun0
10.7.7.0 * 255.255.255.0 U 0 0 0 tun0
192.168.254.0 * 255.255.255.0 U 0 0 0 br-lan
195.166.130.252 * 255.255.255.255 UH 0 0 0 pppoe-wan
with 192.168.254.x as the subnet which the NAT'd servers it on
Er nope! That seemed to prevent everyone on the LAN from seeing 192.168.70.1 entirely. Very odd. I will dig into this further and try to find out what's going on.
ignore me, i manually had to add the following for each forward rule
option reflection '1'
option reflection_src 'external'
the GUI did not seem to be adding it properly
1 Like
Hi Stangri - gotta say you're an absolute legend for making this. I cant recall how many hours I fluffed around trying to get this sort of thing to work on my own, with only failure!
So I mainly just want port based rules, I left your default Plex one in, cause that's one I want. I get 'indirect' server access now - is that intended, or should I be getting direct access?
Also, for other services, for example sabnzbd, running on port 8080, I add that to your interface, but then using my WANIP:8080 I cant access - am i doing something wrong? Do I need to 'port forward'?
I get direct access. Make sure UPnP is enabled and working, there's no double-nat and that you allow plex.direct to break rebind protection.
Either port forward or UPnP should work.
I am trying to bypass my VPN for only Netflix using Domain-Based Policies and it seems to work OK for "whatismyipaddress.com" but it does not work for Netflix. I always get the Netflix error on the screen on not to use proxies.
My entries in DCHP config are:
list ipset '/netflix.com/nflxvideo.net/nflximg.net/nflxext.com/wanroute'
list ipset '/whatismyipaddress.com/wanroute'
Has anyone got the Domain-Based Policies to work for Netflix only going through the WAN and not the VPN (tun0)?
If so, could you post your setup?
I enabled port forward and now (in Plex Server settings) I get "Fully accessible outside your network" for a few seconds, then it switches back to "Not available outside your network".
The bit below that that lists the private and public IP's also lists my VPN IP as public IP...
I'm not sure what that means sorry?
EDIT; nevermind, I discovered DNS rebind protection as a thing. I tried to add "dhcp.@dnsmasq[0].rebind_domain='plex.direct'" - it didn't seem to work, but then I discovered why pihole wasn't working properly, dbs rebind protection screws pihole up, so I just disabled rebind protection altogether... Plex and Pihole work great now thanks.
No one has got this to work for Netflix yet??
I don't use Netflix but see post number 5 here https://forum.openwrt.org/viewtopic.php?id=54048
But creating dnslog you are able to see all dnslookups made when you connect to Netflix. I suspect it goes beyond just "netflix.com" (you'll see it in the log) and you have to add all of those to your wanroute.
Feel free to post the results here for others to use....
I am trying to setup my routing to go through the WAN by default and VPN only if selected in OPR. I tried various combination of the README instructions below but the setups will not survive a reboot.
I tried "route_nopull" and "route_noexec" but I seem to be missing something basic to get it to be setup on reboot. On some combinations of above I can get it to work on restart of OPR.
I use PIA (Private Internet Access) VPN service setup via OpenVPN Service GUI and it works great but routes through the VPN by default. I would like it to route through the WAN (my ISP) by default.
Anyone have this type of setup working?
OPR README Extract
Service does not alter the default routing. Depending on your OpenVPN settings (and settings of the OpenVPN server you are connecting to), the default routing might be set to go via WAN or via OpenVPN tunnel. This service affects only routing of the traffic matching the policies. If you want to override default routing, consider adding the following to your OpenVPN tunnel(s) configs:
option route_nopull '1'
option route '0.0.0.0 0.0.0.0'
Thanks, will give it try and post results if successful.