I have a temporary setup on my Asus RT-AC68U C1, running DD-WRT v3.0-r55779 std (04/12/24), where I share Iphone tethered network. My brother is running second router (Netgear) running OpenVPN server. Our Netflix Household is tied to that Netgear router. I managed to get the ASUS router connected trough the VPN and get correct public IP address, but there appears to be some additional checks other than the public IP. Possibly the MAC is checked against the MAC of the NETGEAR router.
What would be the correct setup for this scenario? I think I would like the TV to think it is speaking directly to the Netgear router, unaware that there is a VPN connection happening. I have managed to get it working with TAP mode, but would it be better to use TUN mode? I was able to get it working with ASUS merlin a while back, but I switched to dd-wrt, to get the Iphone tethering support, I remember having some problems also then, but got it working in the end.
One problem I have is that both routers are serving 192.168.1.0/24 networks. 192.168.1.1 is the Netgear router and 192.168.1.2 is the ASUS router. One problem is that I cannot connect to the ASUS management webui (192.168.1.2) while VPN connection is up, but I can access Netgear management webui (192.168.1.1). Additionally it would be nice to dedicate a single LAN port that would use the VPN only.
Thank you for your reply. I have read at least most of the OpenVPN guides. What I missed was some information about the other settings I should configure when setting up the VPN. For example should I use gateway or router mode? I guess I should use different IP-ranges for both of the devices, but I only managed to get it working when setting ASUS router in same IP range.
The VPN server is Netgear (Don't remember model) running stock firmware, so running wireguard probably not an option.
Thank you for the hint about DNS. Should "block-outside-dns" be enought? Is there some easy way to verify it is working?
Additionally it would be nice to dedicate a single LAN port that would use the VPN only.
I also have the ASUS RT-AC68U and know the following will work.
1. Reset the router to factory defaults (do NOT simply try to reconfigure from the current state).
2. Setup->Basic Setup: Configure the default/local IP network (br0) to something other than that used by the remote IP network of the OpenVPN server (e.g., 10.0.0.1/24). This is important in order to avoid routing issues!
Hit Save.
Wireless->Wireless Security: Configure your wireless security settings.
Hit Save, then Administration->Reboot
3. Setup->Switch Config: Enable VLANs.
Hit Save, then Administration->Reboot
4. Setup->Switch Config: Configure a new VLAN (e.g., vlan3) and move port #4 (or more ports if you want) from the default VLAN (vlan1) over to the new VLAN.
Hit Save, then Administration->Reboot
Note: Upon reboot, Do NOT configure the new VLAN any further on the Setup->Networking page; leave it at Default (bridged).
5. (Optional) Wireless->Basic Settings: If you'd like to include wireless support, then you can add one or more VAPs (e.g., wl0.1, wl1.1) to the configuration.
Hit Save.
Wireless->Wireless Security: Configure your wireless security settings.
Hit Save, then Administration->Reboot
Note: Upon reboot, Do NOT configure the new VAP(s) any further on the Setup->Networking page; leave them at Default (bridged).
6. Setup->Networking: Create a new bridge (e.g., br1).
Hit Save, then Administration->Reboot
7. Setup->Networking: Disable ALL features on br1. Do NOT configure IP on the new bridge either.
Hit Save, then Administration->Reboot
8. Setup->Networking: Assign the new VLAN and any VAPs to the new bridge (by default, they've probably been assigned to br0).
Hit Save, then Administration->Reboot
9. Configure the OpenVPN client. Under Advanced Options, do NOT "Bridge TAP to br0".
When you establish the bridged OpenVPN client connection, you'll want the tunnel (tap1) assigned to the new bridge (br1). You can use a route-up script for that purpose.
Enable JFFS and copy/paste the above into the terminal window of an SSH session on the router. It will create the necessary route-up.sh script for the OpenVPN client. You'll need to add the following to the Additional Config field as well.
Code:
script-security 2
route-up /jffs/route-up.sh
Hit Save, then Administration->Reboot
Upon reboot, and assuming the OpenVPN client connects successfully, you'll now have two separate IP networks, br0 and br1. You access the remote IP network of the VPN over the port(s) you assigned to vlan3 and the VAPs (if applicable). You can bypass the VPN and manage the router from the br0 network on ports #1 thru #3 (or whatever you did NOT move to vlan3) and the APs. Beware, devices on br0 and br1 have total network isolation from each other. Even the router itself can only manage br1. It can't access its IP network for routing purposes.
Why all the Save and Reboots? Because DD-WRT can be very finicky and error-prone when it comes to dealing w/ VLANs, VAPs, bridges, etc. The router will automatically reboot itself w/ certain changes when using Apply Settings. I purposely avoid that option and only use Save. Time and again I've seen the router mess up these kinds of configurations unless you reboot after *every* change! And I'd rather control exactly when the reboot occurs by using Save rather than Apply Settings. You'll avoid a LOT of frustration if you do the same.
Joined: 16 Jun 2006 Posts: 221 Location: Germany, BW
Posted: Sun Sep 29, 2024 12:23 Post subject:
I also use OpenVpn Site-to-site Bridge (TAP).
My purpose is to share DLNA, but all other services like Prime or Netflix are also working but is not needed as my Kids have their own.
@egc did a very good OVPN-Server Guide with a TAP Part at the end.
I have a different config to keep it simple and to put all TVs and other stuff (IoT) in a separated Subnet.
On all sites I have an own Internet-Router (also providing the "normal" Subnet), after that the DD-WRT-Box with the IoT-Subnet.
The main reason to separate TVs and some other stuff by an own Subnet is that especially Samsung-TVs are scanning the network and search for other Samsung stuff.
You can see that under the Active IP-Connections, each Samsung-TV sends dozens of requests on Port 15600, you can search for that on internet. I blocked that with
iptables -I INPUT -p udp --match multiport --dport 15600,33969 -j DROP
but about 2 seconds later the TV uses another Port and after the seventh Port I gave up. The list of blocked Ports will become longer that the chinese wall I think.
1. You MUST use TAP mode, otherwise Netflix and Co. see you using VPN. You need to have all non IP-related communication like Broadcasts, Bonjour-blabla and so on on both sides.
2. The networks on both sides MUST be the same subnet in TAP-Mode (otherwise the config is screwed). The goal is to appear as one network.
3. Disable Compression.
4. I disabled DHCP on Client-side, (read @egc Guide)
5. On Server-side I activated "Default Gateway" and removed on Server-side additional Config " route-Gateway..".
6. Use on Server-Side in additional Setting "disable-dco".
OVPN does not support DCO for TAP-Mode. Normally OVPN disables DCO by itself when TAP is used, but there was at least one DD-WRT-Build where this wasn't the case and my VPN was blocked.
7. I disabled SFE.
I remember doing some OVPN-posts, maybe you can find some helpful infos.
Would be helpful if you can provide the server-settings too.
Last edited by Sp1derman on Sun Sep 29, 2024 13:00; edited 1 time in total
Joined: 18 Mar 2014 Posts: 13423 Location: Netherlands
Posted: Sun Sep 29, 2024 12:45 Post subject:
Sp1derman wrote:
1. You MUST use TAP mode, otherwise Netflix and Co. see you using VPN. You need to have all non IP-related communication like Broadcasts, Bonjour-blabla and so on on both sides.
I do not think that is necessary for Netflix.
The Netflix app is running on the client and what Netflix checks is the Public IP address and DNS origin (they might check more like webRTC etc)
I can perfectly fine use American Netflix (much more content) when connected via WireGuard with my American based VPS from the Netherlands.
So I think for Netflix using a routed tun setup will be fine
Note if you use PBR you have to use Split DNS as outlined in the guide.
Joined: 16 Jun 2006 Posts: 221 Location: Germany, BW
Posted: Sun Sep 29, 2024 13:40 Post subject:
egc wrote:
I do not think that is necessary for Netflix.
The Netflix app is running on the client and what Netflix checks is the Public IP address and DNS origin (they might check more like webRTC etc)
I can perfectly fine use American Netflix (much more content) when connected via WireGuard with my American based VPS from the Netherlands.
Netflix allows you to use VPN (--> Netflix VPN <--) but they don't allow you to share your account over different locations.
I'm not an expert in this but I think that e.g. a simple traceroute should look the same from all VPN sites and afaik with TUN it's not the same, with TAP it is.
A short Internet search shows me that folks trying Account-Sharing via TUN get a note on TV to activate something like "Guest-Account".
But at least I'm not 100% sure ( but 99% ) as I didn't tried this.
iptables -t nat -A POSTROUTING -o br1 -j MASQUERADE
4. Use this new OpenVPN script (/jffs/route-updn.sh) instead of the prior script. As before, just copy/paste it into an SSH terminal window on the router to create and install it.
I left the script w/ debug mode enabled in case any problems pop up, but for the long hual, that can be disabled once it's working satisfactorily.
5. Beware, you can NOT use the Watchdog option on the OpenVPN client GUI when using a bridged tunnel if that tunnel is assigned to one of the router's bridges (e.g., br1)! That's because the built-in watchdog pings the tunnel's network interface (tap1). But when that gets assigned to (in my example) br1, you LOSE access to that network interface! You can only access tap1 indirectly, via br1.
I'm presently working on a solution for this situation w/ my own OpenVPN client watchdog script on PasteBin. It will either involve detecting the bridge assignment of tap1 and moving the ping check to the bridge (br1), or else abandoning ping checks entirely (which can be done today) and only checking for failure/stoppage of the OpenVPN client (my script does BOTH types of checks). See my signature for the link.
Yes, this is a bit of a bug in the GUI, at least if you assign the tunnel's network interface to one of the router's own bridges, which I suspect is very common. I'm less sure how common it is to need a watchdog in that situation anyway.
In summary ...
This makes it particularly convenient for administrative purposes, but it may also prove useful simply for the ability to route to the remote network as if you had configured an OpenVPN routed (TUN) tunnel.
All of this was accomplished using a T-Mobile TM-AC1900 (aka ASUS RT-AC68U) router. Since it involves VLANs, and VLANs have always been tricky w/ DD-WRT using the GUI, I can't speak to other routers.
