The Setup

I've gotten OpenVPN working on our Windows XP laptops. Users are limited, so I went ahead and set OpenVPN client to run as a service, which is great anyway because that means they are on the VPN before logging in, so login scripts work, plus we can do remote support even if the user can not log in (such as connecting via VNC or resetting passwords). It is also configured to send all traffic over the tunnel, so when, for example, they browse the internet it is just like browsing from our corporate network.

The Qestion(s)

So, I'm wondering how does the OpenVPN client act when the computer is already physically on the same network as the OpenVPN server? Right now, the client is configured to connect the the public dns name which will resolve to the public ip address which will NOT get reflected back to the OpenVPN server, so it is affectively blocked from connecting to the OpenVPN server while on the network. Is that a good thing? Or will it constantly try to connect, using up system resources and network resources? We will likely have hundreds of laptops regularly on the physical network with this, so it could contribute to a lot of unnecessary network chatter.


Would it be better to have the firewall reflect the port back to the OpenVPN server and let it connect? Or have our internal dns resolve the name to the private ip and allow them to connect directly? Would traffic then go over the vpn connection (which I do not want, when already on the physical network)? Or is it possible to tell it to ignore the connection when the client and server are already on the same network?


What's a sane way of handling OpenVPN client running as an always-on service when the client and server will often be on the same network?

  • It kinda depends. Are the OpenVPN clients bridge, as in do they receive an IP address in the same subnet as your wired network? Or do you have a separate subnet just for the OpenVPN network.
    – Zoredache
    Mar 1 '12 at 23:14
  • Separate subnet. Eventually I might have a need for bridged, but for now I'm just going for maximum throughput, so I'm using tun adapters.
    – James
    Mar 1 '12 at 23:17
  • IIRC, OpenVPN client tries to connect three times and then stops... I did not try it as a service, but you should check it out.
    – SJuan76
    Mar 1 '12 at 23:20

Keep doing what you're doing.

OpenVPN as a service trying to reconnect and failing is going to translate into minimal traffic. A quick check revealed that the initial "I'd like to connect to you" packet for openvpn was 14 bytes of data. Taking into account UDP, IP, and an Ethernet Frame overhead I get 56 bytes in total.

Avoid using OpenVPN internally, as it would actually add more overhead then just having OpenVPN fail to connect.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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