Home / server / Questions / 238932
Accepted
BCS
Asked: 2011-02-23 15:51:03 +0800 CST

Can OpenVPN be set up so the server doesn't have interface that is part of the VPN?

  • 772

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.

vpn

3 Answers

  1. 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.

    • 1

  2. 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.

    • 1
  3. Best Answer

    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.

    • 0