OpenVPN not working with RT-AC3200

[IT@K]

I am trying to set up OpenVPN on an RT-AC3200 running Asuswrt-Merlin firmware 384.5 and in router mode.

The VPN server (OpenVPN Server 1 configured on the Asus) is on and marked as running while the OpenVPN client (running on Windows 8.1 Pro and connected to an iPhone hotspot for testing) shows as being Connected. The client log is repeating this:

Mon Jul 23 14:19:59 2018 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.


Mon Jul 23 14:19:59 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]24.177.198.247:1194


Mon Jul 23 14:19:59 2018 UDP link local: (not bound)


Mon Jul 23 14:19:59 2018 UDP link remote: [AF_INET]24.177.198.247:1194


Mon Jul 23 14:20:59 2018 [UNDEF] Inactivity timeout (--ping-restart), restarting


Mon Jul 23 14:20:59 2018 SIGUSR1[soft,ping-restart] received, process restarting​

The server is showing:

The wireless router currently uses a private WAN IP address (192.168.x.x, 10.x.x.x or 172.16.x.x). Please refer to the FAQ and set up the port forwarding.​

The RT-AC3200 is sitting behind a HITRON cable modem/router with a dynamic IP provided by our ISP. Does it matter that we're not using the router on the modem?

Possibly related is the yellow exclamation point by the DDNS label on the Network Map page. When I click it, I get an empty pop-up.

On the DDNS tab of the WAN page, I see this:

The wireless router currently uses a private WAN IP address.

This router may be in the multiple-NAT environment and DDNS service cannot work in this environment.​

Which looks related.

I was not getting this error when setting the Asus up initially, probably due to the previous modem being without router capability.

As an aside, I'm getting "Invalid IP Address!" when I try changing the DDNS Host name, though the displayed name is changed after I close the error dialog.

I tried enabling port forwarding on the WAN page, but it won't let me select Open VPN from the Famous Server List.

Other things:

• icanhzip.com is showing a different address (24.177.198.92) than on the Network Map (192.168.44.2).

Is there something that needs to be changed on the modem/router (e.g. convert it to using a static IP), or can this all be done by changing the Asus' settings?

 

[ColinTaylor]

You have double NAT. You need to put the HITRON into bridge mode if that's possible.

 

[IT@K]

You have double NAT. You need to put the HITRON into bridge mode if that's possible.

That's what I was afraid of. It took Charter/Spectrum 2 weeks to actually get a line in that worked, replaced the modem twice, etc I'll put in a service request with them to see what they'll do.

Am I going to need it to be bridge mode regardless of the router on my side?

 

[ColinTaylor]

Am I going to need it to be bridge mode regardless of the router on my side?

You could get it to work but you'd have to setup port forwarding on the HITRON, not the Asus.

 

[IT@K]

Charter/Spectrum did some reconfiguring of the HITRON (3 times - one of which knocked out our main corporate network for a few minutes) so now it is in bridge mode.

An OpenVPN client can now connect and allows a successful ping of the router's IP address. However, there is no name resolution and I cannot ping other computers on the network (IP or otherwise) nor see them in Windows File Explorer.

On the VPN Status tab I see Real Address (66.xxx.xxx.xxx) and Virtual Address (10.8.0.x), so I'm assuming that I need to hard-code a route mapping somewhere (VPN Server Advanced Settings ?). Is there a handy decoder ring for what to put there (as I'm not understanding the few examples I've been finding... which I blame on lack of sleep rather than basic ignorance)?

 

[ColinTaylor]

Charter/Spectrum did some reconfiguring of the HITRON (3 times - one of which knocked out our main corporate network for a few minutes) so now it is in bridge mode.

I didn't realise this was for a business network. The first thing I would say is "be very very careful". The whole point about VPNs is that you are putting absolute trust in the devices that you allow to connect to your network. I have personally witnessed an organisation of 1000's of PCs brought to its knees for days because a senior manager connected his virus infected home PC to the corporate network. It cost the company 10's of thousands of pounds(£). Having, for example, your home network infected with a zero-day ransomware is very inconvenient. Having that happen to a corporate network can put you out of business. Depending on the size and type of business you might question whether or not a consumer router is an appropriate choice. Also, don't rely just on username/password authorisation, use certificates as well. OK enough lecturing.

An OpenVPN client can now connect and allows a successful ping of the router's IP address. However, there is no name resolution and I cannot ping other computers on the network (IP or otherwise) nor see them in Windows File Explorer.

On the VPN Status tab I see Real Address (66.xxx.xxx.xxx) and Virtual Address (10.8.0.x), so I'm assuming that I need to hard-code a route mapping somewhere (VPN Server Advanced Settings ?). Is there a handy decoder ring for what to put there (as I'm not understanding the few examples I've been finding... which I blame on lack of sleep rather than basic ignorance)?

There shouldn't be a need for any additional routing. The settings on the VPN client can effect what DNS server is being used. So check that the server is correct and use the fully qualified domain name in nslookup. The client is probably not configured as part of the same domain/workgroup.

Bear in mind that the VPN clients will be connecting to your network with 10.8.0.x addresses (assuming a TUN interface type). So they won't normally be able to "browse" network resources because they are not part of the broadcast domain. But they can still connect directly to them if they know the IP address or FQDN. Another point is that by default Windows Firewall will block all unsolicited connections from outside the local subnet. So for a VPN client to be able to RDP (for example) a local PC that PC's firewall will need a rule allowing access from the 10.8.0.x network. CORRECTION: Windows Firewall will allow remote RDP connections, but other protocols, like ICMP Ping are blocked. Look at the firewall rules on a case by case basis.

An alternative approach to using the TUN interface, which is a routed connection, is to use TAP. TAP is an Ethernet bridge so the VPN client is connected to the corporate LAN just like a local PC. It gets a local IP address from the corporate DHCP server and is part of the local broadcast domain. This type of connection has a lot more traffic continuously flowing over it and that is why it tends to only be used for fixed point to point connections. TUN requires a lot less bandwidth and works well from ad-hoc locations like hotels or mobile networks which is why it's the default setup.

 

[IT@K]

I didn't realise this was for a business network. The first thing I would say is "be very very careful". The whole point about VPNs is that you are putting absolute trust in the devices that you allow to connect to your network. I have personally witnessed an organisation of 1000's of PCs brought to its knees for days because a senior manager connected his virus infected home PC to the corporate network. It cost the company 10's of thousands of pounds(£). Having, for example, your home network infected with a zero-day ransomware is very inconvenient. Having that happen to a corporate network can put you out of business. Depending on the size and type of business you might question whether or not a consumer router is an appropriate choice. Also, don't rely just on username/password authorisation, use certificates as well. OK enough lecturing.

There are a few reasons for using a consumer router:

• budgetary: we're a small startup and this router was repurposed
• it will be little used: prior VPN access has been - at most - 1 time/month for the users who would have access to it. I know this is not the best reason since all it takes is one time.
• the accessing system will almost certainly be a business-issued laptop, which is running anti-virus software. Yes, I did say 'almost', but the chances of this group of users installing it on another system is practically nil.
• VPN access effectively only allows access to our fileserver, which is running anti-virus (as do any in-house systems connecting to the server over the LAN). The only other thing that could be accessed is their own laptop. Since that is almost certainly what they are accessing the VPN with in the first place, then that isn't a real possibility.

I already have a certificate installed on the VPN server. One is enough, correct?

I appreciate your pointing out things that are problematic. I do the networking, but that isn't my primary job so I could easily have not considered something.

There shouldn't be a need for any additional routing. The settings on the VPN client can effect what DNS server is being used. So check that the server is correct and use the fully qualified domain name in nslookup. The client is probably not configured as part of the same domain/workgroup.

Bear in mind that the VPN clients will be connecting to your network with 10.8.0.x addresses (assuming a TUN interface type). So they won't normally be able to "browse" network resources because they are not part of the broadcast domain. But they can still connect directly to them if they know the IP address or FQDN. Another point is that by default Windows Firewall will block all unsolicited connections from outside the local subnet. So for a VPN client to be able to RDP (for example) a local PC that PC's firewall will need a rule allowing access from the 10.8.0.x network.

An alternative approach to using the TUN interface, which is a routed connection, is to use TAP. TAP is an Ethernet bridge so the VPN client is connected to the corporate LAN just like a local PC. It gets a local IP address from the corporate DHCP server and is part of the local broadcast domain. This type of connection has a lot more traffic continuously flowing over it and that is why it tends to only be used for fixed point to point connections. TUN requires a lot less bandwidth and works well from ad-hoc locations like hotels or mobile networks which is why it's the default setup.

We do not have a domain (for various historical reasons), but the laptops likely to be VPN clients are part of the same workgroup when internally connected to the LAN.

So, the DNS settings on the client system are not provided in the .ovpn file and are instead the ones defined for the client's network driver configuration? The latter would make the most sense, but I just want to confirm what settings I need to muck with (if I need to).

The VPN server is currently using TUN. When you said that they could still connect if they know the IP address., that would be the Real Address and not the Virtual Address, correct? I am unable to connect to a known IP, though I can ping the router.

The continuous traffic (associated with TAP) would only be on the VPN connection and would not affect in-house LAN users' bandwidth dramatically, correct? Or is how much bandwidth the VPN can use a configurable setting somewhere?

TAP works a charm for Windows clients but not iPhone (which a slight inconvenience). I think browsability will be more in demand than connecting with an iPhone.

 

[ColinTaylor]

We do not have a domain (for various historical reasons), but the laptops likely to be VPN clients are part of the same workgroup when internally connected to the LAN.

I was just referring to your local LAN domain name. Set something on the router at LAN > DHCP Server > Domain Name. Leaving it blank can sometimes cause confusion. It can be almost anything, I use home.lan but you might use companyname.lan.

So, the DNS settings on the client system are not provided in the .ovpn file and are instead the ones defined for the client's network driver configuration? The latter would make the most sense, but I just want to confirm what settings I need to muck with (if I need to).

The DNS addresses are typically pushed to the client by the VPN server (see "Advertise DNS to clients"). You might also want to push your local domain name with the Custom configuration option of push "dhcp-option DOMAIN companyname.lan"

The VPN server is currently using TUN. When you said that they could still connect if they know the IP address., that would be the Real Address and not the Virtual Address, correct? I am unable to connect to a known IP, though I can ping the router.

I'd expect a VPN client to be able to ping a local PC (i.e. 192.168.1.55) but only if that PC has a Windows Firewall rule to allow it (by default it will block it because the source is 10.8.0.x). Unless you use TAP in which case it should just work.

The continuous traffic (associated with TAP) would only be on the VPN connection and would not affect in-house LAN users' bandwidth dramatically, correct? Or is how much bandwidth the VPN can use a configurable setting somewhere?

This traffic won't impact the LAN. It is just the normal traffic that is floating about your LAN. Sending that data over a VPN was more of a concern in the past when you had slow links and paid by the kilobyte.

 

[IT@K]

Thanks for answering these, I really appreciate it.