Cannot connect Windows OpenVPN client to RBR860

[Keith_1952]

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.  This was working great for years on the old 20 system.  Even more confounding, I can remote into the VPN successfully with OpenVPN from my Android phone, but not from a Windows laptop.  The behavior I see is a perpetual "Connecting" status that never times out, but no errors or logging on either client or in the Orbi logs that offers any insight to the issue.  In Orbi, I see messages like:

[OpenVPN, connection fail] from reomote IP address:192.168.1.105

Yes, the log contains the misspelling. 

When using my phone, I see:

[OpenVPN, connection successfully] from remote IP address:107.122.246.161

I am using OpenVPN client version 2.4.12, but have tried other older versions with the same result.  I cannot use OpenVPN v3, because they dropped support for TAP, and I must have remote access to my LAN servers, which cannot be accomplished with only TUN.

My client.ovpn has:

client
dev tap
proto udp
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
dev-node NETGEAR-VPN
remote kgreer.org 12974
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC

remote-cert-tls server

key-direction 1
comp-lzo
verb 0

I've had the same experience on 2 laptops, and from 2 different wireless environments.  Any help greatly appreciated.. 

[CrimpOn]

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

[Keith_1952]

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.

[CrimpOn]

(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-lzo

verb 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.0

My 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:02

This 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:

[Keith_1952]

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.