OPENVPN CLOUD IS LIVE: TRY TODAY FOR FREE
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.

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 or Bring Your Own License model is a model where you can install an OpenVPN Access Server anywhere, and then buy an activation key from our website, and install it on your Access Server to license it for a number of allowed VPN connections.

This works on pretty much all OpenVPN Access Servers except the Amazon AWS tiered instances that have (xx connected devices) in the title on the AWS Marketplace. Those images are activated and billed automatically through Amazon AWS.

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.

If you have an AWS tiered instance that you launched from the AWS Marketplace with (xx connected devices) in the title, it will be licensed and billed automatically through Amazon AWS. In such a case you would see “AWS paid AMI” on the Activation page of your Access Server. These type of EC2 instances can be stopped, imaged, and then from the AMI image a new instance can be launched, and the resulting EC2 instance would be billed and licensed automatically as well.

If you have a subscription, monthly or yearly, on your Access Server, then you can make a copy of this machine just fine. The new copy would then also be licensed with the same subscription. You can have multiple Access Servers on the same subscription, but you can’t have multiple subscriptions on the same Access Server.

If you have a fixed license key, then you cannot clone or copy your Access Server. Fixed license keys, recognizable for the fact that they are in the format of #EXA-MPLE-LICE-NSE#, can be activated on a server, but they then lock to that server’s hardware/software combination and cannot be moved to another system. If this action has already occurred and you lost your original server, 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.

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.

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.

The OpenVPN Access Server can be licensed to accept a certain number of VPN connections. This can be through Amazon AWS tiered instances that are licensed and billed through Amazon, or through BYOL. The BYOL (Bring Your Own License) model allows you to set up your OpenVPN Access Server anywhere and then purchase and activate an activation key to unlock a certain number of connections. The activation key can be of a fixed license key type that unlocks a very specific amount of connections and cannot be adjusted afterwards, or through a subscription that can be adjusted at any time.

For the subscription model, you can manage changing the amount of allowed connections yourself. Simply go to our Access Server licensing portal and alter the amount of connections on your existing subscription and create a new one. For example if you have a 50 connection subscription key now, and you actually want it to be two subscription activation keys of 20 and 30, then simply edit the 50 connection subscription and change it to 20, and then purchase a new subscription for 30.

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

To increase the amount of allowed connections on the fixed activation key model on an OpenVPN Access SErver, you can activate multiple fixed activation keys on the same Access Server. They simply add up. So if you have 10 allowed connections on a server now with a fixed activation key, you can simply activate another key for 10, to get a total of 20 allowed connections.

If for have or you work for a company that has OpenVPN Access Server activation keys, then we will offer support on our support ticket system. If the activation key isn’t on your account then you can provide the following information when you contact us on the support ticket system so we can give you support as if you were the holder of an activation 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.

  • Order ID # for the activation key.
  • Or the activation key itself.
  • License holder name or email address.

If you do not have an Access Server activation key at all, and you do not work for an organization that has an activation key, then you can still contact us. We do want to help prospective customers to get things configured while they are trialing our software, 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.

A: 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.”
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.

There is more information and troubleshooting steps available on our troubleshooting problems with software licensing page.

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.

Our pricing model is such that the higher amount you buy, the less the price will be per connection. If you have the need for a quote to do the purchase or if you wish to discuss possible discounts, free to discuss your needs with some detail as to how many VPN connections you would need with our sales team at sales@openvpn.net, and we’ll get back to you as soon as possible.

For the OpenVPN Access Server product we have the subscription licensing model which requires constant direct access (so not through a proxy) to the server asb.sts.openvpn.net on port TCP 443. If the interruption gets interrupted for a short while, like a few minutes or a few hours, that is not a problem, as the system is robust enough to function and accept new VPN connections even during such events (so long as you were not already at your limit yet). This software licensing model is flexible and allows multiple activations and sharing of a license across multiple Access Servers and lets you change the amount of connections allowed.

We also have the fixed license model which requires one-time direct access (so not through a proxy) for activation and renewals to licensing.openvpn.net at port TCP 443 in order to complete activation. This model does come with some drawbacks as it is single-activation only, cannot be shared across multiple Access Server nodes, and is of a fixed size which cannot be altered later on, although you can add additional fixed licenses on the same Access Server to increase its amount of allowed connections. They simply add up.

On Amazon AWS on the AWS Marketplace we also offered the tiered instances which are automatically licensed by reading specific metadata from the EC2 instance when launching our OpenVPN Access Server from the AWS Marketplace directly. These tiered instances can be recognized by the (xx connected devices) in the title of the offering on the AWS Marketplace. These are licensed for the stated amount of connections automatically through the Amazon AWS services and requires access to awspc1.openvpn.net at port TCP 443. There are also 3 backup licensing servers it can use (awspc2.openvpn.net, awspc3.openvpn.net, awspc4.openvpn.net) to get licensed and billed automatically through Amazon AWS.

If however your system is installed somewhere where Internet access is not possible or not allowed, then it is possible to do an installation of Access Server by downloading the Access Server package manually and installing it yourself, and then doing an offline activation. This uses the fixed license model. 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 manually transferred and stored on the file system of the Access Server.

For more information about the pricing for OpenVPN Access Server software licenses see the Access Server pricing page.

For more information and technical details about connection requirements see the troubleshooting software licensing page.

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.