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

I'm looking to set up a VPN (OpenVPN is my first choice but I'm not stuck with it) in such a way that the server that hosts the VPN is not visible from within the VPN. That is; any packet that a client sends via the VPN interface will get delivered to another client's VPN interface or get dropped. In the other direction, the server shouldn't have a VPN interface at all and normal network operations shouldn't be able to send packets on the network.

Can this be done?

All the docs I have found have assumed that clients will connect via DHCP (this requiring that the server connect at least to that extent) but I can't think of any reason that a VPN couldn't use static IP's or that the DHCP server couldn't be implemented inside the VPN (see edit) server without setting up a VPN interface on the server.

Edit: Based on the link on bridged mode from Phil Hollenback's answer it seems that OpenVPN does in fact have the "internal DHCP server" that I'm thinking of.

share|improve this question
Why would you want this? – Zoredache Feb 23 '11 at 7:58
@Zoredache: The requirements listed are the only things I need. Anything more (e.g. having the server in the VPN) is a potential for problems. So the first question is: Can they be avoided? and second: What potential problems will that introduce? Once I have that info, I can make the assessment of if it's worth doing. – BCS Feb 23 '11 at 17:03
I guess I am curious why you wouldn't handle this with firewall rules. – Zoredache Feb 23 '11 at 17:17
@Zoredache: Why even have an interface in the first place if the firewall will be set to block all traffic? – BCS Feb 23 '11 at 17:20
Well the reason is because adding firewall rules is a simple and well documented. What you seem to be trying to do doesn't fit well into how OpenVPN was designed to be work. Or to put it differently. KISS - keep it simple stupid. Setup OpenVPN in routed or bridged mode and just adjust your firewall rules so that VPN traffic is not permitted to be forwarded. If you really think things need to be separate why not setup a virtual machine or separate server that has not connection to your internal network. – Zoredache Feb 23 '11 at 21:19

I suspect this is possible (although pretty weird). Use the tap device so that the remote machines are bridged over the vpn instead of routed. OpenVPN lets you push scripts to the clients to execute on connection, so you can use that facility to configure networking on the client machines instead of using the server push directives to configure dhcp. Instead, directly run the appropriate ifconfig and route commands on the client to tell it to connect to the network over the vpn. That probably gets complicated as you have to deal with different network config tools on linux vs. windows, but it should be doable.

My guess however is this will only be sufficient to avoid casual inspection. It's very likely there will be information leakage that would allow a client to detect that it is connected to the network via a particular openvpn server.

Here's some info on openvpn bridging that might be useful.

share|improve this answer
I may be reading it wrong but doesn't bridging require that there be a VPN interface on the server for every connection? That's going in the opposite direction from what I'm wanting. – BCS Feb 23 '11 at 17:23
How else would you have a vpn without an interface between the openvpn server and every connection? IF you don't have an interface I don't know how you get data between the remote machine and the local network. – Phil Hollenback Feb 23 '11 at 18:03
I don't want to get data from the remote machine to the local network (in fact I want to prevent that possibility) but rather get data from one remote machine to another remote machine. (I have no problem with the clients each having an interface on their end, but if I'm reading that right, running ifconfig on the server with that setup would show an interface for each client.) – BCS Feb 23 '11 at 19:47

This isn't going to answer your OpenVPN question, but let us take a step back if you don't mind.

You want a client-only VPN, is that correct? You have clients potentially anywhere in the world and you want to connect only those clients via VPN? There are no central resources that you want the clients to connect to, just each other. Gotcha.

Have you looked at Hamachi^2? It does exactly what you're trying to achieve.

If what you're doing is non-commercial and you have 16 or fewer clients, Hamachi^2 is free. If you have commercial needs and/or or you require more than 16 clients, it's $199/year.

$199/year is probably less money than it takes than to acquire hardware for OpenVPN (if necessary), your time to configure and maintain OpenVPN and your time to support the clients/users.

Of course, if this purpose is non-commercial, greater than 16 clients, you're donating your time and hardware has already been provided, I can definitely see why Hamachi^2 isn't the solution for you.

That being the case, I'm not entirely sure why a total lockdown firewall solution on the tunnel interface of the OpenVPN isn't adequate for your needs.

share|improve this answer
Sounds ideal, except for the trust issue and that it doesn't seem to use standard clients. If I use my own server, I'm the only one to blame if things get mucked up. (That is not to say they aren't to be trusted, just that a solution that doesn't require trust would be better.) – BCS Feb 23 '11 at 23:27
up vote 0 down vote accepted

I was assuming that OpenVPN was acting as a Virtual switch and that it was just, by default, adding the server in as yet another client. A client that happens to be on the same machine but otherwise completely uninteresting. I was hoping that there was some way to tell it to just not even bother. However it seem (and please do correct me if I'm wrong) that this is not the case and there is something special about the connection that the server has into the VPN.

Edit: Well it seems I was still wrong. In the middle of a hour or so chat with someone who has worked on this stuff (as in kernel mode development etc.) I have, I think, found my misunderstanding of the way VPNs are implemented: I was assuming that the VPN endpoint was handled in a user space process that was listening to some UDP port (making the the tunneling protocol an application layer protocol), the real situation is that the tunneling protocol (at least the common ones) is a transport layer protocol, kin to TCP/UDP, and all the data processing, starting in the processing of the IP packet, the decryption of the tunneled packet and the forwarding to the kernel network stack, is in fact done inside of the kernel. Once this error on my part was pointed out, the rational for the designs that are in use becomes blindingly clear: the user space components of a VPN server are nothing more that configuration tools that manages the authentication and setting up a separate, symmetric, point-to-point link for every client that requests to connects.

OTOH this now has me wondering how VPN scale for large setups (say IBM or the like) that need to support having hundreds to thousands of simultaneousness active sessions to the same host at the same time? Do they run a normal kernel with hundreds to thousands of network interfaces (I'm hard pressed to believe that same kernel can efficiently handle both the majority case of a one, two, maybe three interfaces and thousands) or are they based on radically modified kernels, special OS, different architectures or even special hardware.

share|improve this answer

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.