OpenVPN / site to site with special security/routing constraints

[MarkusI]

Hi,

I am struggling a bit with the following scenario...

I have a LAN (192.168.1.x) with ASUS Merlin router and a remote LAN (192.168.10.x & 192.168.5.x) also with a ASUS Merlin router.
Due to several reasons, I cannot VPN directly to the remote LAN, but the remote LAN can VPN to me.

So, I created a OpenVPN server on my local router and a OpenVPN client on the remote router, so that the remote router connects to my local network.
That connection works, the virtual IPs are in the range of 10.2.0.x.
The remote router does NOT route internet traffic through the VPN, even though it has an internet connection.
I suppose, I could manage to give a static IP (e.g. 10.2.0.100) to the remote router when it connects via OpenVPN, in case I need a fixed gateway IP.

What I want to achieve in the end is the following:

1. every OpenVPN client which is connected to my OpenVPN server is
   • able to access the remote IPs (192.168.10.x & 192.168.5.x)
   • able to access the internet (which could also be achieved by routing all traffic through the remote router)
   • NOT able to access my LAN IPs (192.168.1.x)
2. from my LAN (192.168.1.x) I can access all remote IPs (192.168.10.x & 192.168.5.x), too

As I wrote above, I have a ASUS router with the newest Merlin firmware.
This is where I stand right now (which for me already does solve my most urgent needs, but I know, that I probably need to do it completely differently to achieve all requirements):

1. the remote router connects to my OpenVPN server
2. I have assigned additional subnets (192.168.10.x & 192.168.5.x) to that client in the OpenVPN config (!! every client currently gets these subnets, which is no issue while I only connect the remote router)
3. I have configured the clients to be able to use both, internet and LAN

(I actually do not know how to configure different clients for the same OpenVPN server in AsusWRT, only how to use the same client conf with different usernames/passwords).

With these settings, I reliably can access the remote IPs from my LAN (but also my IPs are reachable from the remote network).
I need 2. & 3. to be able to access the remote IPs.

Since I don't need access to the remote IPs permanently and allowing multiple OpenVPN clients to access the remote IPs would only be the next step, I can simply either configure the OpenVPN server to "clients can access internet only" or shut down my server altogether in order to hide my LAN when I don't need remote access myself.
But this cannot be the final solution, I guess.

I suppose, shielding all OpenVPN clients from my LAN and allowing all OpenVPN clients to access the remote IPs would be first priority (I still can connect via OpenVPN myself to access the remote IPs then, even though this would be a bit clumsy). If then there is a way to also directly access the remote IPs from my LAN, it would be the icing on the cake.

Any ideas and (optimally concrete) tips how I can achieve that in ASUSWRT Merlin?

Really, any help is very very much appreciated!

Thanks in advance
Markus

 

[elorimer]

Going through your writeup, I'm unclear on two things. 1) How is it that you have a single remote LAN with two subnets? 2) Are you looking to just join local router LAN devices to the remote router LAN devices, or are you looking to have other OpenVPN clients accessing the local router OpenVPN server and from there the two remote LANs?

Anyway, in no particular order:

1. Having the subnet of the local router be 192.168.1.xx is not optimal, because of the potential of your tunnel crossing that same address scheme (cable modems, etc). Better to move it to something like 192.168.50.xx where that is less likely. It doesn't sound like you are having an issue there.
2. On the server, while it is better practice to disambiguate different clients with separate keys (particularly in a business environment where you might fire someone and you don't want him walking off with your master key), in a home environment you can use the same keys and disambiguate with username/password combos. You do that by creating up to 32 username/password combos and in the custom configuration box entering "username-as-common-name". I don't know whether you can have multiple clients share the same username/password combo at the same time safely, but there is a configuration setting for that.
3. On the server, "internet only/LAN only/Both" operates to push the default gateway to the client (so all devices on the client LAN access the internet over the TUN), or push a route to the server's LAN (so all devices on the client LAN know a route to the server's LAN is over the TUN), or both. You can direct whether clients do that by having the client configuration use a "pull-filter ignore" setting (but then you can't actually control whether someone changes their client configuration on you.)
4. On the server, you control whether OpenVPN clients can see other clients, and access other clients' LANs, with the client-specific options on the Advanced page. (Or with the client-connect script).
5. On the client router side, you can use VPN Director to control whether individual devices on the LAN access the TUN at all, and for what.
6. You also have two servers you can configure (and maybe wireguard too).

Excepting that I don't understand question 1 above, and assuming you are looking to have multiple clients:

1. Set the server to both.
2. In the remote router client configuration, use a unique username/password combo and use a pull-filter ignore setting to ignore the default gateway change and the route. Or do it in VPN director. Now devices on the remote router never go over the TUN for the internet or the server LAN.
3. For other clients, assign unique username/password combos, pull-filter ignore commands and client specific options to configure whether those clients access the internet over the TUN, access the server LAN, the remote client LAN, or the LANs of other clients.

 

[MarkusI]

Hi @elorimer ,

thanks for your detailed feedback and information..

Regarding the multiple subnets, the situation is as follows:

Both LANs (my local one and the remote) have the ISP's cable modem (on my side it operates in 192.168.0.x and on the remote site it operates in 192.168.5.x).
The only client connected to that modem is the local ASUS router with 192.168.1.x subnet on my side and 192.168.10.x remote which handles all actual clients.

Since I want to able to access as well the ASUS router and the cable modem (which actually acts as the WAN gateway of the router), I mentioned 192.168.10.x and 192.168.5.x..

Hope that made it clearer

Thanks for all your hints regarding common-names and the pull-filter ignores.
I will have to learn how they work, but I already have a rough picture in mind...

Thanks again... I will report if I succeed

But one last question regarding "but then you can't actually control whether someone changes their client configuration on you."...
Does this mean that I cannot isolate LAN access on server side if someone decides on the client side to maliciously work around it?

I would like to make sure that OpenVPN-clients can only access internet or the remote LAN.

Thx
Markus

 

[elorimer]

I will think a bit about your subnets.

What I meant about "actually control" is this. It is one thing if you are a home user and have physical control over both routers and subnets, and effective control over family members for whom you make the magic happen. It is another thing if this is a business environment with multiple employees/locations/clients. In the first situation, inserting a line in the client configuration that makes the magic happen is just fine, I think. In a business environment, you want to assure the folks that write the checks that things are locked down, and a structure that can be defeated by someone commenting out a line in a client config file isn't acceptable. Or, if you ex made off with your keys.

But I think you need to be clear on one point. A device on your remote LAN is not a "client" in this sense. The client is the remote router that handles those devices. A client is something that connects all on its own to the Openvpn server. If that is only the router, then you only have one client, and multiple devices that connect through that client.

 

[MarkusI]

Yes, I get your point.

Ok, let me explain a bit more (even though it might sound a bit ridiculous :-D).

The remote LAN is the LAN of close friends of mine who built up a small sustainable family-run farm.
I help them since their first steps with IT stuff, e.g. website, web-shop, Wifi mesh in their different farm buildings and many other things...

Until a week ago, they had very, very, very crappy internet connection (ipv4, though) to which I was able to VPN to.
Since then, they have fiber optic internet connection with high bandwidth, but ipv6.

After hours and hours of experiments, I (currently) gave up to establish an ipv6 VPN connection to them. Ipv6 is quite new to me and although I'm pretty sure, their VPN server for assigned a public ipv6 IP, I cannot connect. Nothing gets through and I have no clue how to analyze properly (also because without VPN I am pretty lost from remote).
On top, it looks like my cable ISP at home does not provide ipv6 which leaves me in the situation that I cannot VPN to the remote LAN directly from my LAN even if I would be able to overcome the ipv6 issues on their side.

A solution discussed in forums regarding their particular ISP often is a ipv4->ipv6 tunnel. Even the ISP offers a service for that but of course not for free.

So - more or less - clever as I am ;-) I thought: ok, I cannot connect to them, but they can ipv4 connect to me... so let's turn it around.

On top, I could provide an ipv4 vpn for them when they are traveling e.g. to check the IP cams if their livestock is ok.

That is why I was talking about multiple clients.
Client 1 would be the remote router connecting to my VPN.
Additional clients (my friends when they are on the road) could connect to my ipv4 VPN and then should get tunneled to their remote LAN.

Also, I'd like to access their remote LAN directly from my LAN without dialing in to my own VPN first.

Currently I managed to exactly achieve this.
I now have multiple clients identified by different common names, assigned the two remote subnets to the remote router client and all other VPN clients and I from my LAN now can connect the remote network.

But as I wrote above: they are farmers and they are - naturally - not very attentive when it comes to network security (and I don't claim to be very well educated in that area either, but I try to compensate that with a bit of paranoia ).
They e.g. might give direct wifi access to friends and visitors (even though I created a special isolated guest network for these situations)...
And I can understand if they do so because they trust their guests.

But I don't and I don't want any remote LAN IP be able to access my private LAN IPs without my intention. Never.
If they decide to give away their wifi and get compromised (intentionally or by malware), I want to be as safe as possible.

That is why all VPN clients shall be able to communicate (as if they would VPN into their own network directly) but communication between my LAN and the remote LAN (or any other VPN client) shall only be possible if initiated from my LAN but never vice-versa.


It was simpler when they still were on ipv4 on the ISP side...
But maybe I'm overcomplicating things...

Hope that makes it a bit clearer
Markus

 

[MarkusI]

Hmm. I think I could try to isolate my LAN from incoming(!) connections from my VPN by iptables... will investigate that.

 

[MarkusI]

I found a simple solution which works for me.

When I set the OpenVPN server to "Clients can use both (LAN and internet)", I can access the remote LAN from my LAN.
Then, it is also possible to reach my LAN from the remote LAN, as well.

But if I set it to internet only, only all OpenVPN clients (of which one is the remote router) can talk to each other and access the remote LAN.
Neither I can access the remote LAN, nor can any OpenVPN client access my LAN.

I configured the OpenVPN client on the remote router to reconnect within 10 minutes if the OpenVPN connection gets lost.
I just will keep the OpenVPN server in "Internet only" mode by default, thus providing the VPN tunnel for other OpenVPN clients to the remote LAN.

In the rare cases I need to check the remote location, I will just temporarily set the mode to "Both" and restart the server, wait the remote router to reconnect, do my work and set it back to "internet only".

I'm totally fine with that.
Thanks for your support

 

[elorimer]

I don't think this is working quite like you think.

First, it may be that the farm is sending all its internet traffic through your router. That means their Asus router is encrypting all their internet traffic, sending it over the tunnel to your router (limited to your download bandwidth and the speed the farm's Asus router can handle), where it is decrypted (limited now again to your Asus router processing speed) and then out your internet connection (limited now to your upload speed). That wastes all of their fiber speed and limits your speed too. Better if none of their internet traffic goes up the tunnel to you. For that you might add the pull-filter ignore redirect-gateway command to their client config to see what happens. If it works like I think it might, that is equivalent to your router having "none" instead of "both" (which isn't a setting, actually).

Second, what is controlling whether your openvpn clients have access to the farm is (1) the firewall setting on the farm's router and devices and (2) the client <> client setting on your Asus router, and the routes specified on the Allowed Client table (which would specify both the .10.xx and .5.xx subnets with the farm's client name. I don't think the "Both" has anything to do with it--I don't think setting it and unsetting it is doing anything.

Third, what is controlling whether your LAN has access to the farm's LAN is in your server's configuration, not the Both setting.

And last, if I follow, you have the farm's ISP router doing the .5.xx subnet, and the farm's Asus router doing the .10.xx subnet. You must have the ISP router doing port forwarding to the Asus router, so traffic down the tunnel to the farm get's forwarded to the Asus router, which routes traffic to the .10.xx subnet, and then uses its own default gateway to forward traffic back (untunneled) to the ISP router and then to the .5.xx subnet.