RT-AC51U connected via OpenVPN - how to access its config page

[BosseSwede]

As discussed in another thread here I have configured an ASUS RT-AC51U to connect back home to my OpenVPN server to allow streaming geo-blocked videos from the remote location where it is connected.
I have provided my brother-in-law with this and he has started it up abroad and it works very well.

Now I have a question concerning the access to the config website on the router on address 192.168.213.1:
I have tried from the VPN server to connect to the config interface on this router by using both the remote IP address 192.168.213.1 and the VPN tunnel address of the router 10.8.0.133, but both fail to connect.

I have set up the VPN for this client to route backwards from the server LAN to the client LAN and I have also set up the route on my home LAN router to route the remote addresses through the OpenVPN server.
I have another site where this works fine but it uses an RT-AC86U router like my home LAN does.

So when I ping the remote router on the RT-AC51U site from the vpn server I get this:

$ ping 192.168.213.1
PING 192.168.213.1 (192.168.213.1) 56(84) bytes of data.
From 192.168.119.1 icmp_seq=2 Redirect Host(New nexthop: 216.119.168.192)
From 192.168.119.1 icmp_seq=3 Redirect Host(New nexthop: 216.119.168.192)
...

And to the working remote site:

$ ping 192.168.117.1
PING 192.168.117.1 (192.168.117.1) 56(84) bytes of data.
64 bytes from 192.168.117.1: icmp_seq=1 ttl=64 time=3.85 ms
64 bytes from 192.168.117.1: icmp_seq=2 ttl=64 time=4.41 ms
64 bytes from 192.168.117.1: icmp_seq=3 ttl=64 time=4.29 ms
...

Why the "Redirect Host" messages for the RT-AC51U site?

 

[eibgrad]

There really isn't enough here to explain the behavior. I don't even know what 216.119.168.192 is.

I assume what you've done here is configured multiple OpenVPN clients, each in a site-to-site configuration (i.e., connections can be initiated from client to server, or vice-versa, server to client) to access each other's LANs. And that's normally done by configureing Manage Client-Specific Options on the OpenVPN server. But again, w/o any details AT ALL, I have no clue if all that was done properly. And if NOT, how it might be contributing to those redirect messages.

In short, unless someone just happens to make a good guess, you're going to need to dump a LOT more information about this configuration, including dumps of the routing tables on the various clients and server.

 

[BosseSwede]

There really isn't enough here to explain the behavior. I don't even know what 216.119.168.192 is.

I think I know what this is even though it looks kinda strange:
216.119.168.192 == 192.168.119.216 but listed backwards...

An that is the local IP address on my home LAN for the Ubuntu 20.04.4 server running my OpenVPN server service.

The home LAN router is set up to route packets to my remote LAN by sending calls from clients on towards the OpenVPN server, which then knows to send them via the open VPN tunnel towards the remote LAN.
I have entered the same kind of route as for my existing LAN-LAN connection also for the new router, which connects to my home OpenVPN server.
Their LAN addresses differ so the calls should be sent out through the correct tunnel. But only one such route works, not the new one.

I assume what you've done here is configured multiple OpenVPN clients, each in a site-to-site configuration (i.e., connections can be initiated from client to server, or vice-versa, server to client) to access each other's LANs.

I have two OpenVPN clients configured for auto-connecting ASUS routers. One works fine and the other is the new one (using an older and simpler ASUS router).
The VPN connection from the new router works perfectly too so the clients on that remote LAN will be relocated to Sweden when they access the Internet.

They are not supposed to be connected bidirectionally to my home LAN though, I just want my side to be able to access the remote site's router by its 192.168.213.1 IP address, since that is the only address it listens to for configuration.

 

[eibgrad]

They are not supposed to be connected bidirectionally to my home LAN though, I just want my side to be able to access the remote site's router by its 192.168.213.1 IP address, since that is the only address it listens to for configuration.

But as soon as you need to access the LAN side of the client (192.168.213.1), you have, by definition, created a need for site-to-site, even if the router is the only thing you intend to access! IOW, there's no such thing as having access to 192.168.213.1 and NO site-to-site. Access to 192.168.213.1 *is* site-to-site.

 

[BosseSwede]

I have examined the two cases more carefully now and it turns out that they work a bit differently...

1) The existing (and working) LAN-LAN integration
This is set up with the remote router's config connecting to my "local only" OpenVPN server instance. This is set up to only route server LAN calls through the tunnel while all other client Internet traffic is is using the client side default gateway.
I.e. it is set up to only access server side local assets via VPN. Everything else directly. I think it is called "split tunnel".

2) The new router used for geo-location to Sweden
This is configured to use my other OpenVPN server instance, which is a full redirect of everything through the tunnel basically placing the client side in Sweden so geo-locked content can be streamed from wherever the new router is connected.
So currently this allows the remote side access to my local LAN thanks to these entries in the server's conf file:

push "route 192.168.119.0 255.255.255.0" #Access to server side LAN devices
push "redirect-gateway def1 bypass-dhcp" #Access to Internet via server's gateway

But this instance is not set up for LAN-LAN integration so remote devices are not accessible from the server side LAN, only the other way around.

So I have to figure out how to modify the config for the new router such that the needed configurations are copied over from the local-only server instance to the full-access server instance without breaking it.
And without disturbing other clients, which means that the changes have to be done via client specific ccd directory entries.

The safest bet is probably to create a 3rd server instance for remote connections to reach Internet via VPN but not allow local access for these clients, while still allowing my own server side clients access to the remote LAN devices.
This would then not disturb any working functionality.

A lot more to go over, will take a while...

 

[eibgrad]

As I said, you configure the Manage Client-Specific Options section to configure site-to-site. You do NOT manually push the server side LAN (192.168.119.0/24) to the OpenVPN client. Using Manage Client-Specific Options takes care of that for you, including adding the necessary iroute directive and CCD directory. You're just making things more difficult for yourself if attempt to do all this manually.

 

[BosseSwede]

Back again...
I do not understand what you are hinting at regarding "you configure the Manage Client-Specific Options section to configure site-to-site"....
And what does this mean: " Using Manage Client-Specific Options " ??? Is it some GUI "helper"?

My OpenVPN server is running on an Ubuntu 20.04 LTS server with no GUI whatsoever. Everything is done via terminal text access on this server.
And configurations are stored in config text files in the proper locations.

What I am trying to accomplish is connecting to the router config from my side when it is itself connected home by VPN. And that ASUS config is of course a GUI webpage...

 

[eibgrad]

Unless otherwise stated, I have to assume the OpenVPN server is running on the router. My description for configuring the OpenVPN server was based on that assumption.

From the server's perspective, a site-to-site configuration has specific requirements that include telling the server the IP network(s) that lie behind the OpenVPN client. You do that using a CCD directory that contains a file by the CN (Common Name) on the client cert. That file must contain an iroute directive specifying the IP network(s) that lie behind that specific OpenVPN client. And you need route directives for those IP networks in the OpenVPN server config as well. All those fine details are discussed in the following document.

https://community.openvpn.net/openvpn/wiki/RoutedLans

When using an ASUS router for the OpenVPN server, all those gory details are hidden from you by use of the Manage Client-Specific Options section. But if you're creating an OpenVPN server on some arbitrary platform (e.g., Ubuntu), YOU are responsible for making those changes.

Did you do that? If you don't, there's simply no way to address the private network behind the OpenVPN client (e.g., 192.168.213.1). IOW, server->client access is NOT automatic just because you've successfully established a connection and access from client to server works.

All that said, there is *one* exception that does NOT require those changes. If you're only attempting to access the device hosting the OpenVPN client from the server by the client's assigned IP on the tunnel (e.g., 10.8.0.133), it should work, *provided* the service you're accessing is bound to the tunnel. Unfortunately, for security reasons, the GUI only listens on the LAN network interface! You would have to add a firewall rule to DNAT (i.e., redirect) any such request from the client's assigned IP on the tunnel to the LAN network interface (similar to what the router does when you enable remote access to the GUI from the WAN). You are effectively port forwarding over the tunnel.

If you only need remote access to the router's GUI, perhaps this is the better approach. But if you expect to have access to the rest of the LAN, then you need a proper/traditional site-to-site config.

I know this is all very complicated, but that's just the way it is. The combination of OpenVPN having all these site-to-site requirements, plus the router only binding the GUI to the LAN, just complicates matters.

 

[BosseSwede]

Unless otherwise stated, I have to assume the OpenVPN server is running on the router. My description for configuring the OpenVPN server was based on that assumption.

But it is not...
The home router itself is an ASUS RT-AC86U but the OpenVPN server is an Ubuntu 20.04.4 LTS *server* (as I have written above).
This server is pointed to by route entries on the ASUS router for the remote networks I need to have connected LAN-to-LAN. This works just fine.

I have already set up LAN-to-LAN connectivity for my summer home LAN and my main home LAN so they are tied together and any client on any of the LAN sections can communicate with any LAN client irrespective of where it is connected.
And this includes accessing the router config pages on both LAN:s from anywhere on any of these LAN:s. Works just fine.

This thread is about accessing another remote router which also connects to the home LAN OpenVPN server (on Ubuntu)...
I need to be able to reach it for maintenance but did not add the required functionality before deployment.
So now I'm looking for an alternate way to reach it using functionality in OpenVPN itself maybe.
But if the remote ASUS router itself is only listening to the main local LAN for config access then it will be a problem, I guess...