Right setup for a network of multiple machines, but two or more clients can also act as servers for redundancy

[LostPhysicist]

I have a few machines in my internal network with a VPN, and they're all `client-to-client` through the server (so they can access each other from any of them). They're all under one subnet. All good there.

The only issue is that there's only one machine being the server. If it fails, I lose access to that network.

I would like to increase redundancy in case of failure by making another one of the clients in that network also a server, but without creating a whole new subnet (hence, it should retain its ip address in the original VPN network). Having to create new subnets will just complicate the topology, and it'll have M subnets with N*M ip addresses, where N is the number of machines on that network. This doesn't scale well.

This isn't exactly a fail-over setup like described here, because that setup is based on checking availability (if I understand correctly), because I just would like to have the choice to connect to either servers, and have them both in the same subnet where they can still see each other.

Is what I'm thinking possible?

[openvpn_inc]

Hello LostPhysicist,

The problem here is that of subnet collision.

So you have an existing VPN network right now that the server and the clients are talking on. For example this could be 10.8.0.0/24 network, where the server is on 10.8.0.1 and the clients on 10.8.0.2, 10.8.0.3, 10.8.0.4, and so on. This network exists so that the VPN clients and the VPN server have a common network to communicate over. The operating system knows how to reach 10.8.0.0/24 - by talking to the tunnel network interface.

Now let's say you install an OpenVPN server next to an already running OpenVPN client in this network. The idea being that now you have another VPN server that you could connect to, to then talk to the 10.8.0.0/24 network. But you don't want a new network, but instead you want this new OpenVPN server to also use 10.8.0.0/24. Now the operating system of this computer running both an OpenVPN client and an OpenVPN server will have two tunnel interfaces that both declare that they want to operate in the 10.8.0.0/24 space. The operating system now does not know which one to send the packet to. It can only deal with having this subnet actually work on one of these interfaces.

What you could do, but would be really very ugly in my opinion, is to not have OpenVPN run any subnets on its own at all, but rely on the existing local network DHCP server. This requires putting OpenVPN into bridging mode so that VPN clients are 'plugged into' the local network on the server side. Now you're not even introducing any subnet for VPN at all, you're using what is already on the local network on the server side. Then you can run multiple such OpenVPN servers on machines connected to that same local network. Then whichever OpenVPN server you connect to in this network, the VPN client will get its IP address from the same DHCP server of that same local network.

The downside is that you're not using routing anymore, but bridging, and that means VPN clients are now a lot more tightly integrated into your network, so the clients can reach anything on your local network. And your local network can reach these VPN clients too. There is a lot less control now over what they can access, and there are other downsides as well that relate to bridging sending across all sorts of traffic and not just IP traffic, like DHCP options like changing the search domain on the client side and such.

Since the concept may be a bit difficult to grasp let me give you this;

In routing mode, OpenVPN server is like a router with a WAN port that's connected to your local network, and a bunch of LAN ports with its own DHCP-like server with a unique subnet for VPN (10.8.0.0/24). VPN clients plug into these LAN ports and get IP and routing gateway address from the OpenVPN server.

In bridging mode, OpenVPN server is reduced to acting almost like a simple network switch only that's connected to your local network. VPN clients plug into one of these switch ports and then are simply a part of your local network roughly like any other local computer would be. So then it gets its IP address from your local network DHCP. OpenVPN becomes transparant in this fashion. And as you can imagine, you can have multiple of such network switches and they all connect to the same local network, so it doesn't matter which one you connect to.

It is ugly and I cannot recommend it at all. But your train of thought goes into a direction that kind of leads here. I would never do this because bridging is difficult to configure right, some clients don't even want to do it anymore. DCO is the newer method of handling encryption in the kernel and it doesn't do bridging at the moment either. And on some clients you need to do special stuff just to get the client to be able to get an IP at all over bridging. It is still working for some very specific use cases but it is highly recommended to use routing if you can. And basically, there is almost no valid use case where you are required to use bridging these days.

Personally if I wanted redundancy, I would recommend to actually do high-availability like the failover mode you mentioned. That way if the server dies, its backup comes up and takes over the task. And since the configuration is the same, so if the VPN subnet. And if you set up static IP addresses for the VPN clientst they will always be on the same predictable IP address in the VPN network.

Kind regards,
Johan