NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
OpenVPN connects to router when clients on Ethernet but not on Wifi
I am having difficulty getting OpenVPN to work to connect to my RS300 router with my Windows 11 computers. I have a Dell XPS 16 9640 and a Microsoft Surface Pro 2103 both running Windows 11 Pro. Both computers have the same issue. The router is a Netgear Nighthawk RS300 v 1.0.5.18. The client computers are running OpenVPN 2.6.14 and GUI 11.55.0.0
I want to connect to the RS300 "remote" LAN via the VPN tunnel and the internet through the local LAN at the client location. This works perfectly as long as the client computers are connected to their local LAN via a hardwired Ethernet connection. If the client computers are connected with a WI-fi connection (which works perfectly without the VPN) on the same local network, there are issues. The VPN still connects properly. The router status shows the active VPN connection is successful. File explorer shows the remote LAN devices properly. However, none of the 3 browsers I have tried can access devices on the remote LAN or access the internet. Although not a complete test, the same thing happens when trying to us a public WI-fi connection at a different location. I have tried the usual things. I run the Open VPN as administrator. I have tried changing the adapter metric, placing the various Wi-fi, Ethernet and VPN adapters in various priorities. I have disabled the firewall. There is no subnet overlap. At this point, I am out of ideas.
Without making any changes, the VPN connection now works over wi-fi on the Dell laptop. The only change was a firmware update from Dell including for the wi-fi adapter. I tried updating the firmware on the tablet, but the problem still persists on that computer. I will continue to look at the difference between the tunnels and see what the difference is and if I can override it.
20 Replies
Thanks for the response. It might be easier to put the Ethernet and WiFi log files on cloud storage and post Links to them?
Each Netgear WiFi family seems to implement VPN connections differently.
- The original WiFi5 Orbi systems put VPN connections in a subnet "one up" from the primary IP subnet. i.e.
If the primary subnet is the default (192.168.1.x) then VPN connections receive IPs in 192.168.2.x - The WiFi6 Orbi systems put VPN connections in 192.168.254.x. I have an RBR750 that has a primary IP subnet of 10.10.0.x
When a device connects to the RBR750 over VPN, it gets an IP in 192.168.254.x
Alas, I have no experience with the RS product line. Perhaps Netgear decided to place devices connecting via VPN into the primary IP subnet (in this case 192.168.1.x)
Another consideration is the 'mode'. OpenVPN supports two types of connections: tap (for "network tap") and tun (for "tunnel")
Do an internet search for details. AI summary:The default configuration file for Windows computers is tap, using UDP port 12974. With the latest versions of OpenVPN, I have been more successful manually changing the configuration to tun, port 12973. i.e.:
client dev tun proto udp remote xxxxxxx.mynetgear.com 12973With the latest versions of OpenVPN, I have been more successful manually changing the configuration to tun, port 12973
KngDa - I also found I needed to do this (though with an Orbi system, not the RS300). Might be worth a try (though in my case I needed it to connect to remote servers connected with ethernet, so my symptoms were a bit different).
In addition, it marked three of them as SPAM.
FWIW, ReadyNAS log snippets are often marked as SPAM by the automated filter. That was also the case with the old forum software. I wish they'd adjust the filter to fix that.
- The original WiFi5 Orbi systems put VPN connections in a subnet "one up" from the primary IP subnet. i.e.
The long posts appear to be difficult for the Forum software to handle. In addition, it marked three of them as SPAM. It may be easier to begin a new conversation than to continue with this one.
Changing to TUN solves my recursive routing problem. Unfortunately one of the software packages I am running relies on network discovery to connect to the device on the server LAN. That of course, doesn't work with Network layer 3 TUN. I will continue to chase why I get the recursive routing issue with wifi only.
Without making any changes, the VPN connection now works over wi-fi on the Dell laptop. The only change was a firmware update from Dell including for the wi-fi adapter. I tried updating the firmware on the tablet, but the problem still persists on that computer. I will continue to look at the difference between the tunnels and see what the difference is and if I can override it.
Without making any changes, the VPN connection now works over wi-fi on the Dell laptop.
Great.
I will continue to look at the difference between the tunnels and see what the difference is and if I can override it.
If this is an iPad or Android tablet, you should start with the mobile config file you download from the router.
The tablet is a Microsoft Surface Pro running Windows 11 Pro, the same as the laptop. The client config files are exactly the same for the 2 computers.
The tablet is a Microsoft Surface Pro running Windows 11 Pro, the same as the laptop.
Ok. Then the same config should work.
Did you remember to rename the VPN interface to NETGEAR_VPN ?
Yes the VPN interface name was changed. As noted in my original post, the surface pro tablet connects fine when the tablet is connected by a hard wired Ethernet link but has a recursive routing error when connected by Wi-fi.
I have tracked the problem down to the Metric assigned to the network route for the two 0.0.0.0 "routes of last resort". For some reason, on the Surface Pro tablet, the route that goes to the interface IP assigned to the tablet on the server network is being assigned a metric number higher than the route that goes to the interface IP assigned to the tablet on the client network. If, after connecting, I manually assign a lower metric number to the server network route, the recursive addressing error goes away. I would like to find some way to fix this in the client OpenVPN config file that works regardless of what network the client is connected to. I have tried some route-metric commands in the config file but it has not made any difference to the routing table.
