NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Cannot connect Windows OpenVPN client to RBR860
I recently replaced my old RBR20 router and RBS20 satellites with 860 models. Everything is working well, with one exception. I cannot remote into my VPN using a Windows 10 laptop with OpenVPN. Thi...
This situation is a real puzzle. I am guessing that the 860 router created new VPN files for the various platforms (Windows, smartphone, etc.)
When I search, the advice about 'tap' for Windows is what you already discovered. OpenVPN v3 no longer supports tap connections, and the advice is to use v2.
Could you please share what sort of application requires a tap connection?
It appears that the VPN connection was using tap because the IP address is in the primary IP subnet. When I use OpenVPN with tun connections, they appear in 192.168.2.x rather than 192.168.1.x
In response to your question re: TAP: I need to navigate and connect to any system on my network (using Remote Desktop Connection) to log into them and use them virtually. In order to browse and navigate the network, and access file shares, two options are available: TAP (for bridging) or routing. The latter is more complicated and requires more networking skills than I currently possess. My network hosts a Windows Domain, with internal DNS and security.
(Sorry to take so long to respond. "Life" sort of gets in the way.) This has been a challenge.
Not having an 860, I set up OpenVPN on an RBR750 running the current firmware v7.2.6.21. This 750 is connected to my Orbi LAN at 192.168.1.71, so I used that Static IP address rather than create a DDNS entry. Because the 750 WAN side is a 192.168.1.x address, the 750 creates a LAN subnet of 10.0.0.x. The Windows ovpn file created on the 750 is clearly set up for a tap connection:
client
dev tap
proto udp
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
dev-node NETGEAR-VPN
remote 192.168.1.71 12974
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca750.crt
cert client750.crt
key client750.key
cipher AES-128-CBC
comp-lzoverb 0
The Windows configuration files were moved to a Windows 11 PC on the primary Orbi LAN, where I loaded OpenVPN GUI version 2.6.8 (Nov 15, 2023). I did a "Connect", which threw all sorts of complaints in the OpenVPN log:
2023-12-18 21:47:00 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-12-18 21:47:00 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2023-12-18 21:47:01 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2023-12-18 21:47:02 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
2023-12-18 21:47:02 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.0My guess is that Netgear's implementation of OpenVPN is a bit "old" and no longer meets OpenVPN's expectations. (sigh). I then opened a web browser to 10.0.0.1 (the LAN side of the RBR750). Sure enough, the 750 Orbi web interface came up. Found this in the 750 log:
[Admin login] from source 10.0.0.5, Monday, Dec 18,2023 21:47:27
[DHCP IP: (10.0.0.5)] to MAC address 00:FF:B4:05:4A:0E, Monday, Dec 18,2023 21:47:03
[OpenVPN, connection successfully] from remote IP address:192.168.1.2 Monday, Dec 18,2023 21:47:02This confirms that my computer on the host Orbi LAN (192.168.1.2) was successful in opening a VPN connection to the 750 router and then connecting to the 750 web admin page. It appears to be a tap connection because the VPN assigned IP address is in the 750 LAN (10.0.0.x) If it had been a tun connection, the assigned IP address would not have been in the 750 LAN space. So, the ovpn config file specifies tap and the assigned IP indicates tap.
At this point, I am a bit "stuck". It is not clear (to me) how I can further demonstrate the tap-ness of the VPN connection. When I open a command window on my PC, I remain clearly in the 192.168.1.x IP LAN, so trying to ping a device on the 750 LAN fails.
Here's a screen shot showing a couple of devices attached to the 750 LAN (a PC and a phone) and the computer that has VPN'd into the 750:
Had to put this issue on the back burner until after the holidays. Will take it back up after the 1st. I'll keep you posted on my progress, or lack thereof. My wife's son is a certified Cisco network engineer. We'll be seeing he and his family on Christmas, and I plan to solicit his help diagnosing this.