Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a number of Database severs running MongoDB on Debian plus a number of Application servers also on Debian. The db servers hold replicating db clusters, so they need to talk to each other. Application servers need to talk to all db servers (for reasons of fault tolerance). The servers are potentially spread across multiple hosting centers, so we need secure channels between all servers. The number of servers is bound to grow, so we need a VPN solution that's easy to maintain and expand. This is why I feel that SSH that we use for testing might not be up to the task and OpenVPN seems the way to go.

I have ruled out TAP, since I understand that this would mean all traffic going to all the servers - perhaps this is a misunderstanding and TAP acts more like a switch?

With TUN devices I imagine that all DB servers would live in their own separate subnet, they would also need a client configured to be able to connect to each of their peers. The application servers could live in a common subnet range with a client config only.

Does this sound like a reasonable setup? Strangely, on the web I did not find anything about multi-server with OpenVPN.

Thanks for all insights and ideas!

share|improve this question
See answer below. I think you're over-complicating this. – Magellan Oct 13 '12 at 15:08
up vote 2 down vote accepted

You appear to have some assumptions that are not necessarily warranted, and you're over-complicating things.

Tap will not route all traffic through the VPN unless you configure it to do so with routing statements. This is covered in the OpenVPN documentation on their website.

If your datacenters are connecting with a VPN technology, the only reason you should need multiple VPN servers is for connectivity to each datacenter's subnet. OpenVPN is very effective at routing traffic between subnets and it's a nearly ubiquitous use case.

If you're attempting to set up a mesh VPN network with point-to-point connections between all servers, you're setting yourself up for a world of hurt in terms of management overhead.

share|improve this answer
Thank you for your answers. Currently we do not have subnets within the hosting centers, we have rented separate hosts. Thanks for confirming this would result in a mgmt nightmare with VPN. For now we have chosen to use SSH tunnels on a per service basis. This may not be ideal in the long run, but for now it does the job. Will further look into Open VPN as future option. – sebut Nov 1 '12 at 8:33
You might be better off with IPSec in this case. – Magellan Nov 1 '12 at 17:08

The tap interface is on layer 2 - it'll look like that all machines are in the same segment. The tun - on layer 3 (as you said - they will be in different subnets).

If you go with the TUN iface you don't have to install vpn client on each peer. It's sufficient to have one vpn client per site and configure routing between them. This way the VPN client will act like router. For me this is the easiest because you'll only have to add route for the new network on each machine (or setup your default gw).

share|improve this answer
Interesting that one client would act as a router, will look further into that. This would have 2 drawbacks though: 1. single point of failure, 2. two tunnels involved for most of the routes – sebut Oct 11 '12 at 16:34
Why two tunnels for most of the routes? – tsv.dimitrov Oct 12 '12 at 6:42
Good question, not sure anymore about the picture I had at this point. For now we have chosen SHH tunnels, see also my comment above. Thanks for your answer! – sebut Nov 1 '12 at 8:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.