@kevin -- what was the problem which was fixed by removing wget?
Stangri
I was installing vpnbypass on Lede 17.04.1 on a Foxconn Nano PC
To add the custom repo, I installed ca-certificates wget libopenssl, and then realised my mistake as these were for CC15.05.1
I removed ca-certificates and libopenssl, but left wget in case I needed it in the future
I installed uclient-fetch and libustream-mbedtls, and then added your repo, and opkg update gave wget error 5 (SSL verification failure)
I removed wget and opkg update completed without errors
vpnbypass and luci-app-vpnbypass also installed correctly.
Seems that wget (or one of its dependencies) caused the problem
1 Like
I would love to know more about this workaround with details on how to implement given that domain-based rules aren't working with at least some domains such as Netflix and hulu (and perhaps others) in both VPN Bypass and the newer VPN Policy-Based-Routing services. Anything you could share would be most welcome and appreciated. Thanks!
Did you test it with a simple domain like whatsmyip.org? Netflix is pretty hard to do because it calls out to a very large number of domains--I ended up just bypassing my smart TV for Netflix rather than try to whitelist every domain.
Good idea. Just tried it and site reports the IP of the VPN rather than true IP. So I guess that means the Domain policy is not working?
Sounds like it. You added the leading / and trailing /vpnbypass, correct? So the rule would be /whatsmyip.org/vpnbypass
What are you using for DHCP/DNS? Are you using unbound or just dnsmasq-full?
Yes, format/syntax matches above. Using dnsmaq-full. Not sure about unbound, though... but probably not because I'm not exactly sure what that is 
People warned me it might happen and it actually have happened. 
I need to update the vpnbypass based on experience (and code) I gained with vpn-policy-routing.
If you can stomach the difference in the interface, I would recommend you uninstall vpnbypass and use vpn-policy-routing and luci-app-vpn-policy-routing for now.
Stangri
I've installed LEDE 17.04.1 (x86/64 build) with AirVpn. Everything works fine, but I had to disable IPv6 on the wan interface to prevent IP leakage.
I then installed vpnbypass and luci-app-vpnbypass following instructions in this thread. I want to have one local IP address (7.22.4.8) bypass the VPN, and all others go through the VPN.
When I enable vpnbypass and reboot the router, the PC on 7.22.4.8 looses internet connectivity.
Other local devices still have internet connectivity through the VPN.
I've checked and double checked my setup, and also tinkered with various settings, but the PC on 7.22.4.8 still has no internet connectivity. It can ping other local machines and vice-versa, but not access anything on the internet.
Would you be able to help?
I've uploaded my config files as follows:
firewall https://pastebin.com/WJ7kZHzu
dhcp https://pastebin.com/ZM1W1wdA
network https://pastebin.com/SG3tq4Ac
openvpn https://pastebin.com/w381HGp2
vpnbypass https://pastebin.com/0kabNmR2
Thanks in advance!
Kevin
Kevin,
in my setup I don't have the network.lan.gateway and instead of network.wan.dns I set the default DNS server with dhcp.@dnsmasq[0].server='8.8.8.8' '4.4.4.4'.
Otherwise I don't see what could be messing things up. Just to be on a safe side, what's the output of route?
People warned me it might happen and it actually have happened.
Would you mind elaborating briefly? I'm curious what could've happened since vpnbypass has been working great for me for months.
The concern was that I'll spend more time developing vpn-policy-routing and neglect vpnbypass. I'm on the fence wherever to implement the same dnsmasq integration in vpnbypass now as it will break old configs.
Hopefully a simple problem this, but for some reason whenever I enable a remote port to bypass the VPN that matches one forwarded though the firewall it causes the firewall or something to reject/drop traffic on it. Yet if I remove this port from VPNBypass it then tests as being OPEN again, this never used to happen and quite quite figure out whats different.
This example is for Plex btw, which I have the local port as 32400 and the external one set to a manual one. The only other options I have set in VPNBypass is a local subnet/cidr that should bypass the VPN and this I know still works.
Any suggestions then let me know please,
Thanks.
Probably something to do with the firewall config. I've just tested what Plex wants to open thru UPnP and here's the list of iptables the upnpd inserted into nat table:
Chain MINIUPNPD (1 references)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:17076 to:192.168.1.*:32400
Chain MINIUPNPD-POSTROUTING (1 references)
target prot opt source destination
MASQUERADE tcp -- 192.168.1.* anywhere tcp spt:32400 masq ports: 17076
If you don't want to configure UPnP on your system (to be available for Plex Server only), you will need to make sure that whatever you create in the fw3 config results in similar two iptables rules. Or, if you're not concerned with having UPnP daemon on your router just use that.
Good luck!
I decided against UPnP and did everything manually, it's just this was working before a recent firmware update, so may well be something not set up in the same way.
I am a bit of a newb when it comes to iptables or how to edit them though sadly. However I did just switch to your policy-routing app instead, although so far no luck, but I am still figuring it out 
Can we make this consumer-centric? I, as geek (much like you all reading this) can manage it as it is. But, my purposes for it would be more along the lines of installing upon pre-flashed USB / SD devices, for distribution amongst a whole lot of neighbors, for the sake of mesh-net and various other decentralized comms capabilities (think post-SHTF, grid is down).
Did you accidentally post this reply in a wrong thread? I don't think VPN Bypass will do you much good in the "grid down" scenario.
Nope, not even a little bit.
I get the confusion, however. Most VPNs aren't so grid-independent as cjdns, tinc, wireguard, etc.
Does that mean that they aren't VPNs? Or were we just talking about VPNs that are dependent upon the oh-so-unreliable OPN/OPI (Other Peoples' Networks / Infrastructure)?
That wasn't specified, nor is it terribly relevant to the issue, is it?
Hi @stangri,
I've been using vpnbypass happily for awhile now but I recently made some changes to my network setup and everything seems to break now when the VPN tunnel is up. I've been investigating for a couple of weeks now and I was hoping you could offer some insight into the problem.
Before, I just had one lan network--everything worked, lan traffic was routed through the VPN tunnel and WAN to LAN port forwards worked. I added a DMZ interface on a separate VLAN with a vpnbypass rule for the local dmz subnet. This is when things started breaking:
With the tunnel down, everything works as expected, including port forwards, traffic from LAN to DMZ, DMZ to WAN, etc. With the tunnel up (and a bypass rule for the DMZ subnet), LAN to DMZ doesn't work, port forwards from WAN to LAN don't work, but DMZ to WAN and port forwards from WAN to DMZ DO work.
I've enabled logging on all firewall zones and I'm not seeing any rejected traffic, so I'm thinking it's a routing issue rather than a firewall one. Do you know if I'm running into some limitation with vpnbypass that vpn-policy-based-routing might be able to solve? I'm happy to ask elsewhere but it'd be really helpful to get your opinion about whether vpnbypass could be related to these issues or if it's just a more general networking problem. Thanks!
update: I've made a little progress following the advice here and adding a route like this:
ip rule add from 10.1.1.0/24 table dmz
ip route add 192.168.1.0/24 via 192.168.1.1 dev br-lan table dmz
Are these commands what vpn-policy-based-routing does behind the scenes?
I can now access the DMZ from the LAN and not vice versa, which is what I want. However, port forwards from the WAN to the LAN still are not working. I've been packet sniffing with tcpdump and the target host is receiving the traffic and replying, but the packets seem to be being routed over the wrong interface (tun0 instead of the WAN?). Any ideas on how to get the port forwarding working with this setup? I'm happy to try vpn-policy-based-routing if you think that'll work. I'm just really confused at this point about why port forwards were working perfectly before adding the DMZ interface.
Second update: Not sure why this didn't occur to me before, but simply adding a vpnbypass rule for the local port I'm forwarding makes it work.
1 Like
For those curious about negating netflix issues using vpnbypass, I've had success in excluding amazon.com (aws servers are used by netflix). Of course, this means all requests to aws servers are bypassed, so something to consider carefully.
1 Like