OpenVPN open source

Community Resources

Configuring client-specific rules and access policies

Read

Which version of OpenVPN to use

Read

Configuring OpenVPN to run automatically on system startup

Read

Connecting to a Samba share over OpenVPN

Read

Connecting to an OpenVPN server via an HTTP proxy.

Read

Determining whether to use a routed or bridged VPN

Read

Ethernet Bridging

Read

Expanding the scope of the VPN to include additional machines on either the client or server subnet.

Read

Hardening OpenVPN Security

Read

2x HOW TO

Read

1x HOW TO

Read

Controlling a running OpenVPN process

Read

Implementing a load-balancing/failover configuration

Read

Important Note on possible "Man-in-the-Middle" attack if clients do not verify the certificate of the server they are connecting to.

Read

Installing OpenVPN

Read

Management Interface

Read

Mailing Lists

Read

Notes -- Differences between TAP-Windows driver and CIPE driver

Read

Notes -- Ethernet bridging, Windows client, Linux Server

Read

Notes -- Setting TAP-Windows address/subnet automatically via DHCP

Read

Notes -- Ethernet bridging, with the bridge occurring on the Windows side.

Read

Numbering private subnets

Read

OpenVPN cryptographic layer

Read

OpenVPN logos and icons

Read

OpenVPN on Windows notes

Read

OpenVPN Protocol

Read

OpenVPN Quickstart

Read

Porting Notes

Read

Protocol Compatibility

Read

Pushing DHCP options to clients

Read

Revoking Certificates

Read

RSA Key Management

Read

Running OpenVPN as a Windows Service

Read

Running OpenVPN from a console window

Read

Setting up routing

Read

Setting up your own Certificate Authority (CA)

Read

Static Key Mini-HOWTO

Read

Subversion Repository

Read

The standard INSTALL file included in the source distribution

Read

Using alternative authentication methods

Read

Reference manual for OpenVPN 2.4

Read

Reference manual for OpenVPN 2.3

Read

Reference manual for OpenVPN 2.2

Read

Reference manual for OpenVPN 2.1

Read

Reference manual for OpenVPN 2.0

Read

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.

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

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.
"MULTI: bad source address from client [192.168.100.249], packet dropped" or "GET INST BY VIRT: 192.168.100.249 [failed]"?

This error can occur if you don't include a ca directive in your profile, since the iOS Keychain does not provide the CA list from the PKCS#12 file to OpenVPN. The solution is to extract the CA list from the PKCS#12 file and add it to your profile via the ca directive. This is discussed in detail in the FAQ item above: How do I use a client certificate and private key from the iOS Keychain?

Starting with OpenVPN Connect v1.2.5, the app has restricted access to the iOS keychain. This is a policy enforced by Apple in order to improve security and avoid a generic app to access unauthorized key/certificates. For this reason PKCS#12 bundles have to be re-imported by OpenVPN Connect directly.
Please refer to the FAQ "How do I use a client certificate and private key from the iOS Keychain?" for detailed instructions about how to do so.

On Amazon AWS Marketplace you can look for "OpenVPN Access Server". You'll see a number of results. One of these will simply be titled "OpenVPN Access Server". This Marketplace image is suitable for the BYOL licensing system as long as you do not use auto-scaling and do not change the instance type after activating a license key. If you do then the virtual hardware that the license key has locked to will change and the license key may become invalid. In such a case you will have to contact us through the support ticket system to request a license key reissue. With this licensing model you pay for the AWS instance itself and any license keys that you purchase through us and activate on your Access Server installation. If no license key is installed, the Access Server goes into a demonstration mode where all functions work without time limitations, but it will only allow 2 simultaneous VPN connections to be established. A license key unlocks more connections.

The other images for OpenVPN Access Server listed on AWS Marketplace will have an amount of "connected devices" specified. These function using the Amazon AWS tiered instance licensing model, and these are billed directly through the Amazon systems per the stated hourly charges. The costs are separated into software licensing costs and AWS instance costs. These are billed hourly. If you launch an OpenVPN Access Server (?? connected devices) type instance on Amazon AWS you will incur charges for the use of the software and charges for the use of the instance you've launched while the instance is actively running. If you stop the instance, you will stop incurring additional costs. It is therefore possible to use such a system on demand, or in other words to have an instance on cold standby ready to be launched when needed.

Yes, CRLs are supported starting with version 1.1.14 for Android.

To use a CRL, it must be added to the .ovpn profile, such as:

<crl-verify>
-----BEGIN X509 CRL-----
MIHxMFwwDQYJKoZIhvcNAQEEBQAwFTETMBEGA1UEAxMKT3BlblZQTiBDQRcNMTQw
NDIyMDQzOTI3WhcNMjQwNDE5MDQzOTI3WjAWMBQCAQEYDzIwMTQwNDIyMDQzOTI3
WjANBgkqhkiG9w0BAQQFAAOBgQBQXzbNjXkx8+/TeG8qbFQD5wd6wOTe8HnypQTt
eELsI7eyNtiRRhJD3qKfawPVUabSijnwhAPHfhoIOLKe67RLfzOwAsFKPNJAVdmq
rYw1t2eucHvGjH8PnTh0aJPJaI67jmNbSI4CnHNcRgZ+1ow1GS+RAK7kotS+dZz9
0tc7Qw==
-----END X509 CRL-----
</crl-verify>

Multiple CRLs may be concatenated together within the crl-verify block above.

If you are importing a .ovpn file that references an external CRL file such as

crl-verify crl.pem

make sure to drop the file crl.pem into the same place as the .ovpn file during import, so the profile parser can access it.

While most OpenVPN client directives are supported by the app, we have made an effort to reduce bloat and improve maintainability by eliminating what we believe to be obsolete or rarely-used directives. Please email us at android@openvpn.net if you believe that a specific directive that is not included should be reconsidered for inclusion.

Here is a partial list of directives not currently supported:

  • dev tap — This directive is not supported because the underlying Android VPN API doesn't support tap-style tunnels.
  • fragment — The fragment directive is not supported due to the complexity it adds to the OpenVPN implementation and the fact that it is usually better to leave fragmentation up to the lower-level transport protocols. Note as well that the client does not support connecting to a server that uses the fragment directive.
  • mssfix — This directive will be added in a future release. Since the functionality of mssfix can be achieved on either the client or server side, specifying it on the server side will enable it even if the client doesn't support the directive.
  • secret — Static key encryption mode (non-TLS) is not supported.
  • socks-proxy — Socks proxy support is currently not supported.
  • Ciphers other than AES, Blowfish, and DES family — Currently, only AES, Blowfish, and DES family ciphers are supported. This is done to reduce bloat and improve energy efficiency. The AES cipher algorithm, in particular, is well-suited for the ARM processor generally used in Android devices.
  • proxy directives — While proxy directives are currently supported (http-proxy and http-proxy-option), they are currently NOT supported in <connection> profiles.

The BYOL model works on any OpenVPN Access Server, except the Amazon AWS tiered instance type that comes with a specification of the amount of connected devices allowed. With the BYOL model you can purchase a license key through our main website and activate it on your Access Server. These license keys are single-activation and lock to the system you activate it on, and unlock a certain amount of simultaneous VPN connections for the duration of the license key. When the license key expires, the license key disappears off the server. As explained below this licensing model is also available on Amazon AWS if you choose the BYOL type OpenVPN Access Server instance from the AWS Marketplace. The instances that specifically mention the amount of "connected devices" do not work with the BYOL licensing model but are instead billed directly through Amazon.

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 theserver, ifconfig, or ifconfig-pool directives) is routed to the OpenVPN server machine (i.e. its internal address).

Yes. An OpenVPN server can push HTTP and HTTPS proxy settings to an iOS client such that these settings will be used by Safari (or other iOS browsers) during the duration of the VPN session. For example, suppose that you are managing an OpenVPN Server and want iOS clients, after they connect, to use an HTTP/HTTPS proxy at 10.144.5.14 port 3128. You could add the following directives to the OpenVPN server-side configuration to push these settings to clients:

push "dhcp-option PROXY_HTTP 10.144.5.14 3128"
push "dhcp-option PROXY_HTTPS 10.144.5.14 3128"

Suppose also that you want several web domains to connect directly (example1.tld, example2.tld, and example3.tld), without going through the proxy:

push "dhcp-option PROXY_BYPASS example1.tld example2.tld example3.tld"

If your site uses a Proxy Autoconfiguration URL, you can specify the URL as follows:

push "dhcp-option PROXY_AUTO_CONFIG_URL https://example.tld/proxy.pac"

If you don't want to (or can't) modify the OpenVPN server configuration, you can also add proxy directives directly to the client .ovpn profile, by simply removing the enclosing push "..." from the directive:

dhcp-option PROXY_HTTP 10.144.5.14 3128
dhcp-option PROXY_HTTPS 10.144.5.14 3128

In some cases, if you push proxy options, it may also be necessary to push a DNS server address as well:

push "dhcp-option DNS 1.2.3.4"

Note that this feature controls application proxy use over the VPN tunnel and is not related to the connection proxy capability of OpenVPN to connect to a server through an HTTP proxy. The connection proxy capability is a separate feature that is accessed through the Settings App under OpenVPN or by using the http-proxy and http-proxy-optiondirectives.

No, license keys are single activation keys that lock to the hardware/software combination and cannot be moved to another system. If this action has already occurred and your license key is now not working anymore, then your only recourse is to contact us for a license key reissue, assuming that your license key is valid and not expired. We can then provide you with a new key that you can use to use your license again.

We would like to point out however that if you are deploying your system on Amazon AWS and you are looking to use autoscaling or you wish to rebuild your instance regularly for security regulatory purposes, then you can instead make use of the Amazon tiered instances on the Amazon Marketplace. These are launched through Amazon's systems and are billed directly through Amazon's systems as well, and these can be moved, copied, and reinstalled, just fine, as they will just pick up their licensed state from Amazon's systems and you will be billed for each instance that you actively have running.

Yes, using shortcuts. Go to Menu / Add Shortcut to add a shortcut to your home page. Shortcuts can be created for:

  • connecting a specific profile,
  • disconnecting, and
  • launching the app

On some Android devices, a connection notification sound is played by Android whenever a VPN tunnel is established, and cannot be silenced by a non-root app.

Note that it is possible to reduce the frequency of these notifications by going to the Preferences menu and selecting the Seamless Tunnel option.

Yes, you can import any number of profiles from the Import menu -- tap the profile field to select one. Keep in mind that OpenVPN will assign a name to a profile based on the server that the profile connects to. If you import a profile with the same name as one that already exists, the new profile will replace the old one. You can prevent this from happening by renaming the old profile.

Yes, you can add any number of proxies from the main menu. Once a proxy is added, a proxy selection field will appear on the main page. Tap the field to select a proxy or None at the end of the list to connect directly.

Yes, OpenVPN profiles can be created using the iPhone Configuration utility and exported to a .mobileconfig file, which in turn can be imported onto one or more iOS devices. Unfortunately, the process is a bit cumbersome at the moment because the directives of the OpenVPN profile must be manually entered as key/value pairs into the iPhone Configuration utility UI.

To create a .mobileconfig-based profile, open the iPhone Configuration utility, go to the File menu, and select "New Configuration Profile" (note that these directions were tested with version 3.5 of the iPhone Configuration utility on a Mac tethered to an iPad Air running iOS 7.0.4).

Next, edit the newly created Configuration Profile. Click on General in the left pane and fill out the fields such as Name, Identifier, Organization, etc. Click on VPN in the left pane and a "Configure VPN" dialog box should appear in the main window. Click the "Configure" button. Fill out the VPN settings as described below:

  • Connection Name should be set to a name that will identity this profile on the device.
  • Connection Type should be set to Custom SSL.
  • Identifier should be set to "net.openvpn.connect.app". (on older versions this used to be net.openvpn.OpenVPN-Connect.vpnplugin)
  • Server must be set to "DEFAULT". The actual server hostname will be configured via OpenVPN remote directives in the Custom Data section.
  • User Authentication should be set to Password, and the password field should be left blank.

Parameters normally given in the OpenVPN client configuration file must be defined using key/value pairs in the Custom Data section:

  • Define each OpenVPN directive as a key, with arguments specified as the value. As in the OpenVPN configuration file, arguments are space-delimited and may be quoted.
  • Key value pairs for remotecacertkeytls-authkey-directionauth-user-passcomp-lzocipherauthns-cert-typeremote-cert-tls must be defined if the server requires them.
  • If your server doesn't require clients to authenticate with a client certificate and private key, you can omit key/value pairs for ca and cert, but be sure to add the key/value pair "setenv" : "CLIENT_CERT 0".
  • The client certificate and private key can be separately imported onto the iOS device using a PKCS#12 file, in which case you can omit key/value pairs for ca and cert.
  • If you are attaching a private key to the configuration using the key directive, consider encrypting the key with a password to protect it while in transit to the target iOS device.
  • You must add a special key/value pair "vpn-on-demand" : "0" so that OpenVPN can distinguish this profile from an iOS VPN-On-Demand profile.
  • For OpenVPN directives with no arguments, use "NOARGS" as the value.
  • If multiple instances of the same directive are present, when entering the directive as a key, number the directives in the order they should be given to OpenVPN by appending .n to the directive, where n is an integer, such as remote.1or remote.2
  • For multi-line directives such as cacertkey and tls-auth, where the argument is a multi-line file, an escaping model has been provided to allow the file content to be specified as a single-line value. The procedure is to convert the multi-line data to a single line by replacing line breaks with "\n" (without the quotes). Note that because of this escaping model, you must use "\\" to pass backslash itself.
  • For OpenVPN Access Server meta-directives such as "OVPN_ACCESS_SERVER_USERNAME", remove the OVPN_ACCESS_SERVER_ prefix, giving USERNAME as the directive.

Once the profile has been defined, you have two options for exporting it to an iOS device:

  • If your device is currently tethered, click on your device name in the left pane. Then in the main window, click on the Configuration Profiles tab. You should see the name of your Configuration Profile and a button to install it on the device.
  • You can also save the Configuration Profile as a .mobileconfig file, and make it available to iOS clients via email or the web. To do this, select your Configuration Profile, go to the File menu, and select "Export...". An Export Configuration Profile dialog box will appear. Select a Security option -- "Sign configuration profile" is a reasonable choice. Press the Export button and save the profile.

When an iOS device receives an OpenVPN .mobileconfig profile (via Mail attachment, Safari download, or pushed by the iPhone Configuration utility), it will raise a dialog box to facilitate import of the profile. After import, the profile will be visible in OpenVPN.

For a sample Provisioning Profile without .p12 payload, please visit this page.

Yes, you can push an IPv6 DNS by using the same format used for IPv4 ones. For Example:

push "dhcp-option DNS 2001:abde::1"

No. That's because that system uses an ARM processor, and we haven't built Access Server for ARM. You might wonder why, since it is a Linux based program, and it should be possible to do so. The main reason aside from it still being a lot of work due to all the dependencies involved and having to support more than one major platform (x86/x64), is simply that ARM is a fairly low-power processor architecture compared to x86/x64. And there's nothing wrong with that in and of itself; ARM processors definitely have earned their place in the world of computers. But it's not a platform we would want to launch OpenVPN Access Server on, as people may have unrealistic expectations then. After all, encryption/decryption relies very heavily on the processor to do its work, and aside from that, a SoC platform like a Raspberry Pi has its network interface connected through a USB interface. All of this means you simply cannot get a very good performance out of OpenVPN in general on a Raspberry Pi. So we choose not to support it with our commercial product.

However, you can use the open source OpenVPN program instead. As a client, this could be suitable to connect to an Access Server. It can even be used as a site-to-site VPN gateway client system, although with some limitations on the speed at which it can handle traffic. And if you use the open source OpenVPN program, you can indeed also set it up to function as a server. Just not with the OpenVPN Access Server program, as that is x86/x64 only.

If you are looking for a small format cheap and energy frugal system to run Access Server on you may consider for example an entry system cheap Intel NUC system, or the MinnowBoard. There are dozens of projects out there with boards for development and tinkering that run on x86/x64 and are reasonably cheap.

Anim pariatur cliche reprehenderit, enim eiusmod high life accusamus terry richardson ad squid. 3 wolf moon officia aute, non cupidatat skateboard dolor brunch. Food truck quinoa nesciunt laborum eiusmod. Brunch 3 wolf moon tempor, sunt aliqua put a bird on it squid single-origin coffee nulla assumenda shoreditch et. Nihil anim keffiyeh helvetica, craft beer labore wes anderson cred nesciunt sapiente ea proident. Ad vegan excepteur butcher vice lomo. Leggings occaecat craft beer farm-to-table, raw denim aesthetic synth nesciunt you probably haven\'t heard of them accusamus labore sustainable VHS.

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 serverserver-bridge, or ifconfig.

If you need to split a license key up into smaller license keys, this is possible under certain conditions. The minimum size of a single license key must contain 10 licenses. So if you purchase a single license key for 30 connections, and you want to have it split up, you can create a maximum of 3 license keys of 10 connections each. We normally only consider requests to split license keys up if the license key has not already been used for activating an Access Server. To request your license key to be split up contact us on the support ticket system.

If for example you work for a company that does have license keys, but you have your own account and do not have a license key on your account, then you still have the right to support. If you provide the following information when you contact us on the support ticket system, then we'll give you support as if you were the holder of the license key. We require the following information from non-primary license holders to ensure that these individuals are in fact authorized to make changes to the account, as well as to protect the privacy of our valued customers.

  • The valid license key
  • Order ID # for the license key.
  • License holder name or email address.

If you do not have a license key at all, and you do not work for an organization that has a license key, then you can still contact us. We do want to help prospective customers to get things configured while they are trialing the software of course, but we do reserve the right to withhold certain support to users that are not actually paying customers of our OpenVPN Access Server product.

Yes. VPN-On-Demand (VoD) is a new technology introduced by Apple in iOS 6 that allows a VPN profile to specify the conditions under which it will automatically connect. In addition, using a VoD profile on iOS 7 allows OpenVPN to be connected and disconnected using the iOS Settings App under the VPN tab (although note that on iOS 8 and higher, ordinary OpenVPN profiles can be connected using the Settings App, as long as they don't require credential entry). OpenVPN on iOS fully supports VoD, with the following features:

  • The iPhone Configuration Utility can be used to create an OpenVPN VoD profile by entering OpenVPN configuration file parameters as key/value pairs.
  • The OpenVPN app supports connect and disconnect actions triggered by the iOS VoD subsystem.
  • The OpenVPN app recognizes VoD profiles and will show them in the UI and allow them to be monitored and controlled like other OpenVPN profiles (with the exception that VoD profiles cannot be manually connected from the app UI, they can only be disconnected -- this is because a VoD profile is designed to be connected automatically by iOS).

OpenVPN VoD profiles can be created using the iPhone Configuration utility. Unfortunately, the process is a bit cumbersome at the moment because the directives of the OpenVPN profile must be manually entered as key/value pairs into the iPhone Configuration utility UI.

For now, to create a VoD profile, open the iPhone Configuration utility (these directions were tested with version 3.5 on a Mac tethered to an iPad running iOS 6.0.1), go to the File menu, and select "New Configuration Profile".

Next, edit the newly created Configuration Profile. Click on General in the left pane and fill out the fields such as Name, Identifier, Organization, etc. Click on VPN in the left pane and a "Configure VPN" dialog box should appear in the main window. Click the "Configure" button. Fill out the VPN settings as described below:

  • Connection Name should be set to a name that will identity this profile on the device.
  • Connection Type should be set to Custom SSL.
  • Identifier should be set to "net.openvpn.connect.app". (on older versions this used to be net.openvpn.OpenVPN-Connect.vpnplugin).
  • Server can be set to a hostname, or "DEFAULT" to use the hostname(s) from the OpenVPN configuration.
  • User Authentication should be set to Certificate, and the client certificate+key should be attached as a PKCS#12 file.
  • VPN On Demand should be enabled and match entries should be defined to instruct iOS under which conditions the VPN profile should be automatically connected.

In addition, parameters normally given in the OpenVPN client configuration file may instead be defined using key/value pairs in the Custom Data section:

  • VoD requires an OpenVPN autologin profile, i.e. a profile that authenticates using only a client certificate and key, without requiring a connection password.
  • Define each OpenVPN directive as a key, with arguments specified as the value. As in the OpenVPN configuration file, arguments are space-delimited and may be quoted.
  • At a minimum, key/value pairs for ca and remote must be defined (Note that OpenVPN cannot get the CA list from the VoD profile, therefore it must be provided using a ca key/value pair).
  • Key value pairs for tls-authkey-directioncomp-lzocipherns-cert-type, and remote-cert-tls must be defined if the server requires them.
  • For OpenVPN directives with no arguments, use "NOARGS" as the value.
  • If multiple instances of the same directive are present, when entering the directive as a key, number the directives in the order they should be given to OpenVPN by appending .n to the directive, where n is an integer, such as remote.1or remote.2
  • For multi-line directives such as ca and tls-auth, where the argument is a multi-line file, an escaping model has been provided to allow the file content to be specified as a single-line value. The procedure is to convert the multi-line data to a single line by replacing line breaks with "\n" (without the quotes). Note that because of this escaping model, you must use "\\" to pass backslash itself.
  • For OpenVPN Access Server meta-directives such as "OVPN_ACCESS_SERVER_USERNAME", remove the OVPN_ACCESS_SERVER_ prefix, giving USERNAME as the directive.

Once the VoD profile has been defined, you have two options for exporting it to an iOS device:

  • If your device is currently tethered, click on your device name in the left pane. Then in the main window, click on the Configuration Profiles tab. You should see the name of your Configuration Profile and a button to install it on the device.
  • You can also save the Configuration Profile as a .mobileconfig file, and make it available to iOS clients via email or the web. To do this, select your Configuration Profile, go to the File menu, and select "Export...". An Export Configuration Profile dialog box will appear. Select a Security option -- "Sign configuration profile" is a reasonable choice. Press the Export button and save the profile.

When an iOS device receives a VoD profile (via Mail attachment, Safari download, or pushed by the iPhone Configuration utility), it will raise a dialog box to facilitate import of the profile. After import, the profile will be visible in the Settings App under General / Profiles. It will also be visible as a profile in the OpenVPN app. Note that the profile must be the currently-enabled VPN profile in order for the VoD functionality to work.

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:

remote myremote.mydomain.com
dev tun
ifconfig 10.1.0.2 10.1.0.1
up ./up-script # optional

# crypto config
replay-persist replay-persist-file # optional (1.4.0 or above)

# TLS config (or omit TLS security by using a pre-shared key
# such as 'secret static.key').
tls-client
ca key/my-ca.crt
cert key/my-cert.crt
key key/my-key.key
tls-auth key/my-tls-password # optional

# timeouts
ping 15
ping-restart 300 # 5 minutes
resolv-retry 300 # 5 minutes
persist-tun
persist-key

# compression (optional)
comp-lzo

# UID (optional)
user nobody
group nobody

# verbosity (optional)
verb 4
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):

/usr/sbin/ddclient -daemon=0 -syslog -use=ip -ip=$1
Here is a sample /etc/ddclient.conf file:

######################################################################
##
## TODO: change mylogin, mypassword, myremote. mydomain.com
##
######################################################################

login=mylogin # default login
password=mypassword # default password
#mx=mx.for.your.host # default MX
#backupmx=yes|no # host is primary MX?
#wildcard=yes|no # add wildcard CNAME?

##
##
## dyndns.org custom addresses
##
## (supports variables: wildcard,mx,backupmx)
##
custom=yes \
server=members.dyndns.org, \
protocol=dyndns2 \
myremote.mydomain.com

Yes, starting with iOS 8. Note that, if you are using 1.2.5 or older, only autologin profiles (i.e. profiles that don't require credential entry) can be launched using this mechanism. Starting with version 1.2.6, also profiles using a PKCS#12 bundle stored in the iOS keychain can be connected from the Settings.

Q: 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?
>When I modify the Preshared 2048 bit Static Key on the Initiator Side of the
>Tunnel(don't tested the other way) I'm anyhow able to establish the
>Tunnel an send Packets through the Tunnel. I don't understand
>the Key splitting and handling as described below, but I think the Keys
>on both Sides of the Tunnel should be identical for the Tunnel to be
>established.
>I can modify every Char in Line 2,3,4,7,8,9,10,11,12,13,14,15,16 without
any effect and think this is possible a Bug.
>Bye
> Klaus
No, this is not a bug. The 2048 bit static key is designed to be large
enough to allow 512 bit encrypt, decrypt, HMAC send, and HMAC receive keys
to be extracted from it.
However, this key size is far too large for current conventional OpenVPN
usage. OpenVPN uses the 128 bit blowfish cipher by default. It also uses
the 160 bit HMAC-SHA1 as a cryptographic signature on packets to protect
against tampering. Since you probably didn't specify a key direction
parameter, the encrypt/decrypt keys for both directions are the same and
the HMAC keys for both directions are also the same.
That means that OpenVPN is only actually using 128 + 160 = 288 bits out of
the file -- much less than the 2048 bits which are available.
Below, I will show a sample 2048 bit OpenVPN key, bracketed to show which
bits are actually used for key material, assuming default crypto settings:
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
[eac9ae92cd73c5c2d6a2338b5a22263a] -> 128 bits for cipher
4ef4a22326d2a996e0161d25d41150c8
38bebc451ccf8ad19c7d1c7ce09742c3
2047ba60f1d97d47c88f7ab0afafb2ce
[f702cb04c7d15ff2606736c1825e830a -> 160 bits for HMAC SHA1
7e30a796] 4b82825d6767a04b3c8f4583
d4928127262c3a8603776bd6da339f69
dece3bbfee35f1dceb7cbceaef4c6933
2c2cef8ac550ed15213b216b825ab31e
49840f99ff9df3c5f31156439ed6b99c
4fc1bff417d33d77134365e38c9d71cd
e294ba6e65d51703d6d4a629d5fc618e
adddb889b8173ac79b4261328770bbbe
74294bc79e357c82af9ef53f2968be6a
007e6022da0a1a39f2ed5660f94a5926
35d72e5838dd78dd680d91f6edcf6988
-----END OpenVPN Static key V1-----
As you can see, the only lines actually used are 1, 5, and 6. And of
course, that matches up perfectly with what you observed.
To verify this, run OpenVPN as follows:
openvpn --dev null --verb 7 --secret key | grep 'crypt:'
where 'key' is a file containing the key shown above.
Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Encrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Encrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Decrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796
Note that the keys which are shown in the OpenVPN output exactly match the
bracketed section of the key source.
Now if you want to use more of the key material, it is possible to use two
sets of encrypt/HMAC keys, one for each direction:
openvpn --dev null --verb 7 --secret key 0 | grep 'crypt:'
(Note that the '0' after key chooses one symmetrical direction -- the
opposite peer would use a '1' to choose the other direction).
Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Encrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Encrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: CIPHER KEY: 2c2cef8a c550ed15 213b216b 825ab31e
Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Decrypt: HMAC KEY: adddb889 b8173ac7 9b426132 8770bbbe 74294bc7
Now notice that the Encrypt and Decrypt keys are no longer identical. The
encrypt keys are drawing key material from lines 1, 5, and 6 in the key
file, while the decrypt keys are drawing from lines 9, 13, and 14.
Now the opposite peer will use a key-direction of 1:
openvpn --dev null --verb 7 --secret key 1 | grep 'crypt:'
Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Encrypt: CIPHER KEY: 2c2cef8a c550ed15 213b216b 825ab31e
Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Encrypt: HMAC KEY: adddb889 b8173ac7 9b426132 8770bbbe 74294bc7
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Decrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796
Notice how the Encrypt and Decrypt keys are swapped, in relation to the
key-direction 1 example.
So you might ask why is the OpenVPN static key file so large, if such a
small percentage of the bits are currently used? The answer is to
accomodate future ciphers and HMAC hashes which use large keys. Changing
a file format is obviously problematic from a compatibility perspective,
so 2048 bits were chosen so that two sets of 512-bit encrypt and HMAC keys
could be derived for two separate key directions.

Fault 9000: 'twisted.internet.error.TimeoutError: User timeout caused connection failure.

In most cases this problem is caused by an inability of the OpenVPN Access Server installation to reach the Internet for an online activation. Please verify that Internet access is possible from this Access Server and that the DNS settings are correct. Verify on the command line that you can ping and reach Internet addresses from the operating system that the OpenVPN Access Server is installed on. Check that any firewalls or security groups are not blocking access. If your system is intentionally cut off from the Internet or if it is not possible to resolve this problem, request or perform an offline activation. In rare cases this error can also show up if the license key has already been used before for activation - all license keys are single-activation keys only. In such a case request a license key reissue.

Fault 9000: "twisted.internet.error.DNSLookupError: DNS lookup failed: address 'licensing.openvpn.net' not found: [Errno -2] Name or service not known." What's wrong?

This error is almost always due to a DNS resolver misconfiguration or a country-related block on your DNS servers. Please verify that Internet access is possible from this Access Server and that the DNS settings are correct. Verify on the command line that you can ping and reach Internet addresses from the operating system that the OpenVPN Access Server is installed on. Check that any firewalls or security groups are not blocking access. If your system is intentionally cut off from the Internet or if it is not possible to resolve this problem, request or perform an offline activation.

Yes, on Amazon AWS for example with the Amazon licensing model it's possible to choose an annual payment model which offers 20% discount compared to hourly payment. And with the BYOL licensing system if you purchase for longer than a year, you get a discount as well. There are different discounts for 2, 3, 4, and 5 years.

We currently do not have any discount program available to the general public for bulk discounts. However, feel free to discuss your needs with some detail as to how many licenses you need with our sales team at sales@openvpn.net and someone will get in touch with you regarding your request.

Yes, our activation system relies on being able to contact licensing.openvpn.net at port TCP 443 in order to complete activation. However if your system is installed somewhere where Internet access is not possible or not allowed, then it is possible to do an offline activation. This can be done by us when you contact us and request an offline activation and provide us with the necessary hardware activation file, or you can do it yourself using a second Access Server installation that does have access to the Internet, and which can be provided with the necessary hardware activation file, after which the resulting activated key file can be stored on the file system of the Access Server. We intend to provide a guide on how to do this here on the website (UNFINISHED MARKER)

Yes, OpenVPN Connect supports the tls-crypt option starting with version 1.2.5

Everything seems to be configured correctly, but I can't ping across the tunnel ¶
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:

openvpn --genkey --secret key
openvpn --test-crypto --secret key
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:

iptables -A INPUT -i tun+ -j ACCEPT
or similarly you can enable incoming packets on a TAP device:

iptables -A INPUT -i tap+ -j ACCEPT
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:

tcpdump -i eth0 udp port 1194
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:

tcpdump -i tun0
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.

OpenVPN Cookbook - 2nd Edition

by Jan Just Keijser
Publisher: Packt Publishing (Feburary 2017)
ISBN: 9781786463128

Purchase Here

Troubleshooting OpenVPN

By Eric F Crist
Publisher: Packt Publishing
(March 2017)
ISBN: 9781786461964

Purchase Here

Mastering OpenVPN

by Eric F. Crist and Jan Just Keijser
Publisher: Packt Publishing (August 2015)
ISBN: 9781783553136

Purchase here

OpenVPN 2 Cookbook

by Jan Just Keijser
Publisher: Packt Publishing (March, 2011)
ISBN: 1849510105

Purchase here

Not Finding What You Are Looking For?

Sorry you're not finding what you're looking for. Let us help you. Click on either Wiki/Tracker or Forums.