What are the intended VPN uses for Nighthawk MR60

[Alberrow]

Can someone explain the intended use cases of the VPN software on the MR60? It's advertised as allowing a remote computer to connect to a home network and Internet proxy. I've followed all of the instructions and bounced between Netgear's minimalist documentation, OpenVPN's excessive documentation, and other Internet tutorials of varying levels of usability, correctness and completeness. This has been my experience so far using it, when I've been able to connect:

In TUN mode, the remote computer can connect to the VPN (Nighthawk MR60) and get an IP address. However, the subnet is 192.168.254.0/24, which prevents me from connecting to computers on the default 192.168.1.0/24 local network subnet. I even changed my remote network subnet to guarantee there wouldn't be no subnet collisions. Am I correct in concluding that TUN mode is designed exclusively for Internet connection sharing and not local browsing?

In TAP mode, I can connect to the VPN, but no IP address gets assigned. I assume that I have to fiddle with Ethernet bridging on the client end to hook into the 192.168.1.0/24 subnet? I assume, once I'm able to figure out how to configure this with OpenVPN documentation, that I'll be able to connect to local network computers through the VPN. Is the only way to connect to computers on the local network using TAP mode?

I don't suspect that there are any firewall issues, as I'm able to connect and the MR60 serves as the Internet-facing gateway for the local network (the modem to which it's connected acts strictly as a modem, not gateway)

For greater certainty, I assume that IPv6 is unsupported in VPN connections, as the MR60 seems to refuse all IPv6 connection attempts but accepts IPv4.

[tramperB · Accepted solution]

Am I correct in concluding that TUN mode is designed exclusively for Internet connection sharing and not local browsing?

To answer directly, no.  TUN mode establishes a connection to the LAN as though your remote device is part of your LAN.  For example, I have Home Assistant running in a docker container in my LAN - no WAN connections (out or in).  When remote, I can connect to my LAN with the OpenVPN client and then access all the HA data as though I was at home.

One 'bug' I've noticed is the internet browsing setting (in the router, at the bottom of the VPN page).  "Clients will use this connection to access"

* all sites on the Internet & Home network

* home network only

* auto

The setting seems to be ignored sometimes.  The 1st value seems to work most of the time.

[Alberrow]

I'll ask a simpler question, then: is there any way to get the server-side (AKA Nighthawk MR60) configuration file so that way I can figure out what compatible client-side settings I can use from the general OpenVPN software?

[tramperB]

Hi,

OpenVPN (in the router) allows, as you say, a remote computer to connect to the LAN.  However, the router doesn't assign an IP in your LAN.  It assigns an IP in a different subnet and then routes between the two subnets.  Use TUN mode.

It works well (I'm using both win & android clients).  Here's (part of) my client file -  which the router will create for you.

client
dev tap
proto udp
dev-node NETGEAR-VPN
remote x.x.x.x  port#
resolv-retry infinite
redirect-gateway
nobind
persist-key
persist-tun
cipher AES-128-CBC
comp-lzo
verb 5

....certificates & key....

[tramperB · Accepted solution]

Am I correct in concluding that TUN mode is designed exclusively for Internet connection sharing and not local browsing?

To answer directly, no.  TUN mode establishes a connection to the LAN as though your remote device is part of your LAN.  For example, I have Home Assistant running in a docker container in my LAN - no WAN connections (out or in).  When remote, I can connect to my LAN with the OpenVPN client and then access all the HA data as though I was at home.

One 'bug' I've noticed is the internet browsing setting (in the router, at the bottom of the VPN page).  "Clients will use this connection to access"

* all sites on the Internet & Home network

* home network only

* auto

The setting seems to be ignored sometimes.  The 1st value seems to work most of the time.

[Alberrow]

Thank you for confirming. Curiously, it worked this time whereas it hadn't worked before. Perhaps it previously failed on IPv6 and/or there was an IPv4 subnet collision. I'll try seeing if I can fiddle with the IPv6 firewall settings or if it's an oversight on Netgear's part.

I'm confused by what you said here:

---

@tramperB wrote:

Use TUN mode.

Yet the (working) configuration clearly says dev tap. Does your configuration change that line to TUN and still have it work?

[tramperB]

My mistake - you are correct - it should be tun

My 'in-use' client files are 'dev tun' - I picked the wrong backup to copy !

Actual client file is :

client

dev tun
proto udp
remote x.x.x.x port#
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-128-CBC
comp-lzo
verb 5

....cert stuff ....

tun mode establishes a layer 3 tunnel between the client & the server's LAN.

tap mode establishes a layer 2 ethernet bridge - not what's required here.

Anyway, glad it's working for you.

[Alberrow]

Thank you for confirming. I'm a bit confused: I got TUN working with the configuration file that you provided. However, I must use the OpenVPN TAP-Windows6 network interface and not the OpenVPN Wintun interface. I mean, it works, so no big deal, but I thought TAP is TAP and TUN is TUN, so it makes as much sense to me as trying to establish a PPPOE connection over a WiFi network interface.

I also lied a bit in my initial report. The main issue I was having was that I couldn't connect to OpenVPN in Linux. I discovered that there's a bug "undocumented feature" in the Linux openvpn client where it doesn't run DHCP properly (if at all), and therefore doesn't get an automatic IP address or routing information. For TAP connections, the workaround is to run dhclient tap0 (or whatever the TAP device is) after the VPN goes up. But this also overwrites /etc/resolv.conf, meaning that all DNS requests will go through the VPN.

I reckon that TUN will take more fiddling because openvpn gets an address lease, but on the wrong subnet that precludes network browsing.

[tramperB]

I reckon that TUN will take more fiddling because openvpn gets an address lease, but on the wrong subnet that precludes network browsing.

Can't help you with linux but be aware that the vpn client subnet is different to the LAN subnet; eg my LAN is 192.168.1.x & a VPN client is 192.168.254.2

The router establishes a route between the two subnets (ie between 192.168.1.x & 192.168.254.x)

[Alberrow]

---

@tramperB wrote:

the vpn client subnet is different to the LAN subnet; eg my LAN is 192.168.1.x & a VPN client is 192.168.254.2

The router establishes a route between the two subnets (ie between 192.168.1.x & 192.168.254.x)

---

Sorry, I'm a bit confused, but the answer might help me straighten out the TUN issue. By "LAN subnet," you mean the LAN subnet on the server side and not the client side, correct? For further certainty, I've tweaked my client-side LAN subnet to prevent subnet overlaps.

I can confirm that my Linux client gets a 192.168.254.x assignment from the VPN. That's a problem because when I want to access LAN machines on the server side, including the Nighthawk itself, the Nighthawk rejects all 192.168.254.x or 192.168.1.x destination addresses. This includes the reported 192.168.254.1 gateway, which ought to connect to the Nighthawk, no? My Nighthawk definitely does not route between the 254 and 1 subnets.

Given that the Nighthawk definitely refuses VPN connections over IPv6, it seems that the Nighthawk is fussy over which destination IPs it'll answer to. For absolute certainty, when I can get a 192.168.1.x subnet assignment over TAP (by manually running dhclient tap0 after VPN connection), I can connect to 192.168.1.1 (the Nighthawk).

From my elementary understanding of how server's push directive works, Nighthawk offers a number of possible subnets to the connecting client during negotiation and the client has some algorithm to pick one. I guess if I can figure out how to configure the .ovpn file to force it to use the 192.168.1.0/24 subnet that I'll have it "working out of the box" without having to run dhclient.

I hope that makes some sense.

[Alberrow]

Further update: given the decentralised and often fragmented implementation of Linux, openvpn requires the user to manage their own DNS and IP address assignments after openvpn establishes the connection.

A manual run of dhclient is one way of doing it. A better way is adding up & down commands to call resolvconf or resolvectl directly to the .ovpn configuration file (depending on which you have installed).

Accordingly, the basic TUN configuration file to run in Linux looks something like this:

client
dev tun
proto udp
remote vpn-domain.com 12973
resolv-retry infinite
redirect-gateway
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC
comp-lzo
verb 5
; Here ends the default configuration settings from Netgear. Required Linux additions below:
; To allow up and down commands to run:
script-security 2
; using the systemd-resolved configuration:
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
; To force the down command to run before bringing the tun interface down
down-pre

I'm still figuring out how to get TAP working because it requires additional routing instructions that openvpn won't configure automatically. The Holy Grail is to get NetworkManagler, erm NetworkManager working, which presents unique challenges because it doesn't allow up/down commands in VPN configurations. For some people, NetworkManager appears appears to run DHCP and DNS configuration automatically and things just work. Netgear customers don't appear so lucky. I suspect because we're shut out of editing the server-side configuration and therefore have to hack around the settings.