Anyone have any ideas???
I have a cosmetic bug report:
When going into the luci OpenVPN menu, the ui acts as if two entries are selected at once (darkmatter luci theme).
I think this due to the entry name "OpenVPN Routing". It causes luci to think "OpenVPN" and "OpenVPN Routing" are selected at the same time, which then leads to side menus to collapse when they should not.
My educated guess is that it could be easily fixed by removing the white space (i.e. rename the luci entry to "OpenVPNRouting").
Other than that your package works really well for me, so thank you!
Found the problem. I set no_pull but I did not enter a route in OpenVPN config. Then rebooted. Did not work, it was missing a VPN Table 201 entry in the route status page. On OPR restart via GUI the Table 201 route is now there.
On review of syslog it seems my DNDMasq process is not fully finished before OPR starts and therefore VPN route is not setup correctly.
A work-around for it to work on reboot is to put "/etc/init.d/openvpn-policy-routing restart" in the Local Startup (/etc/rc.local). I did via GUI. This forces OPR to restart after all other services have been started. Seems to work for me.
Is there a way to add a delay to the start of the OPR service so I do not have to do this work-around?
I also have a similar issue with theme-material with luci-app-openvpn and luci-app-openvpn-policy-routing installed, however default theme doesn't exhibit any problems at all, making me believe it's a specific theme problem, not the luci problem. I've also had to hack a luci map-file for the theme-material to properly display the Web UI, so it's not the only bug. If darkmatter theme developer is active, maybe post an issue against the theme?
OPR sets triggers so that it's restarted on many different events. When my router boots, OPR starts and then is being restarted 2 times without additional /etc/rc.local entries.
Which router and LEDE version are you using? If you could capture the syslog up to a point where you can connect wireless devices to it, I'll try to compare it against EA8500/WRT3200 logs to see what might be going wrong. However I'm away from home until July and I don't want to reboot the router while I'm away.
I will send you a version of the syslog that I now have setup with the additional "reload". I changed it from restart to reload as I thought it was less intervention. I also put a "sleep 10" before the "reload" just to make sure all other services were done. Looking closer it may not be the DNSMasq but OpenVPN not completing prior to OPR.
No worries about the time, I will keep learning by the "hit & miss" method but if you can help out that would be greatly appreciated.
Futher to my Netflix problem:
I have OPR setup to have my Android tablet on the VPN as a normal situation. When I try Netflix in my country (not trying to get other country content) it comes up with a proxy error statement. If I set OPR for the tablet static IP to WAN it works fine. But I would like the VPN active for non-Netflix traffic on the tablet.
I then tried to exclude all Netflix domains by sending them to WANROUTE in OPR. Still the same problem. Here are my domain based routes for OPR that I found with DNSMasq logging as recommended by @dziny:
/netflix.com/nflxvideo.net/nflximg.net/nflximg.com/nflxext.com/wanroute
/edgesuite.net/akamaiedge.net/akamai.net/wanroute
/google.com/wanroute
/btstatic.com/amazonaws.com/wanroute
From internet searches it seems to be a Netflix check problem involving DNS comparisons but it is way above my understanding.
Can anyone help me out to get the tablet going through the VPN but Netflix working as it does through the WAN?
Have you tried routing external port 53 thru WAN?
Thanks to @FCS001FCS reporting that OPR restart does not get triggered by successful OpenVPN connection if the route 'no_pull' option is used (so OpenVPN does not update firewall I guess and that results in OPR not being restarted) -- in that case OPR starts before OpenVPN establishes the connection, OPR doesn't get restarted when OpenVPN connection is established, resulting in all VPN traffic being blocked.
I don't know how can I get OPR restart triggered by successful OpenVPN connection in this case and if any of the wiser minds reading this do -- please let me know, so for now I've tried to scan all tun* interfaces on boot and wait for them when OPR starts during router boot up. If there's a more elegant solution to this problem, please let me know.
The OPR 4.1.5-1 contains the change mentioned above. I'm away from home for a few months, so sadly I can't test this new build.
I have a similar issue with Domain Policy not working at all (IP Policy works perfectly fine). I've added route_nopull only, however when I add route '0.0.0.0 0.0.0.0', I cannot open any webpage, on any device. Don't know if DNSCrypt-proxy or/and adblock might affect it somehow.
My router WRT1900AC v.1 with David's Lede Reboot SNAPSHOT r4049-9412fc2 / LuCI Master (git-17.117.26217-26fb47b) version (4.4.61).
My default traffic should go through WAN and only some domains need to be trafficked through VPN (PIA).
Upd: I've just updated OPR to the latest 4.1.5-1 version, however the issue still exists. Thanks.
what does logread -e policy or OPR support command say?
service openvpn-policy-routing restart
openvpn-policy-routing 4.1.5-1 stopped ✓
creating table wan/eth1/88.999.99.1/wanroute [✓]
creating table PIA/tun0/10.30.99.99/tun0route [✓]
routing 'Plex Remote Access' 192.168.1.1/24:32400 to ... via wan [✓]
routing 'Temp' 192.168.1.16 to ... via tun0 [✓]
routing dnsmasq policies ✓✓✓✓✓✓✓✓✓✓✓
openvpn-policy-routing 4.1.5-1 started wan/88.999.99.1 PIA/10.30.99.99 ✓
Thanks.
Weird, from what the logread says it should be working. Make sure you don't have your local devices/router configured for another server for name resolution.
I also had to leave out "route" '0.0.0.0 0.0.0.0'. VPN would not work with it in the PIA VPN Config. I just used "route-nopull". Do not know why or if it is important.
Is your firewall settings as the following?
For me -- no, it'd be PIA -> REJECT.
It seems that @stangri is correct. I got the PIA setup from the web but not sure where. It seemed logical to me.
I'm working with a user who has a large number of policies and for whom the OPR doesn't seem to restart when the OpenVPN connection is established*. So I'll be playing with various boot/start_service options in the next few of the 4.1.5-x builds. If you're happy with how OPR works for you, don't upgrade until further notice.
*: OPR starts almost at the same time as OpenVPN, but because OpenVPN takes a while to settle, without a very large number of policies, OPR finishes its start before OpenVPN connection is established and once the OpenVPN connection is established, OPR is automatically restarted.
Sorry Stangri, I need some more help re: plex. I have upnp installed and enabled (and it picks up port 32400, so appears to be working correctly). I have this installed, and left your default setting as is (though I added another one, and it is working, so this appears to be working). I've also disabled rebind protection altogether.
However, when I enable (or click retry) on the remote access in plex, it thinks for a while, then displays "Fully accessible outside your network" for 1-2 seconds then flicks back to "Not available outside your network". Also of note, plex detects my public IP as my PIA VPN IP, not my wan IP... in practical terms, from outside the lan, I have "indirect" plex access.
I do not have a double nat as far as I'm aware, I have a router running in bridged mode, so modem only, then my LEDE router. If i disconnect from VPN plex is fully open.
For your entertainment, here's a short video of what happens... https://vimeo.com/217288550
Any thoughts? many thanks
Post (better yet PM me) the output of /etc/init.d/openvpn-policy-routing support plex.tv my.plexapp.com and the content of the /etc/config/dhcp.
For anyone else with a similar problem, my log was rather normal and I just needed to do the following. Plex now fully open. Thanks stangri.
1 Like