OpenVPN^TM FAQ

These FAQs are an attempt to distill questions and answers from the openvpn-users mailing list. If you don't find an answer to your question here, please consult the OpenVPN mailing list archives, which contains considerably more information than has yet been compiled into these FAQs.

Also, see the troubleshooting section in the HOWTO for more information.

I am having problems running OpenVPN with the Windows XP firewall enabled. What's wrong?

Microsoft has released a hotfix which may address this issue: http://support.microsoft.com/kb/913522/en

I've upgraded the OpenVPN daemon on one side of the connection to version 2.0, and now it can't connect. What's wrong?

Starting with version 2.0-beta17, OpenVPN's default port number has been changed from 5000 to 1194 per an official port assignment by IANA in November 2004. If you are mixing different OpenVPN versions on both sides of the connection, make sure to explicitly use a port directive, and not rely on the default value.

I've installed/upgraded OpenVPN 1.6.0 on XP SP2 and I can't find the TAP-Win32 adapter icon in the network connnections panel. What's the deal?

On Windows XP SP2, the TAP-Win32 adapter icon is missing from the network connections control panel. A workaround is available in OpenVPN 2.0.

This issue occurs because of a bug in XP SP2 which causes device drivers having HWIDs of 3 characters to fail to export network adapter icons to the network connections panel.

The workaround was to change the HWID of TAP-Win32 adapters from "TAP" to "TAP0801".

I've set up an OpenVPN server, and successfully connected a client to it, but when I try to connect a second client, the first client gets bumped off the VPN. What's the problem?

This is a common problem that occurs when you re-use the same certificate/key pair among multiple clients. It can also occur if you didn't provide a unique common name for every client's certificate. While none of these practices is recommended, if you cannot avoid using duplicate certificates or common names, use the --duplicate-cn config file option.

I'm getting this error: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other.

This is almost a result of:

• A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
• A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
• A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
• The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
• Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.

My OpenVPN client and server say "Connection Initiated with x.x.x.x" but I cannot ping the server through the VPN. Why?

This usually occurs because a firewall on the server or client is blocking the TUN/TAP interface. If you already have a firewall on your system, chances are high that it will block incoming connections on new interfaces by default, so you will need to add explicit firewall rules to allow connections via the TUN/TAP interface. In general, it's reasonable to open up TUN/TAP interfaces to all traffic, since any incoming connections over these interfaces will already have been authenticated by OpenVPN. An exception to this rule would be if you don't fully trust the OpenVPN clients connecting to the server. Assuming that's not the case, on Linux, TUN/TAP interfaces can be opened up with the iptables shell command:

# Allow TUN interface connections to OpenVPN server
iptables -A INPUT -i tun+ -j ACCEPT

# Allow TUN interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tun+ -j ACCEPT

# Allow TAP interface connections to OpenVPN server
iptables -A INPUT -i tap+ -j ACCEPT

# Allow TAP interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tap+ -j ACCEPT

On Windows XP, the firewall can be accessed by Control Panel -> Security Center -> Windows Firewall -> Advanced. In the Network Connection Settings control, uncheck the box corresponding to the TAP-Win32 adapter.

Note that if you want OpenVPN clients to be able access other machines on the LAN, it is not enough to merely disable firewalling on the TUN/TAP adapter. You must also enable IP forwarding and set up a return route from the LAN gateway to the OpenVPN server. This is discussed at length in the HOWTO.

Also note that firewalling the TUN/TAP interface is a completely separate operation from firewalling the internet-facing interface. For example, suppose an OpenVPN client is sending email via SMTP over the OpenVPN tunnel. The OpenVPN server firewall will need to allow both incoming encrypted data on TCP/UDP port 1194 via the internet-facing interface as well as incoming SMTP connections via the TUN/TAP interface.

Can an OpenVPN server be set up on a machine with a single NIC?

Absolutely, as long as you make sure that:

• The NAT gateway on the server's network has a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
• If you are using routing rather than ethernet bridging mode and would like connecting clients to see the whole LAN rather than only the server machine itself, you need to add an internal LAN route to the LAN gateway so that the private OpenVPN subnet (declared in the server, ifconfig, or ifconfig-pool directives) is routed to the OpenVPN server machine (i.e. its internal address).

I am running OpenVPN on Windows and the TAP-Win32 adapter is not coming up, causing the message "Initialization sequence completed with errors". What's wrong?

In Control Panel / Administrative Tools / Services, make sure that the DHCP Client Service is started.

If the above fix doesn't work, then it's possible that the TAP-Win32 adapter is being firewalled. In general, it's safe to disable the firewall on the TAP-Win32 adapter because OpenVPN makes sure that only an authenticated machine on the other end of the connection can communicate through it. Having said that, there have been reports that certain third party firewalls will block the TAP-Win32 adapter after an XP SP2 upgrade.

You can also try changing the ip-win32 setting to a non-DHCP method. For example:

• ip-win32 netsh
• ip-win32 ipapi
• ip-win32 manual

When I try ./configure on Red Hat 9 Linux or higher, it complains about OpenSSL headers not found. How to fix?

Try:

or

I've successfully set up OpenVPN and can ping between both OpenVPN peers, however I cannot reach any of the other machines on the remote subnet. What's the problem?

• Make sure that the firewall is not filtering the TUN/TAP interface.

• Make sure you have IP forwarding enabled on the server.

• If you are using routing (not ethernet bridging), make sure the clients (or LAN gateway) have a route back to the server for the packets coming in over the tunnel. This can be done by:
  • adding a route in your default gateway for the VPN network IP subnet pointing to the OpenVPN machine,
  • adding a route to every client, or
  • NATing all VPN traffic to the local address of the OpenVPN machine for network traffic which leaves the OpenVPN machine for the local net.

• If you are still stumped, use tcpdump, wireshark, or WinDump to determine where packets are being dropped.

How do I enable IP forwarding?

If you are using a routing-based VPN (dev tun) and you would like to configure your OpenVPN server or client to act as a VPN gateway for a LAN, you should enable IP forwarding.

On Windows 2000/XP, see this KB article.

On Linux, use the command:

echo 1 > /proc/sys/net/ipv4/ip_forward

I am having trouble getting OpenVPN 1.x to talk with OpenVPN 2.0. What's the problem?

While OpenVPN 2.0 is compatible with OpenVPN 1.x, some of the default options have changed. For this reason, if you want to connect OpenVPN 1.x to 2.0, add the following to your 1.x config file to set it to the defaults which 2.0 is already using:

  port 1194
  tun-mtu 1500
  tun-mtu-extra 32
  mssfix 1450
  key-method 2

Also note that OpenVPN 1.x cannot connect as a client to an OpenVPN 2.0 server running in the new --mode server mode. This is because OpenVPN 1.x lacks the --pull directive which is essential to the operation of OpenVPN 2.0's client/server mode.

I am running OpenVPN 1.6.0 on 2.6.8.1(client) and 2.4(?) on server. Quite inevitably, after a few days of uptime, I get the message: Tue Oct 26 14:34:48 2004 36880: write UDPv4 []: No buffer space available (code=105)

Increase the required free memory. I recommend at least 2 MB, which you can set with:

If you don't bump it up, the min_free_kbytes value for 2.6 kernels gets set to something pitifully small, giving the kernel essentially no incentive to reclaim memory that's no longer used. You can watch your free memory gradually decline by running free or vmstat periodically - once per hour or so.

You can kick the kernel into freeing memory by running something that allocates a lot of memory, something like hdparm -tT /dev/hda. Apparently when servicing userspace requests for memory, the kernel can free unused memory if it doesn't have enough, but when servicing interrupts caused by events like packet arrivals it needs to have enough memory free before the interrupt. (I'm unsure of this explanation, but it seems to make sense and agrees with what I've observed happening.)

I set min_free_kbytes to 8 MB on my servers, which have lots of RAM. The (2.6.6) system I use for my OpenVPN tunnel at home has only 64 MB of RAM, so I use 2 MB for its min_free_kbytes. Its current uptime is 110 days.

Most of the time, the kernel will actually keep quite a bit more memory free than the minimum specified, so don't specifiy too large a value.

I can ping through the tunnel, but any real work causes it to lock up. Is this an MTU problem?

Probably. It's best to change the mssfix parameter rather than directly changing the MTU of the TUN/TAP adapter. For example:

You could also combine this with:

Note however that fragment will exact a performance penalty.

Common values to try for mssfix/fragment: 1200, 1300, or 1400.

Note that while mssfix only needs to be specified on one side of the connection, fragment should be specified on both.

Why does OpenVPN's "ifconfig-pool" option use a /30 subnet (4 private IP addresses per client) when used in TUN mode?

OpenVPN allocates one /30 subnet per client in order to provide compatibility with Windows clients due to the limitation of the TAP-Win32 driver's TUN emulation mode.

If you know that only non-Windows clients will be connecting to your OpenVPN server, you can avoid this behavior by using the ifconfig-pool-linear directive.

In OpenVPN 1.6, when you had to run one OpenVPN instance per client, then it would be more like you expected: a PtP link between the server and each client.

In 2.0 however, OpenVPN can handle multiple clients with only one tun interface on the server. To handle this, you can think of the PtP link you see on server as a link between the operating system and OpenVPN. Then when you're inside OpenVPN, another PtP link needs to created to each client. If all O/S would have supported true PtP links over the tun interface, this could have been done with the OpenVPN server using only one IP address and each client using another IP address.

But, as the TUN/TAP driver implementation on Windows does not support true PtP links, this is emulated through a /30 subnet.

So, you first have a PtP link 192.168.1.1 <-> 192.168.1.2 between your server O/S and OpenVPN on the server.

Then OpenVPN assigns a /30 subnet for each client that connets. The first available /30 subnet (after the one the server is using) is:

• 192.168.1.4/30
• 192.168.1.4 -- Network address
• 192.168.1.5 -- Virtual IP address in the OpenVPN Server
• 192.168.1.6 -- Assigned to the client
• 192.168.1.7 -- Broadcast address.

Then to reach the rest of the network on behind the OpenVPN server, you push a route to the client, so traffic is routed through 192.168.1.5.

As 192.168.1.5 is only a virtual IP address inside the OpenVPN server, used as an endpoint for routes, OpenVPN doesn't bother to answer pings on this address, while the 192.168.1.1 is a real IP address in the servers O/S, so it will reply to pings.

It does cause a little waste of IP addresses, but it's the best way to allow a consistent configuration that works on all O/S supported by OpenVPN.

The TAP-Win32 driver includes a DHCP server which assigns the 192.168.1.6 address to you, that's why you see 192.168.1.5 as DHCP server address.

Hope I made things a little clearer.

Mathias Sundman

Why can't I run OpenVPN on Windows from a non-admin user account?

There are two reasons:

• Windows does not provide a WHQL-approved method to allow the TAP-Win32 driver to make its virtual device node accessible from a non-admin account.
• OpenVPN needs the ability to add routes to the system routing table. This requires admin privileges.

For more information, see the article How To Run OpenVPN as a non-admin user in Windows by Mathias Sundman.

I uninstalled OpenVPN on Windows 2000 and now it appears that Winsock is broken. How to fix?

There have been rare reports of winsock registry corruption on Win 2000 when Windows uninstalls the TAP-Win32 driver.

This is a known bug in Windows and a utility exists to fix winsock if this occurs.

I installed OpenVPN on Windows, and now the TAP-Win32 adapter seems to have become the default adapter for certain functions. How can I make my Ethernet adapter the default again?

When a new network adapter is added, Windows tends to put it at the top of its internal adapter list, making it the default for certain functions.

In many cases this is undesired -- unfortunately I'm not aware of any way that the TAP-Win32 driver installer can programmatically override this default.

Luckily, this can be fixed manually by going to Control Panel / Network Connections / Advanced / Advanced Settings. In the top subwindow of the dialog box, move the TAP-Win32 adapter down from the top position.

Are there any issues related to pushing DHCP options to Windows clients?

Yes, see this article.

What to do if the installation of the TAP-Win32 driver fails?

If your TAP-Win32 driver installation fails with a message such as "The system cannot find the file specified", it's possible that your registry is missing the all-important RunOnce Key. Windows 2000/XP has a bug that it cannot properly detect new hardware by *.inf files, if the "RunOnce" registry key is missing. See this article for more information.

Also, make sure that your system is not configured to silently reject unsigned driver installation.

Can I run multiple OpenVPN tunnels on a single machine?

Yes, of course.

If you are running 2 or more OpenVPN instances on the same machine, you will need a separate virtual TUN/TAP adapter and a separate port (using the port directive) for each instance.

Make sure each TUN/TAP adapter has a unique, non-overlapping subnet using server, server-bridge, or ifconfig.

How to fix the errors "MULTI: bad source address from client [192.168.100.249], packet dropped" or "GET INST BY VIRT: 192.168.100.249 [failed]"?

These errors occur because OpenVPN doesn't have an internal route for 192.168.100.249. Consequently, it doesn't know how to route the packet to this machine, so it drops the packet.

Use client-config-dir and create a ccd file for your client containing the iroute option to tell OpenVPN that the 192.168.100.0/24 network is available behind this client.

Everything seems to be configured correctly, but I can't ping across the tunnel. How to troubleshoot?

Make sure that your options match on both sides of the connection. See below for more info.

Some connection problems are caused by incompatible crypto, compression, or mtu options on either side of the tunnel. If you are using any of the following options on one side of the connection, make sure that you precisely match it on the other side:

• --cipher
• --auth
• --keysize
• --dev tun|tap [unit number need not match]
• --dev-type tun|tap
• --link-mtu
• --udp-mtu
• --tun-mtu
• --no-replay
• --no-iv
• --comp-lzo
• --fragment
• --tun-ipv6
• --tls-auth
• --secret
• --key-method
• --tls-client [matched with --tls-server on the other end of the connection]
• --tls-server [matched with --tls-client on the other end of the connection]
• --ifconfig x y [matched with --ifconfig y x on the other end of the connection]
• --proto udp
• --proto tcp-client [matched with --proto tcp-server on the other end of the connection]
• --proto tcp-server [matched with --proto tcp-client on the other end of the connection]

It is also useful to try to isolate the problem, e.g. is the crypto support working independently of the networking code? You can test this with:

Other loopback tests are presented in the INSTALL file.

Many connectivity problems start at the firewall. For example, if an OpenVPN daemon is tunneling data to and from a given TUN or TAP virtual adapter, a firewall rule must be present to permit incoming traffic on that TUN/TAP adapter. On a Linux iptables-based firewall you can enable incoming packets on a TUN device with this command:

or similarly you can enable incoming packets on a TAP device:

tcpdump or Wireshark are also very useful tools for troubleshooting connection problems.

tcpdump can be used to show encrypted tunnel traffic transiting OpenVPN's UDP port:

The above example assumes that your connection to the internet is via eth0, and that you are using UDP port 1194 as the tunnel port (the default).

tcpdump can also be used to show unencrypted traffic on OpenVPN's virtual TUN/TAP device:

In the above example, replace tun0 with the name of the TUN/TAP device. ifconfig can be used to show active network devices, both real and virtual.

Also, note that you cannot mix --dev tun and --dev tap on different ends of the connection. Use one or the other consistently.

If you are connecting different versions of OpenVPN, check the compatibility page.

Is IPv6 support planned/in the works?

Currently, there's limited support for IPv6.

Point-to-point IPv6 tunnels are supported on OSes which have IPv6 TUN driver support (this includes Linux and the BSDs). IPv6 over TAP is always supported as is any other protocol which can run over Ethernet.

When OpenVPN 2.0 is run in server mode, IPv6 is currently only supported in TAP mode, not TUN mode (Server mode IPv6 TUN support will likely be added post-2.0).

The VPN carrier connection must currently use IPv4 endpoints, however there's a patch which can be found in the openvpn-devel archives which adds IPv6 support. This patch will probably be merged into the mainline post-2.0.

What is the set of options needed to dig a tunnel between two gateways connected to the Internet with a pppoe connection (ip addresses very volatile). The documentation specifies that it's possible to use such a setup but I couldn't find exactly which options are needed.

OpenVPN has a trainload of options to handle the dynamic IP address scenario. One method I personally use is the Dynamic DNS method. Other methods are described below.

When the IP address changes at one end, you want to send a SIGUSR1 signal to the daemon. This will cause it to close and reopen the UDP connection, binding to the new local address. You should also use --float to let the daemon know to accept incoming connections from any IP address (assuming that authentication succeeds) and --persist-tun to keep the tunnel open across the UDP reset. Also use --persist-remote-ip to preserve the peer's most recently authenticated IP address which itself is dynamic.

In case you are wondering, SIGUSR1 is just a more flexible form of SIGHUP that allows the restart behavior to be modified through --persist-x options.

If you are downgrading privileges with --user and/or --group, use --persist-key as well so the daemon doesn't try to re-read the key on restart which would fail.

Consider using an --ipchange script to edit the hosts file so each peer can keep track of the other's IP address via a known hostname.

If you are giving a DNS hostname for --remote, you might want to use --resolv-retry to retry DNS lookups in the event of temporary errors that might happen if one peer is reconnecting to the network after a disconnect.

To make the setup more robust (such as able to deal with both sides going down at the same time, then coming back up with new IP addresses), you might want to use some sort of DNS service that follows your IP address, then use the DNS hostname as the --remote peer. In this case you would not use --persist-remote-ip, which would cause the daemon to re-resolve the hostname on restart.

There are other options as well. If sending a SIGUSR1 on connection reestablishment is inconvenient, you could use --ping and --ping-restart to set up a keepalive sequence that internally generates the SIGUSR1 upon loss of connection.

How can I build a binary RPM package for my specific Linux platform?

Building an OpenVPN binary RPM package requires these RPM prerequisites:

• openssl
• openssl-devel
• lzo
• lzo-devel

The openssl package is almost always installed by default on Linux distributions. The openssl-devel package is almost always available on Linux distributions, but is sometimes not installed by default. The lzo and lzo-devel packages are usually included in more recent Linux distributions but must be installed manually. See the Dag Wieers site for a comprehensive set of LZO RPMs for Red Hat and Fedora.

Once the prerequisite binary RPMs are in place, building an OpenVPN binary RPM is quite straightforward:

rpmbuild -tb [OpenVPN .tar.gz file] 

You will see a lot of lines of output as rpmbuild compiles OpenVPN, but check near the end of the output for a line which looks like this:

This tells you where rpmbuild wrote the binary RPM file. Now, use:

rpm -ivh [OpenVPN .rpm file] 

to do a fresh install of OpenVPN, or

rpm -Uvh [OpenVPN .rpm file] 

to upgrade an existing installation.

On Slackware, I get the error: Cipher algorithm 'BF-CBC' not found (OpenSSL)

By default, OpenVPN uses the blowfish cipher for tunnel encryption. For some reason, some versions of Slackware have an OpenSSL library built without Blowfish cipher support.

The fix is either:

• Rebuild the OpenSSL library to include blowfish, or
• use the --cipher option to choose a different cipher. The command openvpn --show-ciphers will show the available ciphers. For example --cipher DES-EDE3-CBC will select Triple-DES encryption.

Does anybody know how to remap local addresses, if I want to connect two networks with an overlap in the private address range?

Using iptables 1.2.7a+ and the NETMAP target:

What is the principle behind OpenVPN tunnels?

Okay, here is a brief summary of the principle behind OpenVPN:

Imagine you had a direct physical wire (i.e. a long cable) connecting two computers (A and B) at different locations. On each computer there would be a /dev/longcable which would be a network device. You could route IP traffic over it, and do everything you could normally do with a network device.

Basically a tun device is like having a /dev/longcable except the OpenVPN daemon is the program that connects the /dev/longcable on computer A with the /dev/longcable on computer B so that you can use the internet rather than a real physical cable. But in this case it is called /dev/tun or whatever your OS prefers to call them.

Now the mechanism by which OpenVPN connects /dev/tun on computer A with /dev/tun on computer B is this: It simply creates an encrypted UDP connection over the internet between A and B and forwards traffic between /dev/tun on A with /dev/tun on B. Because of the clever way in which the tun and tap drivers were designed, it is possible for a program running entirely in user-space to effect this link, allowing OpenVPN to be a portable cross-platform daemon (like SSH), rather than an OS-specific kernel module (like IPSec).

The difference between a tun and tap device is this: a tun device is a virtual IP point-to-point device and a tap device is a virtual ethernet device. So getting back to the "long cable" analogy, using a tun device would be like having a T1 cable connecting the computers and using a tap device would be like having an ethernet network connecting the two computers. People who are running applications that need the special features of ethernet (which won't work on an IP-only network) will often bridge their physical local ethernet with a tap device (using a utility such as brctl on Linux), then VPN the tap device to another similar setup at the other end. This allows OpenVPN to route ethernet broadcasts and non-IP protocols such as Windows NetBios over the VPN. If you don't need the special features of ethernet (such as bridging capability), it's better to use a tun device.

Tun and tap devices can be interconnected to create a complex routing topology. Some people have created multi-node WAN networks over tap devices and actually run DHCP over the VPN so that clients can log into the virtual ethernet and request an IP address. I've even heard of people using Linux advanced routing to run OSPF (a kind of dynamic routing protocol) over the VPN WAN to allow for dynamic, fault-tolerant routing. They sky is the limit as far as the complexity of network you can build, but the basic building block is a VPN daemon such as OpenVPN connecting tun or tap devices on two different machines.

Are there any known security vulnerabilities with OpenVPN?

Not to our knowledge (as of 2004.12.08). The current OpenVPN security model matured by version 1.1.0, which was released in 4/2002. Since that time, there have been no confirmed reports on the OpenVPN lists or other security-related forums claiming any security vulnerabilities due to bugs in the software.

Having said that, there is always the potential for security vulnerabilities to be introduced by incorrect configurations. One such vulnerability is discussed here.

While OpenVPN has not as yet been subjected to a comprehensive security review, so far the security model has stood up well to analysis. In 9/2003, cryptography expert Peter Gutmann looked at the field of open source VPNs with a critical eye, and OpenVPN was singled out for some positive remarks.

OpenVPN's security model can be summarized as such: Use the IPSec ESP protocol for tunnel packet security, but then drop IKE in favor of SSL/TLS for session authentication. This allows for a lightweight, portable VPN implementation that draws on IPSec's strengths, without introducing the complexity of IKE.

See the article OpenVPN and the SSL VPN Revolution (PDF), by Charlie Hosner, for a more in-depth look at OpenVPN from a security perspective.

While it's impossible to assure with certainty that no weaknesses exist, OpenVPN has multiple levels of security to protect against a single flaw causing a catastrophic security breach. For example, by using --user nobody --group nobody you can ensure that even if some kind of remote buffer overflow exploit were discovered, the exploit would be unable to elevate its privilege to root. Another example is using SSL/TLS security with --tls-auth. Using --tls-auth ensures that even if a remote buffer overflow is discovered and exploited in the SSL/TLS authentication code in the OpenSSL library, it could not be used to attack an OpenVPN session that is protected with a --tls-auth password. In addition, if you use SSL/TLS authentication, you have the benefit of "perfect forward secrecy".

Is it important to OpenVPN security practices to build an intermediate certificate authority/key?

Unless you know that you need it, you generally don't -- just be very careful about keeping your CA safe.

Having an intermediate CA allows you to keep your "real" CA locked up with no network connections whatsoever and the intermediate CA located somewhere with security levels which, while high, impinge less on getting work done. Then, in the event that the intermediate CA is compromised, you can revoke it and create a new one without replacing your real CA.

If you're not going to be following this procedure (real CA locked up w/ no network connections), there's no value-add to having an intermediate CA.

I edited my OpenVPN static key, changing some of the hex bytes, but the key still connects to a remote peer which is using the original key. Is this a bug?

Can OpenVPN handle the situation where both ends of the connection are dynamic?

Yes.

A prerequiste of this method is that you subscribe to a service such as dyndns.org that lets you conveniently point an internet domain name to a dynamic address (or you can do it yourself if you have control over a DNS server that exists on a machine having a static IP address).

The crux of this method is in the 'timeouts' section of the config file below, or more specifically the 'ping' and 'ping-restart' options. Basically, if for whatever reason, OpenVPN doesn't receive a ping from its peer during a 300 second period (as would happen if its peer changed addresses), it will restart. When it restarts, it will re-resolve myremote.mydomain.com to get the new IP address. This method assumes that you are using a dynamic DNS service that lets you immediately update your domain name with your current dynamic address.

Using this technique, OpenVPN will essentially "follow" a dynamic DNS address as it changes.

Here is the config file example:

On the other end of the connection, you would duplicate the above config file but change 'remote' appropriately, and swap the ifconfig addresses.

If you are using TLS security, then also change 'tls-client' to 'tls-server', add a 'dh' file for the diffie-hellman file, and change 'cert' and 'key' to match your appropriate local cert and key.

This setup requires that each machine have a dynamic DNS name which is updated automatically when DHCP causes an address change. Such an automatic update can be accomplished by using a tool such as ddclient.

ddclient should be called by your /etc/dhcpc/dhcpcd-eth0.exe file (replace "eth0" in the filename with the appropriate network device name):

Here is a sample /etc/ddclient.conf file:

Does OpenVPN support Certificate Revocation Lists (CRLs)?

Yes. See the --crl-verify option in OpenVPN 1.5 and higher.

How stable is the OpenVPN Protocol, i.e. can old versions of OpenVPN talk to new versions?

While the OpenVPN protocol has been fairly stable since version 1.1.0, minor changes have occurred. See the Compatibility Notes for more information.

What is the difference between a TUN device and a TAP device?

A TAP device is a virtual ethernet adapter, while a TUN device is a virtual point-to-point IP link.

You cannot mix --dev tun and --dev tap on different ends of the connection. Use one or the other consistently.

What is Bridging?

Bridging is a technique for creating a virtual, wide-area ethernet LAN, running on a single subnet.

For practical information on bridging, see the Ethernet Bridging Mini-HOWTO.

What is the difference between bridging and routing?

Bridging and routing are two methods of linking systems via a VPN.

Bridging advantages

• Broadcasts traverse the VPN -- this allows software that depends on LAN broadcasts such as Windows NetBIOS file sharing and network neighborhood browsing to work.
• No route statements to configure.
• Works with any protocol that can function over ethernet, including IPv4, IPv6, Netware IPX, AppleTalk, etc.
• Relatively easy-to-configure solution for road warriors.

Bridging disadvantages

• Less efficient than routing, and does not scale well.

Routing advantages

• Efficiency and scalability.
• Allows better tuning of MTU for efficiency.

Routing disadvantages

• Clients must use a WINS server (such as samba) to allow cross-VPN network browsing to work.
• Routes must be set up linking each subnet.
• Software that depends on broadcasts will not "see" machines on the other side of the VPN.
• Works only with IPv4 in general, and IPv6 in cases where tun drivers on both ends of the connection support it explicitly.

What are the fundamental differences between bridging and routing in terms of configuration?

When a client connects via bridging to a remote network, it is assigned an IP address that is part of the remote physical ethernet subnet and is then able to interact with other machines on the remote subnet as if it were connected locally. Bridging setups require a special OS-specific tool to bridge a physical ethernet adapter with a virtual TAP style device. On Linux, for example, brtcl is this tool. On Windows XP or higher, select your TAP-Win32 adapter and your ethernet adapter in Control Panel -> Network Connections, then right click and select Bridge Connections.

When a client connects via routing, it uses its own separate subnet, and routes are set up on both the client machine and remote gateway so that data packets will seamlessly traverse the VPN. The "client" is not necessarily a single machine. It could be a subnet of several machines.

Bridging and routing are functionally very similar, with the major difference being that a routed VPN will not pass IP broadcasts while a bridged VPN will.

When you are bridging, you must always use --dev tap on both ends of the connection. If you are routing you can use either --dev tap or --dev tun, but you must use the same on both ends of the connection. --dev tun tends to be slightly more efficient for the routing case.

I want to set up an ethernet bridge on the 192.168.1.0/24 subnet. How do I configure OpenVPN so that it will cooperate with the existing DHCP server on the LAN?

There are two ways to do this.

Using the server-bridge directive is the easiest. First, set aside an address pool in your 192.168.1.0/24 subnet for use by OpenVPN clients. This range must be separate from the DHCP server range used on the subnet. Suppose you want OpenVPN to use 192.168.1.200 to 192.168.1.254 for allocation to connecting clients, and that the gateway for the LAN is 192.168.1.1. Then the appropriate server-bridge directive would be:

server-bridge 192.168.1.1 255.255.255.0 192.168.1.200 192.168.1.254

In the second method, the OpenVPN clients get their IP address lease from the DHCP server which is serving the LAN. For this configuration, you don't need a server-bridge directive, just something like:

mode server
dev tap0 # must be bridged with LAN ethernet interface
[SSL/TLS parms]
[keepalive parms]

The clients will negotiate a DHCP lease through the tunnel, meaning that both VPN clients and local machines will receive their IP addresses from the DHCP server address pool. The one complexity about this configuration is that you need to modify your DHCP server configuration to differentiate between local clients and VPN clients. The reason for this is that you must not pass out a default gateway to VPN clients. See the Win32 install notes for an example.

I'm using TLS mode with no --remote option on the server. When I start the server then the client it works ok. I can restart the client with no problem, but if I restart the server and the client is connected I get the following problem: "TLS Error: Unknown data channel key ID or IP address received from 111.222.333.444:10203". In this case I need to restart the client again to make it work. Do you know what the problem is?

This problem occurs because when you restart the server, there is nothing to trigger a new TLS key exchange. The server can't trigger it because it doesn't have a --remote option giving it the address of its peer, so it wants to sit and wait for a client to connect. The client doesn't trigger it because it doesn't know the server was restarted (remember that UDP is connectionless).

There are several ways to fix this problem, listed in the order of preference:

• Add a --remote option to the server which points to the client, making the connection peer-to-peer rather than client/server. When one peer restarts, it will force a new key exchange with the other peer.
• Use the --ping and --ping-restart options to force a key negotiation any time that packets are not getting through the tunnel. Restarts always trigger a new key exchange.
• Use static keys which allow OpenVPN to run in an essentially stateless manner.
• Use TCP rather than UDP as your tunnel transport (available currently in the 1.5.x and higher with the --proto option). TCP is a connection-oriented protocol, and as such, either side of the connection knows immediately when the other side has disconnected.

Can OpenVPN be used with the Shorewall firewall?

Yes, information is available here.

How can I connect Windows XP to a Linux-based Samba server using routing rather than bridging?

How can I implement OpenVPN as a classic, forking TCP server which can service multiple clients over a single TCP port?

See the OpenVPN 2.0 release notes.

Also:

I get the error Cannot ioctl TUNSETIFF tun0: File descriptor in bad state (errno=77)