My goal is to have two SSIDs, “Pie” and “Pie VPN”, where one routes directly to the internet and the other routes through an OpenVPN connection. Media devices(TV, TiVo, AppleTV, Xbox, etc) connect to “Pie”, while other clients have a choice of using the VPN or not based on which SSID they connect to. The reason for needing the choice is that I normally want the VPN connection from my phone and laptop unless I’m watching netflix.
I have successfully set up multiple SSIDs on separate subnets using the guides found on these forums, and it is working great. My only issue now is that when I’m connected to “Pie VPN” I can’t “see” the media devices. For example, I can’t use Airplay to the AppleTV, and I can’t control the TiVo from my phone.
Ultimately, I don’t really need separate subnets. It would be easier for me if I could have everything on the same subnet, but route the devices connected to “Pie VPN” through the vpn. Is that possible?
Here’s my current configuration:
Netgear R8000 on build 28500M
Physical wireless interfaces wl0, wl1, and wl2 have SSID “Pie” and are on br0
Virtual wireless interfaces wl0.1, wl1.1, and wl2.1 have SSID “Pie VPN” and are on br1
br0 has ip config 192.168.42.1/24, with DHCP
br1 has ip config 192.168.43.1/24, with DHCP
In OpenVPN config I have policy based routing for everything on 192.168.43.
What I’d like to do instead:
I’d like to have everything on br0 but have DHCP assign clients from “Pie VPN” from the range .192+, and assign everyone else from the range .128-.191. Then I can just use 192.168.42.192/26 for the OpenVPN PBR config.
I’m also open to other suggestions if this isn’t possible.
Last edited by amcoder on Sat Mar 19, 2016 5:59; edited 2 times in total
So, from what you're saying, it is not possible to have all clients on the same subnet, but route them differently based on which interface they are connected to. You didn't specifically say this, but I assume that also means that DHCP can't distinguish and assign ip addresses differently either. Bummer.
What you said about the built-in policy-based routing makes sense. Right now the clients on "Pie" and "Pie VPN" cannot see each other at all. I see the routes pointing to table 10 for the 192.168.43.* IPs.
Code:
0: from all lookup local
32758: from 192.168.43.128/25 lookup 10
32766: from all lookup main
32767: from all lookup default
And I see that routing table 10 only has the VPN default gateway.
Code:
default via 10.105.1.5 dev tun1
When I add a route for 192.168.42.0/24, I can directly access devices from across the network.
Code:
ip route add 192.168.42.0/24 via 192.168.42.1 table 10
Where is the best place to put this? It looks like I need to run this after the OpenVPN route-up script runs. That routing table gets flushed in the route-down script, so I'd prefer to have whatever I do run every time the VPN connection comes up without having to reboot the router.
This at least gets me direct access to clients across the subnets, which is great! Now I just need network discovery because that is how almost all communication is done between my devices nowadays. I feel like I'm so close.
Do you have any other suggestions, or is this the best I'm going to get?
Posted: Sat Mar 19, 2016 5:52 Post subject: [SOLVED] Multiple SSIDs with OpenVPN and Service Discovery
Success! I now have separate SSIDs on separate subnets, one going directly to the internet and the other going through a VPN, WITH service discovery across the subnets.
I was able to fix the routing table for the devices on the VPN side using a variation of the script from eibgrad. Thanks!
The final piece of the puzzle was Avahi to give me service discovery across subnets. Since I had to install Entware anyway to get Avahi, I disabled the built-in openvpn client and installed the Entware version instead.
Here are the details for how I set this all up:
Before beginning, turn OFF the built-in OpenVPN server and client in Services > VPN.
Set up multiple WLANs
Follow the Multiple WLANS wiki entry.
As noted in “Restricting Access”, add firewall rules to the Administration > Commands > Firewall script to allow the br1 to access the main network on br0 and the internet.
Code:
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Get this working first. I made sure I could connect to both SSIDs and access the internet and directly access other devices across subnets before moving on.
Reboot the router and service discovery should now work across the two networks. I tested this using my iPhone connected to the secondary SSID and my AppleTV and TiVo connected to the main SSID. I was able to use Airplay and control the TiVo from the iPhone even though they are on different subnets
OpenVPN
I was never able to reliably get the internal routes working with the built-in OpenVPN client. Sometimes it worked, but if the OpenVPN connection went down it was hosed until I rebooted the router. I decided to scrap it and install OpenVPN from Entware instead.
Code:
opkg install openvpn-openssl
Install the client .ovpn file from your provider. For example, I used the PIA “US East.ovpn” file. This file should be saved to /opt/etc/openvpn/openvpn.conf. Note that this may also require other files as well, depending on your provider. For example, I also had to copy the PIA ca.crt and crl.pem files to the same location.
Edit the openvpn.conf file and change the auth-user-pass line to:
Code:
auth-user-pass credentials
Add the following to the end of the openvpn.conf file:
Code:
route-noexec
script-security 2
route-up route-up.sh
down down.sh
Create a new file “/opt/etc/openvpn/credentials”. This should contain your VPN username and password on separate lines:
Code:
joeuser
secret
Create a new file “/opt/etc/openvpn/policy_ips” containing a list of ip addresses that should be routed over the VPN:
# Add rules for Policy Based Routing
for ip in `cat policy_ips` ; do
ip rule add from $ip table 10
done
# Add default route
ip route add default via $route_vpn_gateway table 10
# Add local routes
ip route show | grep -Ev '^default|^0.0.0.0/1|^128.0.0.0/1' | while read route; do
ip route add $route table 10
done
ip route flush cache
Create a new file “/opt/etc/openvpn/down.sh”. This script will be run when the VPN connection is closed:
# remove the routing rules for policy based routing
for ip in `cat policy_ips` ; do
ip rule del from $ip table 10
done
# clear the routing table
ip route flush table 10
ip route flush cache
If you want to prevent internet access if the VPN connection goes down, add the following firewall rule to the Administration > Commands > Firewall script:
Code:
# Restrict br1 from accessing internet(VPN Only)
iptables -I FORWARD -i br1 -o `get_wanface` -j DROP
And that’s it!
Thanks to eibgrad for all the explanation and for pointing me in the right direction regarding the issues with policy-based routing in dd-wrt!
Amcoder, thank you for writing this up. I was able to follow it all of the way through with my R7000 running kong 29300 (a bit old, but has really been stable for me). I think everything is working. When I look at "rc.unslug check", everything is running.
When I google "what is my ip address", it comes back with the PIA address. When I visit the PIA website, it tells me I am protected, and when I go to dnsleaktest.com, it gets my location as the chosen openvpn.conf config I loaded. However, when I run the leak test, it shows up with a bunch of Chicago servers and not the expected TX servers.
On DNSleaktest.com, there are procedures for fixing dnsleaks in openvpn 2.3.9 and higher. Apparently you add "block-outside-dns" to the end of your openvpn.conf file... but when I do that, openvpn refuses to load.
I'm assuming this has something to do with the optware version of openvpn that we installed
Code:
me@R7000:~# openvpn --version
OpenVPN 2.3.10 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Mar 23 2016
library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.09
PIA support docs mention that their client has leak protection options available, but it wasn't really clear with how this works... it appears they use different dns servers, but I'm just not sure.
Have you fixed DNS leaks and if so, how did you accomplish this?
Is there a way to verify that traffic is traversing through the VPN "tunnel"? When I run tcpdump, it looks to me that I'm talking directly to the endpoint when I would expect my traffic to be going through a PIA address.
Also, when I try to watch Netflix, it actually works (I'm in the US). I would expect this to NOT work and i was just using it as a test. When I run a speedtest, however, it comes in around 15mb which is quite a bit less than the 95mb I get when on my non-vpn SSID.
Any assistance you can provide would be greatly appreciated. Your guide was spot on and VERY helpful.
Just mostly ignore step 2 and proceed to step 3. Step 3 does not (at this time) tell you to enter the PIA specific DNS servers into the dd-wrt config, but if you do, you will no longer leak DNS.
I tested this with my open SSID as well as my VPN SSID. Both resolved to the same server, but there does not appear to be any drawbacks (yet) for using the PIA DNS servers on your non-VPN SSID. Time will tell I suppose.
Also, for the policy based routing above, when specifying the permitted IPs for the VPN subnet, simply use the network address and not the first host address as listed in the procedures.
Code:
vi /opt/etc/openvpn/policy_ips
192.168.2.0/24
this will put all 192.168.2.X hosts into the openvpn config.
Posted: Fri Mar 24, 2017 22:17 Post subject: Service Discovery
I dont suppose theres a simpler method of getting the Service Discovery to work, like importing a script.
I started a thread here as I was struggling with PBR missing routes. Ive imported eibgrad script and now everything work except service discovery.
Any help would be much appreciated
Sorry to ask, I’m new with DD-WRT and I really tried to figure this out myself but after 4 nights of trying I became quite hopeless.
I’m trying to setup up a split tunnel similar as Amcoder.
These are the interface I have:
br0 > eth1 ath0 ath1 With DHCP 192.168.1.1 start at 100 max 50
br1 > th0.1 192.168.10.1 start at 100 max 50
I can make vpn connection with NordVPN on OpenVPN but I will lose my internet connect on the vpn bridge (br1) as soon as soon as I fill in the policy based routing field.
This is what I fill in:
192.168.10.100/30
192.168.10.104/29
192.168.10.112/28
192.168.10.128/28
192.168.10.144/30
192.168.10.148/31
I have paste the script of Eibgrad in the start up commands. (http://pastebin.com/YwnHLqaa)
I have tried dozens of firewall scripts, additional vpn configs and I have rebooted my router at least 100 times, ok maybe a little bit less;-)
What am I missing?
Is Avahi the solution? Or do I need another router? I now use TP-Link C7 V2, DD-WRT build 32753
C
ould you please point me out in the right direction?
My goal is to have two SSIDs, “Pie” and “Pie VPN”, where one routes directly to the internet and the other routes through an OpenVPN connection. Media devices(TV, TiVo, AppleTV, Xbox, etc) connect to “Pie”, while other clients have a choice of using the VPN or not based on which SSID they connect to. The reason for needing the choice is that I normally want the VPN connection from my phone and laptop unless I’m watching netflix.
Surprised how many people have tried this.
I succeeded without installing any additional software and by just using dd-wrt. It ran on my Linksys E900 router for about a year with no problems - so I can certify as stable. The single band router was transmitting two bands ... one on VPN and the other open.
The above link takes readers through the process I underwent - and I would be happy to respond if someone has queries. The only issue was that the Linksys E900 is not the correct router for this heavy task, though it catered to my home requirement with 7-8 devices connected.
Posted: Wed Oct 03, 2018 20:07 Post subject: Same problem; solved. Disable "Shortcut Forwarding Engi
My setup is similar.. but not exactly the same. The issue solved for me at least for linksys wrt1200ac running DD-WRT v3.0-r36698 std ( 8/22/18 )
The interfaces were configured like:
br0 - eth0
br1 - ath1 ath1.1 (wifi non-vpn lans)
ath1.2 - WiFi VAP configured unbridged, intended for VPN clients (192.168.18.0/24) (dhcpd from 129-190)
tun1 openvpn (nordvpn)
Following the various tutorials noted here for setting up a dedicated WiFi VAP for VPN devices only (ie for netflix), while maintaining a direct internet connection for devices connected to the other interfaces, ran into trouble with tcp connections disappearing into a blackhole after the 3 way handshake when the policy based route is in place.
Before applying the Policy Based Routing configuration (under Services -> VPN -> OpenVPN Client) all interfaces are equally routed over the VPN once it is established.
After applying the PBR for 192.168.18.128/26 the result is the desired effect of direct wan routing of clients from other interfaces (which works well), but a bug is noticed where the VPN stops working properly and blackholes TCP traffic after successful connections. Meanwhile ICMP / ping / traceroute still works when this is happening.
It looks suspiciously like a VPN MTU problem, but isn't. tcpdump had me scratching my head for quite a while... As did writing the configuration a dozen different ways to test..
16 hrs in, reading this thread, noticed the comment "fixed - disabled SFE" (Basic setup -> Optional Settings -> Shortcut Forwarding Engine) So I disabled it, rebooted the router, and .... well, issue fixed!
The clients connected to the WiFi VAP now are all routed over the VPN by the simple policy based route configuration, without TCP blackholes, and clients on other interfaces/networks are routed as intended (not over VPN.)
Its worth noting what seems to be such a simple fix for what otherwise can amount to hours of troubleshooting some really weird VPN PBR related routing behaviour.
reading this thread, noticed the comment "fixed - disabled SFE" (Basic setup -> Optional Settings -> Shortcut Forwarding Engine) So I disabled it, rebooted the router, and .... well, issue fixed!