Client Inbound Connection Refused

[mafiaboy01]

I'm trying to setup a VPN connection between two Asus routers using OVPN for management purposes.

Background:

I have an Asus ac86 at my place currently running an OPVN server. This VPN server has my remote backup server connecting to it via a TAP connection and I'm able to access this backup server via SSH etc without any issues.
I'm setting up an Asus ax68 at another location. Normally I would have run a VPN server on this router and connected via my computer when needed. But the ISP there uses GCNAT so there would be no way for me to access this server.


Setup:

So my plan was to configure the ax68 at the remote location as a VPN client to my existing OVPN server on my local ac86. This way the remote router would always stay connected and I would be able to administer it as needed remotely.


Problem:

I can establish the VPN connection without issues, but I can't seem to be able to access the client router. I seem to be able to ping the IP that it's giving on my local network but I just get connection refused if I try to SSH or access via the webpage. I've allowed inbound firewall for the client but it doesn't seem to help. I think I'm missing some sort of a routing rule on the client side to route from the VPN IP to the router but not sure how exactly to configure that.

 

[eibgrad]

It's NOT clear to me if the OpenVPN connection between the routers is configured as bridged (TAP), or routed (TUN) and your reference to TAP was to a secondary connection. Your description was a bit ambiguous in this regard.

In a *routed* site-to-site configuration (which means you want to initiate connections from the server side to the client side), you also have to configure the Manage Client-Specific Options section on the server. You use it to inform the OpenVPN server of what IP network(s) are accessible from that specific OpenVPN client. You uniquely identify a given OpenVPN client based on its CN (Common Name).

 

[mafiaboy01]

Sorry about the confusion. I currently have one TAP server setup with both the router and the other remote backup computer connecting to it. Note that these are on different remote networks.

Currently I'm able to SSH into the remote backup computer on my network using its IP on my local network. I was hoping to be able to do the same with the remote router. I don't wan't to be able to access anything beyond the remote routers SSH/Web interface and ideally I don't want anything on the remote network accessing my network aside from the router itself.

[Local PC] -> [Local Router] -> [Remote Router]

 

[mafiaboy01]

So I've noticed something interesting. I think that my VPN connection is working however the traffic from Server -> Client is seen as WAN traffic to the remote router. If I enable SSH via WAN I'm able to SSH into the remote router.

This isn't really ideal though and I'd like to have this traffic routed as LAN traffic to avoid having to open SSH and Web Access to WAN traffic.

 

[eibgrad]

Sorry about the confusion. I currently have one TAP server setup with both the router and the other remote backup computer connecting to it. Note that these are on different remote networks.

Maybe it's just me, but I'm still having a problem w/ your description. Might be time for a diagram.

You use a bridged (TAP) OpenVPN connection when both sides of the tunnel are configured w/ the *same* IP network (e.g., 192.168.1.0/24). You use a routed (TUN) OpenVPN connection when each side of the tunnel is configured w/ a *different* IP network (e.g., 192.168.1.0/24 and 192.168.2.0/24). So the above statement is confusing.

Things like "both the router" (which router?) and "remote backup computer" and "different remote networks" are too vague. BE SPECIFIC! There's just too much ambiguity in your description. Tell me which router when you reference a router. Tell me the IP addresses. Show me the linkage and data paths. Show me the OpenVPN configuration. Etc.

 

[eibgrad]

So I've noticed something interesting. I think that my VPN connection is working however the traffic from Server -> Client is seen as WAN traffic to the remote router. If I enable SSH via WAN I'm able to SSH into the remote router.

This isn't really ideal though and I'd like to have this traffic routed as LAN traffic to avoid having to open SSH and Web Access to WAN traffic.

When I hear that kind of problem, the first thing that tells me is the other side of the tunnel doesn't know to route traffic back over the tunnel. That's why I indicated you need to use Manage Client-Specific Options to make the routing work. But then you seemed to ignore that and insisted this is a TAP (bridged) connection, so those settings would be irrelevant. Then again, you mention having two different networks.

Again, I'm confused.

 

[mafiaboy01]

Hopefully the diagram will help a bit. It's possible that my current configuration isn't optimal.

There are three separate networks all separated by the internet. Currently the Ubuntu Server on Remote Network 1 is connected to the OVPN server running on my AC86 using TAP and is given IP 192.168.2.252. It is able to see the devices on the Local Network and I'm able to access the Ubuntu Server from My Computer using the 192.168.2.252 address. This may not be the optimal configuration but so far it's been working for my intended purpose.

Now I'm trying to introduce the AX68 from Remote Network 2 so that I can access its Web portal and SSH. I've currently configured it similarly to the Ubuntu Server on Remote Network 1 and the AX68 is given IP 192.168.2.253 on the Local Network. I'm able to Ping 192.168.2.253 from My Computer but get a connection refused when accessing over SSH or HTTP.

Note: I don't want to access any other devices from Remote Network 1 or Remote Network 2 aside from the OVPN client devices (AX68 and Ubuntu Server) that are connecting to OVPN server on my AC86. I also don't want any bridging between Remote Network 1 and Remote Network 2. I may be wrong but I believe in this configuration since I'm not wanting to bridge two networks the Client-Specific Options aren't required. The AX68 is a router but in this configuration I'm looking at it as just a singular client device.

I believe part of my issue is when my HTTP or SSH request is sent from My Computer to the AX68 using IP 192.168.2.253 the AX86 routes this to its WAN interface which has HTTP and SSH connections disabled giving me the connection refused error.

Client Config

# Config generated by Asuswrt-Merlin 386.5, requires OpenVPN 2.4.0 or newer.

client
dev tap
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.
;dev-node MyTap
proto tcp-client
remote
resolv-retry infinite
nobind
float
ncp-ciphers AES-128-GCM
auth SHA384
compress lz4
keepalive 15 60
auth-user-pass
remote-cert-tls server

Server Config

 

[eibgrad]

I believe the problem here is due to the fact that the two OpenVPN clients are configured differently. In the case of the Ubuntu server, I assume the OpenVPN client's network interface is NOT bridged to the private network. It just stands alone as another network interface in addition to 192.168.1.x. But in the case of the AX68 client, that router is going to *bridge* the OpenVPN client's network interface to the private network (br0). As a result, the 192.168.2.x network is effectively subsumed by the private network. And that's probably causing issues w/ what's addressable.

Based on everything I've heard you describe in this config, this should normally be using a routed (TUN) tunnel, NOT a bridged (TAP) tunnel. Bridged tunnels are only intended for support of the *same* IP network on both sides. That's why the AX68 router will automatically assign the OpenVPN client to the private network (br0). In the case of the Ubuntu server, you would normally be expected to do the same, but you've simply chosen NOT to. And so the connection to the Ubuntu server *effectively* ends up being routable to the other network on that same side (192.168.1.x). But again, that's NOT what's happening on the AX68. And why I believe that's the cause of the problem.

So unless you can give me a better rationale for why you're using a bridged (TAP) tunnel, I believe you should change it to a routed (TUN) tunnel. And now you need to configure Manage Client-Specific Options to make 192.168.50.x and 192.168.1.x known to the server side of the tunnel.

 

[mafiaboy01]

Okay so I setup a second OVPN server on my AC86 using TUN and connected the AX68 as a client. It gets assigned IP 10.16.0.2 which I'm able to ping from My Computer but still get a connection refused error unless I enable SSH from WAN on the AX68.

 

[eibgrad]

I assume you're trying to ssh to the local IP of the ssh server, NOT 10.6.0.2 (it's not clear to me if the ssh server would be listening on the VPN's IP network). And you've configured Manage Client-Specific Options. And have Inbound Firewall on the OpenVPN client set to Allow.

Did you try including the verbose option (-v or -vv) to see why it might be refusing the connection?

ssh -v <user>@192.168.50.1

 

[mafiaboy01]

Okay I think I've got it! I've configured the Client-Specific Options as you suggested. I'm able to access the ax68 on 192.168.50.1 now form the Local Network. I also disabled "Create NAT on tunnel" on the client(ax68) side so none of the systems on Remote Network 2 can access the Local Network but I can still access the ax68.

I'll look into migrating the TAP client over to the TUN server as I think that may be a more appropriate solution.

Thanks again for you patience and help!

 

[eibgrad]

I also disabled "Create NAT on tunnel" on the client(ax68) side so none of the systems on Remote Network 2 can access the Local Network but I can still access the ax68.

In a site-to-site configuration (which this is), you should NOT be using NAT at all. Thanks to Manage Client-Specific Options, each side now has sufficient routing information to reach the other, without the need for NAT. A device behind the OpenVPN client could simply guess (i.e., use brute force) to see if some other network might be reachable besides the one on which it resides. So NAT is neither required, nor does it offer protection! If you want to limit access by anything on network #2 to the server and beyond, you need to create firewall rules on the OpenVPN client or server to prevent it (preferably the latter is you don't trust the OpenVPN client either).

 

[eibgrad]

Another thing to keep in mind as well.

When you configure multiple OpenVPN clients using Manage Client-Specific Options, there's a problem in having all the OpenVPN clients share the same client cert and Common Name (client); you can't distinguish one from the other when they connect!

The simplest solution is to add the following directive to the custom config field of the OpenVPN server.

username-as-common-name

Now create different username/passwords for each OpenVPN client, and use the username instead of the Common Name to disambiguate the OpenVPN clients.

The other option would be to generate all your own certs and keys and make sure each OpenVPN client has its own client cert w/ a unique Common Name. But that's a lot of hassle for most ppl. So the username-as-common-name trick simplifies matters considerably.