OpenVPN Access Server

Commercial VPN server Resources

How to configure Access Server

Installing a valid SSL Web certificate in Access Server

SSL web certificate behavior in Access Server

Keeping Access Server updated

Migrating an Access Server installation

Explanation of client-side scripting with simple examples

Assigning a static VPN client IP address to a user

Change encryption cipher in Access Server

Branding Configurations on the Admin and Client Web Server Interfaces

Post-auth programming notes and examples

OpenVPN Access Server post_auth hardware address checking script

OpenVPN Access Server post_auth LDAP group mapping script

OpenVPN Access Server post_auth RADIUS group mapping script

Access Server post-auth SAML group mapping script

Setting up an OpenVPN Access Server cluster

Setting up high-availability failover mode

TOTP multi-factor authentication

OpenVPN Access Server on Active Directory via LDAP

Configuring Google Secure LDAP with Access Server

External public key infrastructure (PKI)

Integrate Okta with OpenVPN Access Server via LDAP

Integrate Okta with OpenVPN Access Server via RADIUS

Add Duo Two-Factor Authentication to OpenVPN Access Server

How to redirect HTTP to HTTPS?

CA Certificate Management

Smart Routing with Access Server Clustering and AWS Route 53

Data-channel cipher negotiation on OpenVPN Access Server

OpenVPN Access Server's User Authentication System

OpenVPN Access Server Web Services

Understanding Connection Profiles on OpenVPN Access Server

TLS Control Channel Security in OpenVPN Access Server

OpenVPN Access Server Downgrade Guide

OpenVPN Access Server FIPS compliance

How SAML Authentication works with Access Server

How to configure SAML with Azure AD

How to configure SAML with Google Workspace

How to configure SAML with Keycloak

How to configure SAML with Okta

How to configure SAML with OneLogin

How to configure SAML with JumpCloud

How to configure SAML with AWS

How to Configure SAML with Auth0

How to migrate OpenVPN Access Server on AWS to the latest version

Configure Access Server SAML authentication with DUO MFA and your IdP

Managing Access Control in Access Server

How to enable OpenVPN DCO on Access Server

Group default IP address networks for Access Server

Domain Name System, or DNS, is the system on the Internet that resolves names like openvpn.net to an IP address like 123.45.67.89 on the Internet. IP addresses are the unique addresses of computer systems in networks, and the Internet is one big network. These addresses work like phone numbers. They are unique and allow communication between the different computers on the Internet. To expect humans to remember IP addresses for all the various websites they want to visit, is simply not practical. So we create DNS names like openvpn.net, google.com, facebook.com, on the Internet, and let a DNS server take care of translating names to IP addresses. It can also be used for shorter host names in an internal network to resolve a name like pc1 to a private IP address.

OpenVPN Access Server automatically locks out user accounts after repeated failed authentications as a security precaution.  When this lockout is triggered on an account, the user receives a message like "LOCKOUT" or "user temporarily locked out due to multiple authentication failures" when trying to sign in. This prevents brute-force guessing the password by endlessly trying different passwords.

The lockout triggers when a wrong password is entered three times consecutively within 15 minutes. The lockout expires after 15 minutes. You can modify these default settings. You can also manually lift the lockout if you don’t want to wait 15 minutes.

Exceptions to the lockout policy are authentications done with a user-locked connection profile and bootstrap accounts. Access Server requires authentication with valid credentials to obtain a user-locked connection profile; bootstrap accounts can only bypass the lockout policy on Access Server 2.9 and older.

To change the lockout policy from the default settings, refer to this command line documentation page regarding the lockout policy.

Yes, Access Server 2.11.0 supports Security Assertion Markup Language (SAML) to authenticate your users with an Identity Provider (IdP), passing a SAML assertion containing the user authorization status to Access Server as the Service Provider (SP).

You can set up Access Server as the SP. We provide  documentation on how to set SAML up with some, but not all IdPs:

For more, refer to the SAML user manual page.

There is no reset command for this, so you will have to wait until the expiration timeout passes. What you can do is set the expiration timeout to 1 second, then wait 2 seconds, and then set it back to whatever the setting originally was. This effectively expires the lockout on all users on your server all at once within a second or two, and lets you log on again immediately. To do this run this set of commands shown below. Afterwards you should reconfigure your lockout policy expiration setting if it was different from the default 15 minutes lockout time. Note: all the command line tools assume you are in the /usr/local/openvpn_as/scripts/ directory and have root privileges.

Reset all lockout policy lockouts now:

./sacli --key "vpn.server.lockout_policy.reset_time" --value "1" ConfigPut
./sacli start
sleep 2
./sacli --key "vpn.server.lockout_policy.reset_time" ConfigDel
./sacli start

The lockout policy can be adjusted to match your needs. See also what is the lockout policy on Access Server for more details.

We will only describe the process here for the Ubuntu operating system, as that is the operating system that we have been using for years to distribute our HyperV, ESXi, Amazon AWS, and Azure appliances on. If you have another operating system you can look online how to configure things exactly. We also assume that you do not use the Ubuntu program NetworkManager. If you do, and you have a GUI on your server, you may want to instead do it via the GUI. But if you have a headless server running on a physical server, or on HyperV, ESXi, and so on, you can use this guide to set a static IP address. The process is relatively straightforward, there is a text file that contains the configuration for your network interfaces. Adjust it to look like the sample below and adjust the addresses to match your network and your desired static IP. We assume an IPv4 address because at the moment this documentation section was written the Access Server only supported incoming OpenVPN tunnel connections on IPv4.

Messing with the network interface settings could mean you lose network access to this system if you make a mistake. So be aware of this and either beforehand make a backup of your Access Server settings or make a snapshot if possible in your hypervisor, or see if can get access to the (virtual) console to make corrections afterwards. It is also important to note that if you have a DHCP server in your network you can also choose to use the DHCP reservation option there (if present) to always assign the same DHCP IP address to this server. But not all DHCP servers have this option. In such a case you can do a static IP address assignment in the Linux server operating system itself with the instructions below, but please then do not configure the static IP to one inside of the DHCP range, but outside of it. Otherwise the DHCP server may consider the IP address you have chosen for your server suitable for assignment to a DHCP client, and that can cause an IP address conflict. Some networks have no DHCP server at all, and in that case you can pick any free IP you want with the instructions below.

Open the file /etc/network/interfaces in the nano text editor:

nano /etc/network/interfaces

Example contents of the interfaces file:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens192
iface ens192 inet static
    address 192.168.70.2
    netmask 255.255.255.0
    network 192.168.70.0
    broadcast 192.168.70.255
    gateway 192.168.70.254
    # dns-* options are implemented by the resolvconf package, if installed
    dns-nameservers 192.168.70.254

Press ctrl+x, then press y, and then press enter, to save and exit the file. You should reboot to allow the changes to take effect.

In the example above, the IP address is set to 192.168.70.2 and it is in the 192.168.70.0/24 network with an Internet gateway and DNS server at 192.168.70.254. In some situations if the DNS server needs to be changed and you have things set statically you'll need to edit /etc/resolv.conf and update it to have the correct DNS server. Without a working DNS server you'll be able to ping IP addresses like 8.8.8.8 on the Internet, but not be able to resolve and ping addresses like www.openvpn.net. In the resolv.conf file you can fix that. Another important thing to note here is that in our situation shown above we have only one network interface and it is called ens192. If it is called something else in your system, obviously make allowances for this and adjust things as necessary.

If you have successfully changed the IP address, and you can gain access via SSH to the server, but the Access Server web services are not responding, it is possible you had your Access Server configured to listen to a very specific IP address, and if you have changed this, then the Access Server web services won't start. We have a guide to reset the web services and daemon ports here to resolve that issue.

IP forwarding is the ability for an operating system to accept incoming network packets on one interface, recognize that it is not meant for the system itself, but that it should be passed on to another network, and then forwards it accordingly. This is what you need when you have for example a system setup that is sitting between two different networks and needs to pass traffic between them. On pretty much any Linux system, barring a few exceptions, this can be accomplished by editing the /etc/sysctl.conf file and adding or uncommenting a specific line. To enable IP forwarding on Ubuntu/Debian for example you can do this:

Open the file /etc/sysctl.conf in the nano text editor:

nano /etc/sysctl.conf

Uncomment or add this line:

net.ipv4.ip_forward=1

Press ctrl+x, then press y, and then press enter, to save and exit the file. Next run this command:

sysctl -p

The alterations you've made to the sysctl.conf file should now have taken effect and IP forwarding should now be enabled permanently on this system. Please note that OpenVPN Access Server always ensures this is enabled by default, so no need to implement this on the OpenVPN Access Server installation itself.

In some of the more complex setups there are additional gateways with behind them additional subnets. If the OpenVPN Access Server itself can ping that gateway but cannot reach the subnet behind it, then the most likely solution here is to add in the routing table of the operating system where the Access Server is installed a route that directs traffic intended for the target subnet through the additional gateway. If traffic is then possible between the OpenVPN Access Server and the target subnet, then VPN clients should also be able to reach that target network as long as you give them access using the fields in user and group permissions and use the NAT method to give VPN clients access. If you use routing then it may not work because the VPN client subnet may be unknown to the target subnet. If you want to use routing then you should also implement a route back to the VPN client subnet using the OpenVPN Access Server's IP address in your network as the gateway address. It will function as a gateway to the VPN client subnet automatically.

To give VPN clients access to the additional subnets you can simply specify in the fields where you give users and groups access to subnets on the Access Server the additional subnets you want them to be able to reach. The traffic will then follow a path that goes from OpenVPN client to OpenVPN Access Server, and in the routing table there it will find the correct gateway and send the traffic there. That gateway then delivers it to the correct subnet. Responses generated there should then find their way back via static routes or routing tables to the IP address of the OpenVPN Access Server, and that will then send it to the OpenVPN client.

As usual, routing must be symmetrical, so it must function in both directions equally.

In some of the more complex setups there are additional gateways with behind them additional subnets. If the OpenVPN Access Server itself can ping that gateway but cannot reach the subnet behind it, then the most likely solution here is to add in the routing table of the operating system where the Access Server is installed a route that directs traffic intended for the target subnet through the additional gateway. If traffic is then possible between the OpenVPN Access Server and the target subnet, then VPN clients should also be able to reach that target network as long as you give them access using the fields in user and group permissions and use the NAT method to give VPN clients access. If you use routing then it may not work because the VPN client subnet may be unknown to the target subnet. If you want to use routing then you should also implement a route back to the VPN client subnet using the OpenVPN Access Server's IP address in your network as the gateway address. It will function as a gateway to the VPN client subnet automatically.

To give VPN clients access to the additional subnets you can simply specify in the fields where you give users and groups access to subnets on the Access Server the additional subnets you want them to be able to reach. The traffic will then follow a path that goes from OpenVPN client to OpenVPN Access Server, and in the routing table there it will find the correct gateway and send the traffic there. That gateway then delivers it to the correct subnet. Responses generated there should then find their way back via static routes or routing tables to the IP address of the OpenVPN Access Server, and that will then send it to the OpenVPN client.

As usual, routing must be symmetrical, so it must function in both directions equally.

The OpenVPN protocol itself functions best over just the UDP protocol. And by default the connection profiles that you can download from the Access Server are preprogrammed to always first try UDP, and if that fails, then try TCP. Unfortunately, on some more restrictive networks, all traffic except very commonly used ports are simply blocked.

For example on a public network it can be quite normal to see that only traffic for protocols such as HTTP, FTP, SMTP, POP3, and IMAP, are allowed, with usually some additional ports for SSL secured versions of those protocols, like HTTPS. Those protocols are almost all TCP-only and not UDP. On such networks it's useful to also support TCP connections, even though this is less ideal due to the possibility of the TCP Meltdown phenomenon. But given the choices between something that works reasonably well or not at all, we've chosen to be practical and also support TCP. By default we choose the port TCP 443 which is the same port as HTTPS traffic, which is usually allowed even on restrictive networks.

TCP stands for Transmission Control Protocol. Basically a means of sending traffic over the Internet with some built-in measures to ensure that traffic can get to its destination. If anything goes wrong during transmission, the protocol has some means to try to find a solution (send the packet of information again or try an alternative route or such). TCP Meltdown occurs when you stack one transmission protocol on top of another, like what happens when an OpenVPN TCP tunnel is transporting TCP traffic inside it. The underlying layer may detect a problem and attempt to compensate, and the layer above it then overcompensates because of that, and this overcompensation causes delays and problems with the transfer of data. That's the layman's version of it that is easy to explain and understand. We therefore instead recommend that you use UDP, which has no transmission control, and on top of that send your TCP traffic as usual, so that there's only one layer of transmission control, and the problem can be avoided.

Some people mistakenly believe that TCP is the best protocol to ensure the best reliability and performance for sending traffic over the Internet. This is the exception.

It is an abstracted view of a computer network, like for example your local computer network at home or in the office, or on a larger scale, the Internet. There are 7 layers that describe their own specific function in the whole. The first 3 are really the important ones that Access Server works with:

  1. Physical, or Bit - The cables and equipment that transfer bits of data from one device to another.
  2. Data link, or Frame - Frames of data that reliably carry data between two devices connected by a physical medium.
  3. Network, or Packet - Structuring and managing a multi-node network, with addressing, routing, and traffic control.

For a full list see the Wikipedia article about the description of OSI layers.

The Access Server by default operates on Layer 3 routed mode, where it functions like a router would, for the most part. You connect to it using our OpenVPN client software, and traffic intended for specific IP addresses can be routed through the VPN tunnel. You can for example allow 192.168.70.0/24 through, but leave all the other subnets and IP addresses on the client side. Or you can redirect all Internet-directed traffic from the VPN client through the VPN tunnel and through the VPN server. The point is you have control over which traffic goes through the VPN tunnel, and which traffic doesn't.

It is also possible for Access Server to operate in Layer 2 bridging mode, where it functions like a network switch or hub would, for the most part. You connect to it using our OpenVPN client software, and your client computer becomes bridged to the network that the Access Server is on. It connects you directly, so to speak. You have little to no control over what traffic goes through the VPN tunnel then. You can either enable or disable sending Internet-directed traffic from the VPN client through the VPN tunnel but that's about all the control you have over the traffic that flows through here. It also means broadcast traffic will be able to pass unimpeded through the link. For some older legacy software this may be necessary, but it is also quite ugly in the sense that if you have for example a 100 VPN clients connected, and 1 VPN client sends 1 megabyte of broadcast traffic through the VPN tunnel, then that gets re-broadcast by the Access Server to the other 99 VPN clients. That's a lot of data at once. It is for these reasons that we very strongly recommend to stick to the default Layer 3 mode. If however you are determined and knowledgeable enough to use Layer 2 bridging mode then you can find the instructions on how to switch to Layer 2 bridging mode here.

This is a side-effect of the fact that the OpenVPN 2 codebase is single-thread. That means it runs as a process on one CPU core and can't make use of multiple CPU cores at once. To get around the obvious performance limitation this creates on a server with multiple CPU cores, we spawn multiple OpenVPN daemons on the Access Server. We spawn 1 TCP and 1 UDP daemon per CPU core by default. An internal simple load-balancing system using iptables connects VPN tunnel connection requests coming in to the least loaded OpenVPN daemon.

Each OpenVPN daemon needs it own network interface to communicate with the operating system. The Access Server makes sure people connected to 2 different OpenVPN daemons can still contact each other if that is necessary. All the communication simply passes through the operating system and hits the routing table which determines which interface traffic should go to. So this doesn't cause a situation where clients are separated from each other when one is connected to one OpenVPN daemon, and the other to another OpenVPN daemon.

The interfaces looks like as0t0, as0t1, as0t2, as0t3, and so on, and each get a portion of the subnet defined in the settings in the Access Server.

This is related to why Access Server has multiple network interfaces. Each OpenVPN daemon launched needs it own subnet. So if you have 4 OpenVPN daemons running, each one gets a quarter of the subnet.

Yes — beginning with Access Server 2.9 and newer, you can install Access Server on Raspberry Pi using arm64 with Ubuntu Server. To install, sign into the Access Server portal, click Get Access Server, click Linux Software Package, click Ubuntu, and select Ubuntu 22, ARM64. For detailed steps, refer to Installing Access Server on Rapberry Pi.

Previous to version 2.9, we didn’t support Access Server installations on Raspberry Pi because of the low performance of previous models. The onboard network interface was connected through a shared USB2 port, which resulted in poor network speeds. On a Raspberry Pi model 2, you might get 10Mbps of encrypted data transfer, which isn’t sufficient for the VPN workload expected for a business-grade VPN.

However, since the release of Raspberry Pi model 4, which has a faster CPU and network connections, you can use Access Server on this model for modest deployments. The model 4’s network port can now reach gigabit speeds, and the ARM64 CPU provides a higher-performance platform. ARM64 is becoming more widespread and is also available on the Amazon AWS Graviton instance.

You can also use Raspberry Pi 5.

Even though the Raspberry Pi 4 and 5 are inexpensive devices, they're capable of at least 70Mbps of encrypted data transfer per CPU core. With a quad-core CPU, four tunnels of 70Mbps are theoretically possible. And theoretically, with future improvements, we should be able to achieve even higher speeds.

For simple use cases, Access Server's current performance on Raspberry Pi 4 devices is adequate. Now that it's available for Raspberry Pi, we believe more technology enthusiasts will try it out.

Notes:

  • Consider an Intel NUC system if you want to run Access Server on a small format, inexpensive, and energy-frugal system other than Raspberry Pi. The Intel NUC has an Intel desktop CPU like the i3, i5, i7, and so on and has plenty of processing power for heavier workloads.
  • Another x86/64 alternative to the Raspberry Pi is the MinnowBoard. There are dozens of projects out there with reasonably inexpensive boards for development and tinkering that run on x86/x64.

Sometimes people want to be able to access the VPN clients directly from the network behind the Access Server. So if for example you have your Access Server installed in your company network, and you have the need to connect directly to a VPN client that is connected from outside to your OpenVPN Access Server, from your company network, then this is possible. But by default a lot of setups use the NAT mechanism, which lets traffic flow from VPN clients to the private networks behind the Access Server, but not the other way around. To lift this restriction you must use routing. And when you use routing, the private network in your company network must then be made aware of where the VPN client subnet is, where it can be reached. It needs to know the gateway system that can lead to the VPN client subnet. And that gateway address then is the IP address of your local Access Server installation in your company network.

Check the reach OpenVPN clients directly from a private network page for more information.

We're not going into the technical details of how the encryption works, as that would become a rather long winded mathematical explanation, but we are going to explain a bit about how SSL certificates play a role in securing Internet traffic. SSL stands for Secure Sockets Layer and is sort of an add-on to an existing system. For example, HTTP traffic is the type of traffic that web browsers use to transfer information from a web server, like the Access Server's admin UI, to your computer, in the web browser. HTTP by itself is completely unsecured. Anyone intercepting the traffic between your web browser and a web server that uses the HTTP protocol, can see all the pages and texts and information flowing over the network, and can read along with what you're seeing in your web browser. Obviously that is terribly insecure when you're visiting a website of a bank or other financial institute. Therefore a security layer is added call SSL. If you apply this to HTTP it becomes HTTPS instead - a secure version of HTTP. With SSL an encryption layer is set up and any traffic flowing over that connection is unreadable to outsiders. This is done using a very clever system using prime numbers and mathematical calculations that make it impossible for anyone trying to intercept the traffic to see what's going through the encryption connection. Over this encrypted connection, normal HTTP is transferred. But this is only visible and legible to the web server itself, and your web browser. Anyone in between will just see encrypted information, useless to them.

But encryption alone is not the only purpose. Another important purpose is establishing trust. Can you trust that the server you are connecting to, is actually the server that you think it is? For example if you are visiting your bank's website, how can you be sure that this is actually the bank's website, and not some other site that cleverly looks a lot like it, but isn't actually your bank's website at all? That's one of the main purposes of SSL certificates - to determine identity of the server and holder of the private key and public key. SSL certificates consist of 2 major components: a private key, and a public key. The private key is generated by the bank itself, and stays with the bank. Nobody else ever gets to see that private key. It is a series of random numbers and letters that has been stored on the web server of the bank and doesn't ever get shown to anyone else. That is the secret key that nobody else but the bank must know. With this private key, the system administrator of the web server uses a tool like OpenSSL to create a CSR, or Certificate Signing Request. This is a standardized form with a bunch of questions like, what is the address of your website (common name), what are your contact details, where are you located, and so on. Once all these questions are answered a file is generated that is connected to the private key cryptographically, but does not contain the private key itself. The next step is sending this to a certificate authority.

A certificate authority is a company or organization that makes it its business to confirm identity of the owner of a website, and when it has validated this, to take your CSR and sign a new public certificate with their keys. Their keys are special because they are trusted by a root authority. And root authorities are automatically trusted by your web browser or other SSL capable programs. There's a list in your web browser of known major root certificate authorities and their public keys which are automatically considered trustworthy. Any certificates they sign are trusted as well. Certificates work with a hierarchy: an SSL certificate for your website signed by a certificate authority contains in it information that identifies the certificate that stands above it - in this case the certificate authority that signed your key. And their key also contains information that identifies the certificates above it - all the way up to the root certificate authority key. So it forms a chain from the public key (certificate) they create for your website, all the way to a trusted root authority. Your web browser or other SSL capable program automatically tries to follow this chain and if it ends up at a root authority certificate that is trusted by your computer, then the private key you get is also automatically trusted.

This signed key is a public key that is cryptographically tied to your private key, but does not contain the private key itself. They are inextricably linked. The public key, as the name indicates, is installed on the web server and anyone that visits gets a copy of it. It's like showing your passport to whomever wants to see it to confirm your identity. But only a trusted authority can issue a passport, and only they know things about you like where you were born, where your live, etcetera, and that you are truly the holder of this passport. Like on a passport, the country and authority that issued it will be mentioned on it. In SSL certificate terms this is the certificate authority that issued you your certificate. Anyone seeing the SSL certificate can check with the authority above it to see if it's a real certificate.

A neat property of a public-private key pair is that they are linked. If you as a visitor receive the public key, and check it with the certificate authorities above it to see if it's a real certificate that is trusted by a root authority, then you can do the next test: is the web server showing you this public key also the holder of its linked private key? If not then they're just faking it. So this needs to be tested. Modern passports can have biometric data integrated into it, like fingerprints and such. Only the real holder of the passport can give their biometric data in a fingerprint test and actually have it match to what is known on the passport. Likewise, anything encrypted using the public key can only be decrypted by the holder of the private key that belongs to this specific public-private key pair. So by simply sending information encrypted with the public key and receiving a sensible response you can be sure that the web server you're talking to is really the correct web server. After all, only the private key that was used to create the original Certificate Signing Request, which was then approved and signed by a certificate authority and resulted in a public key, can be used to decrypt data encrypted with the linked public key.

So that's your proof of identity and method of establishing trust. That's, simplified, how SSL certificates play a role in securing Internet traffic and making sure you are connected to the correct web server.

You can send in bug reports and feature requests by opening a support ticket and providing the details there.

Please note that if you want to report a security vulnerability, you can do so by following the security disclosure procedure.

To use the Android OpenVPN Connect app, you need an OpenVPN profile to connect to a VPN server. OpenVPN profile files have an extension of .ovpn.

You can import a profile through the following methods:

  1. Import a .ovpn file:
    1. Copy the profile and any files it references to your device’s file system — ensure you put all files in the same folder.
    2. In the app, tap + > File > Browse.
    3. Import one profile at a time.
  2. Import a profile directly from OpenVPN Access Server:
    1. In the app, tap + > URL.
    2. Enter the URL for the Client Web UI of the OpenVPN Access Server.
    3. Tap Next.
    4. Enter your user credentials and any MFA, if needed.
    5. Tap Import.
  3. Import a profile from OpenVPN Cloud:
    1. In the app, tap + > URL.
    2. Enter the URL for your Cloud user portal.
    3. Enter your user credentials and click Next.
    4. Select a VPN region.
    5. Tap Connect.

Once you’ve added a profile, that profile displays in your app. Tap on a profile’s toggle to connect to the profile’s VPN server. Once connected, Connection Stats display. To disconnect, tap the toggle.

The OpenVPN Access Server by default generates a server CA and private/public key pair that is unique to your server installation, for the purpose of verifying the identity of the OpenVPN server, and also to create and sign private/public key pair for each VPN account individually. The goal of all this is to make it possible for the VPN clients to verify the identity of the VPN server, and vice-versa, for the VPN server to verify the identity of the VPN clients. Each VPN user account on the Access Server gets its own private key and public certificate.

In other applications that use certificates, the lifetime may be much shorter. For example for HTTPS websites there are certificate providers that generate certificates that are valid for 2 years, or even certificate providers that generate certificates that are only valid for 3 months, and there are programs in place that automate the retrieval and renewal of these certificates (or it is done manually). Generally these type of systems rely on public methods to verify identity of a party like DNS records or domain registry contact information or such. They will use that information to confirm identity and then issue a new certificate. Another difference is that for example web servers are public and there is no pre-existinging trust relationship existing between you and the web site. You do not know the identity of the owner of the sites you visit, most likely, and they don't give you access using access keys, generally speaking. So with web sites, you do need a way to automate establishing trust, which we do by the use of public root authorities that every web browser is equipped with, and it can check the trust path between the public certificate on a stated web server name and see if it was checked and signed by a root authority we already trust. That is a fundamental difference with VPN, where you must have someone give you access in advance, and there is no public records to check.

Of course with VPN, the VPN clients do not have personal identifiable information in public records like web servers do to automate retrieval and renewal of certificates. So you need to go to the Access Server and log in using your unique credentials, and obtain the necessary files, to get started. And if the system administrator has disabled access to the web interface, then only the system administrator will be able to provide you with the required certificates and configuration to get your connection working. And once it is working, you would most likely prefer for it to continue working from that point on without having to revoke your certificates and reinstalling your VPN client when your certificate expires. And this is especially true if this is on unattended systems like servers or hardware devices that just need to be able to connect and stay connected without going in and replacing certificates regularly.

Please note that at any time a certificate can still be revoked from the Access Server side. There is a CRL (Certificate Revocation List) function in Access Server that allows the administrator to revoke VPN client certificates at will, so you still have full control in the event that, for example, a laptop gets stolen or lost, and the certificates on that laptop need to be revoked to ensure that nobody can abuse those certificates. They can just be revoked from the server side, and replacement certificates generated that are new and unique for that user.

Please note that Access Server has 2 components that use certificates, and one of them is the web services of the Access Server, which operates with certificate lifetimes and certificate trust relationship and management consistent with the rest of the Internet regarding certificates for websites, and another component where the certificates are used inside the OpenVPN tunnel protocol itself for server and client verification internally. These are 2 entirely different structures. Therefore, as a default for our own internal key infrastructure, we have chosen 10 years as the default lifetime for VPN certificates, to ensure there is no need to re-provision VPN clients at a regular interval. This default is chosen for you when the server is installed, however, if you start out with a new server installation, you can use the command line to select your own certificate lifetime.

 

Yes, it is available for ARM64 platforms on supported Ubuntu operating systems.

If you see the error message "InRelease doesn't support architecture armhf" then you are trying to install on an operating system that supports only 32-bit software. If your hardware device does support ARM64, install the correct 64-bit supported operating system and try the installation again. If your device cannot run 64-bit software you cannot install Access Server on it.

For more information on installing on Linux (ARM64 or AMD64):

OpenVPN Access Licensing Models Overview

Subscription key

This is our most recent licensing model to unlock more connections. It is a long activation key that works on OpenVPN Access Server 2.8.1 and above, and can be shared across multiple servers and be activated multiple times. It is a more flexible model that allows changing the subscription connection amount on-the-fly and can be a monthly or yearly subscription. It requires an Internet connection to function. Subscription activation keys can for example look like this:

ThisIsAnExampleKeyVGhpcyBpcyBqdXN0IGFuIGV4YW1wbGUga2V5IGFuZCBpcyB0b3RhbGx5IGZha2UuIElmIHlvdSdyZSByZWFkaW5nIHRoaXMsIHlvdSd2ZSBqdXN0IGZvdW5kIGFuIGVhc3RlciBlZ2cgb24gdGhlIG9wZW52cG4ubmV0IHdlYnNpdGUsIGNvbmdyYXR1bGF0aW9ucy4gSSdtIHNvcnJ5LCBidXQgdGhlcmUgaXMgbm8gcHJpemUgYXR0YWNoZWQuIEhhdmUgYSBuaWNlIGRheS4=

If you want to activate or troubleshoot the subscription licensing on your Access Server, consult the troubleshooting guide for subscription licensing.

Fixed license key

A fixed license key always follows the format of 4 groups of 4 characters. This is an older and less flexible method of activating your Access Server to unlock more connections. You cannot change the licensed amount of an existing fixed license key after purchase and activation, and you can only activate the key once on an Access Server. It is also the only licensing method that works on a server that has no Internet access at all, as there is an offline activation method available for this type of software license. Fixed license keys can look like this:

#THI-SISA-NEXA-MPLE

If you want to activate or troubleshoot a fixed license key on your Access Server, consult the troubleshooting guide for fixed license keys.

AWS tiered instance

This licensing model is only available on Amazon AWS and nowhere else. On the AWS Marketplace we have a number of our OpenVPN Access Server offerings available that come prelicensed upon launch. So if you pick the one with 10 connections, and launch it on Amazon AWS, then it will have 10 connections available immediately. It requires that the instance has access to the Internet. So there are no activation keys for this, it happens automatically online.

If you want to troubleshoot software licensing for an AWS tiered instance, consult the troubleshooting guide for AWS tiered instance licensing.

Our credit card payment processor has security features built in that try to filter out any suspicious transactions. Given how credit cards work, and how sometimes credit card information can end up being stolen or leaked, it is necessary for these automated security procedures to be in place. However, in rare cases, it is possible that your completely legitimate payment attempt gets blocked by such an automated anti-fraud system.

One thing that can affect this process is for example using a credit card from one country in another country. Or sometimes when the system thinks you are behind a proxy server, trying to hide your real online identity, it can block you. This detection is automated and not entirely flawless. Unfortunately there is very little on our end that we can do about this automated anti-fraud system, it is not managed by us, it is managed by the company that handles the credit card transactions.

There is however the option of using a PayPal account to do the payment. Creating a PayPal account is completely free, and you can connect your credit card or in many countries even a bank account to your PayPal account to use that to get the funds through PayPal to us. PayPal itself will generally want to do some verification steps to make sure you are truly the owner of this credit card or bank account, and once that verification process is done and the credit card or bank account is registered in your PayPal account, you can then use the PayPal payment option on our website during checkout to do the payment. PayPal will then handle the transaction and get the funds to us. This transaction is immediate, just like with a credit card payment directly, and you will be issued the license keys immediately.

Alternatively, if you do not wish to do the purchase online, you can choose to submit an offline purchase order with our sales department, although a minimum amount of 100 device connections in total is required for such a manual handling of a license key purchase order. The sales department will then wait for you to complete the payment before the license keys are provided to you.

Yes, we currently accept bank transfers/wires for license key orders of a minimum of 100 connections. We cannot accept orders smaller than this amount at this time due to the heavy transactional costs associated with an offline order. For more information about offline license purchasing options, please contact sales@openvpn.net directly.

We have a subscription licensing model that can be managed from our website. This type of subscription retains intact when you migrate your Access Server data from one machine to another. You can also simply look up this subscription and use the activation key to activate it on your new Access Server. You can activate a subscription multiple times and on multiple Access Server nodes at the same time. They will then simply share the subscription. Each node individually will be able to use all connections on the subscription, but the VPN connections on all Access Servers using the same subscription must not exceed the amount allowed on the subscription. If it does, as many VPN connections are terminated as are necessary to stay with the subscription limit.

We also offer OpenVPN Access Server on Amazon AWS on the AWS Marketplace as tiered instances. These are billed directly through Amazon AWS and you can recognize these on the AWS Marketplace because they have (xx connected devices) in the title of the offering on the AWS Marketplace. If you make an AMI image of such an EC2 instance and then create a new EC2 instance from that image, it will also be licensed. Of course each new instance will increase the amount you are being billed for, so they do not 'share' a single software license. This type of license is tied to the instance metadata which usually does get preserved if you create an AMI image and relaunch from such an AMI image.

We also have the fixed license activation key method. This is recognizable by an activation key that contains 4 groups of 4 characters (LICE-NSEK-EYIN-HERE). If you have such an activation key in use on your OpenVPN Access Server now, please note that this cannot be moved by you to another installation. You will need our help to do so. If you are preparing to reinstall your server or wish to move your Access Server installation to another environment, even virtual, then be prepared that your license will fail to function on the new installation. To resolve this, you can contact us ahead of time and let us know you need your license key reissued for a reinstall. You can do this up to 2 weeks in advance. When we reissue a license key, the old installation will still function for 2 weeks on the old fixed license activation key, while the new one can be activated on the new installation immediately. To get a license key reissued contact us on our OpenVPN Support page. Please note that we can only reissue fixed license activation keys if they are still valid and not expired.

 

That depends on what software license you have. Our software subscription license model allows you to activate on multiple Access Servers at the same time. They will then share this subscription. In that situation you only need one subscription for the whole group of nodes. If you still use the fixed license activation key model, then these keys only unlock connections on a single server, and these keys cannot be shared across multiple servers. In that situation you would need a separate key for each node.

In the case of subscription, the sharing of allowed connections occurs in the following way. As long as the total number of connected VPN clients on all Access Server nodes that use the same subscription does not exceed the allowed number of VPN connections on the subscription, then each node individually will be allowed to connect the full number of allowed VPN connections on the subscription. Only when that total goes over, will the subscription system eventually lower the number of allowed VPN connections just enough so you will again be within the limits.

As an aside, we do want to point out that load balancing using round-robin DNS with clustering is supported. But load balancing use a type of device or service that stands in-between the Access Server and the OpenVPN clients can be troublesome and is not supported. If you are considering doing this, try to setup sticky sessions at least, as it may help with some authentication problems.

No, if you use a software subscription license you can use it on the primary and secondary node of the Access Server without extra charge.

It is recommended to purchase and activate a subscription activation key. It is designed with this use-case in mind. This type of software license activation key allows you to activate on multiple Access Servers at the same time. It also automatically migrates from one node to the other in a LAN model failover pair. This means that if you activate a subscription activation key on the currently active node in a failover pair, the other one will also automatically use it once a failover event occurs.

The software subscription license sold on our Access Server portal on our website does not grant access to our VPN servers. It is a software key to unlock an amount of connections allowed on a server you manage yourself that is running our OpenVPN Access Server software product. Therefore we cannot provide instructions on how to connect to our servers with such a software license. If you have purchase a subscription license by accident you can request a refund on our support ticket system.

If you want to use a hosted VPN service, we offer OpenVPN Cloud, which is a business solution for hosted VPN connectivity. We run the VPN servers, and you can use it to secure your connection traffic between offices and employees.

We also offer Private Tunnel, which is designed to secure your Internet traffic and protect against certain threats on the Internet. This is suitable for consumers and business users that do not need to use it to transfer traffic between offices and employees, but just to protect their Internet connection, for example when on a public WiFi.

When this happens you should do the following:

  • Register a new free account on openvpn.net
  • Contact us with the details of the license key / order ID
  • Request to have the keys transferred to your account

We will then verify the information you have given us, and transfer the keys. A transfer of a license key from one account to another does not affect your currently installed and activated Access Server installation at all. This is purely an administrative change here in our licensing system, and does not in any way touch the activation state of your Access Server.

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. On Amazon AWS, for example, with the Amazon licensing model, it’s possible to choose an annual payment model that offers a 20% discount compared to an hourly payment. With the BYOL licensing system, the more connections you purchase, the less it costs per connection.

Our pricing model is such that the higher amount you buy, the less the price will be per connection. If you need a quote to make the purchase, or if you wish to discuss possible discounts, please send a note to our sales team at sales@openvpn.net, and we will get back to you as soon as possible.

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.

OpenVPN Access Methods and Licensing Models

Using a subscription

To use a subscription the OpenVPN Access Server requires direct access to the subscription server at asb.sts.openvpn.net on port TCP 443. Direct access means that the connection can’t route through an HTTP proxy server, and intercepting and terminating the connection prevents your Access Server from functioning. Should the connection between your Access Server and the subscription server work initially but later experience an interruption, your Access Server will still function. Temporary connectivity issues to the subscription server are generally acceptable. We designed the subscription licensing model to be robust, with the intention of replacing fixed licenses.

Once your Access Server has successfully activated a subscription, it remembers the last response received and continues functioning with that information, which even persists across reboots. If your Access Server experiences an extended connection interruption communicating with our subscription server, it automatically enters into a grace period. During this time it functions normally and accepts new VPN connections as long as the number doesn’t exceed the subscription limit. The grace period is dynamically controlled by OpenVPN and as such can vary per situation. But you can count on at minimum 2 days. This means that a loss of connection of 2 days between your Access Server and our subscription server is no problem at all. In most situations this grace period will even be significantly longer, in the order of weeks even. Eventually though your Access Server does need to successfully reconnect to the subscription server and refresh the subscription license state. Your Access Server automatically retries the connection at regular intervals. However, if the grace period expires and it’s not possible to restore connectivity, your Access Server reverts to only allowing two simultaneous connections.

The software subscription model is flexible; it allows multiple activations, lets you share a single subscription across multiple Access Servers, and you can change the allowed number of connections up or down as needed.

Using a fixed license

OpenVPN also offers the fixed license model, which requires one-time direct access for activation and renewals to licensing.openvpn.net on port TCP 443. The fixed license model comes with some drawbacks: It is single-activation only, it can’t be shared across multiple Access Server nodes, and has a fixed number of connections that can’t be changed after purchase. If you want to increase the number of allowed connections, you can purchase additional fixed licenses and activate them on your Access Server.

Using an AWS tiered instance

On the Amazon AWS Marketplace, you can purchase tiered instances for an EC2 with OpenVPN Access Server deployed with set connections. This type of connection is automatically licensed by reading specific metadata from the EC2 instance when launched directly from the AWS Marketplace. The tiered instances are designated with “(xx connected devices)” in the offering title on the AWS Marketplace. The instances are licensed for the stated number of connections automatically through Amazon AWS services, and require access to awspc1.openvpn.net on port TCP 443. Also, there are three backup licensing servers that can be used to get automatic licensing from Amazon AWS (awspc2.openvpn.net, awspc3.openvpn.net, and awspc4.openvpn.net). As long as the instance is running, the billing for this type of instance occurs automatically in Amazon’s system.

Offline activation

If your Access Server is located in an environment where Internet access isn’t possible or allowed, then you can manually download and install the Access Server package following an offline activation process. The fixed license model is the only model that supports offline activation. OpenVPN can perform the offline activation on your behalf, or you can use another Access Server that has Internet access for the activation phase. You either need to provide us with the necessary hardware activation file to do the offline activation for you, or you can use the hardware activation file with a second Access Server that has Internet access. The resulting activated key file can be manually transferred and stored on the offline Access Server’s file system.

Related resources

For more information about the pricing for OpenVPN Access Server software fixed licenses and subscriptions, refer to the Access Server pricing page.

For more information and technical details about connection requirements, refer to the troubleshooting software licensing page.

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.

We offer refunds on any purchased license key that has not been activated on a server and is still valid (not expired). To do so, please contact us on our support ticket system and mention that you want to request a refund, and mention the unused license key, the primary holder's email address and primary holder's contact name, as well as the order number associated with the license key. Upon validation of your information, we will then proceed with making a refund to the original method of purchase and revoke the license key in question.

Refunds are not given for used licenses, or licenses already activated on a server! This is because we assume that you are fully satisfied with the product before purchasing and applying the license key to the server. For this reason, you are highly encouraged to thoroughly test out the software using the fully functional demonstration mode that it automatically goes into when you do not install a license key, and which allows 2 simultaneous OpenVPN tunnel connections, before deciding to permanently purchase and activate a license key on your servers. If the 2 connections in the demonstration mode are not enough you can put in a request for a temporary trial key for more connections.

We're sorry but we are unable to offer refunds or assistance with recovery of assets based on personal or civil matters. For this reason, if you choose to resell license keys, you are encouraged to secure payment before purchasing the product on your own personal funds. If however the license key is still unactivated, you can simply apply for a license key refund. If it is activated, then it is considered used and not eligible for refunds.

There is currently no restriction on this, although the customer is of course easily able to see the pricing information on our website just as well as you can, so there may not be much of an advantage to reselling. We do not have a special reselling program. Anyone is welcome to purchase license keys for the OpenVPN Access Server product either for themselves or another party, as long as payment is done and the license agreement terms for purchasing a license key are agreed to.

This refers to the fixed license model which unlocks VPN connections on OpenVPN Access Server, and is a single-activation type key that ties to the software/hardware machine facts. When you need to change hardware or reinstall your OpenVPN Access Server and you use the fixed license model, then you will need your fixed license activation key replaced with a new one. You can request this from us by contacting OpenVPN Support and explaining you need a fixed license activation key reissued.

This is where we take an existing already activated fixed license activation key, and remove it from our system (revoke it) and replace it with a new fixed license activation key that can be activated on an OpenVPN Access Server installation. We call this a fixed license activation key reissue, and it is to help people move a license from one server to another, or to resolve a problem that can occur when the hardware/software combination a license key has been activated on, has been altered. For example when you reinstall your server or when you replace hardware on a server (new mainboard, new network card, that sort of thing).

If you are using license keys that you have purchased from our openvpn.net website and they have suddenly stopped functioning then check the troubleshooting page regarding OpenVPN Access Server license key issues. In short if your fixed activation license key used to work before but now suddenly doesn't, the fixed activation license key is either expired or something has altered the hardware/software significantly enough to make the licensing system believe it is now running on a different system, and the fixed license activation key is not valid for the new configuration.

We are only able to process fixed license activation key reissue requests for the keys that are not expired.

When a fixed license activation key reissue is requested, we revoke the old fixed license activation key and issue a new one. The old key will function for up to 2 weeks, giving you time to migrate your settings and test your setup if you are currently working on migrating your installation from an old server to a new server. If after that 2 week period the old key is left on the old server installation and is still functioning, you could eventually get the problem where either the old or the new key ceases to function abruptly. So ensure that at the end of that 2 week period you have either decommissioned the old server, or removed the fixed license activation key file from the file system of the old server, if you wish to keep the old server on.

We also have a subscription model that doesn't require such action. A subscription activation key can be activated multiple times and even on multiple OpenVPN Access Servers at the same time, they will simply share the subscription then. So a reinstall or move to other hardware doesn't require us to reissue the key when you use the subscription model. If you have a problem with the subscription licensing model, check the troubleshooting guide for subscription licensing.

On Amazon AWS we have the tiered instance on the AWS Marketplace, recognizable by the (xx connected devices) in the title of the offerings on the AWS Marketplace. Instances launched from these AWS Marketplace images are automatically licensed. If the EC2 instances launched from the AWS Marketplace are not licensed properly, check the troubleshooting guide for AWS tiered instance licensing.

You can split your activation key depending on the license model and specific circumstances.

You can purchase a license directly from our site or may have a license through AWS (Amazon tiered). When you buy on our site, we refer to it as the bring your own license (BYOL) model. With BYOL, you can:

  • Set up your Access Server anywhere.
  • Purchase and activate an activation key.
  • Unlock a certain number of connections.

We provide subscriptions or fixed license keys. For details about their differences, refer to our billing FAQ.

Splitting your activation key depends on whether you have a subscription or a fixed license.

For the subscription model, you can change the number of allowed connections yourself:

  1. Sign in to the Access Server portal.
  2. Click Subscriptions.
  3. Click your existing subscription.
  4. Click Edit Subscription.

You can change the number of connections anytime and purchase another subscription. For example, if you have a subscription with 50 connections that you want to split, you can edit it to a 20-connection subscription and purchase a second subscription with 30 connections.

For the fixed license key model, you can only split it under certain conditions:

  • You haven’t activated the fixed license key.
  • Your new activation keys contain a minimum of ten connections.

For example, you can split an activation key with 30 connections into three keys with ten connections each. To do this, you must contact us using the support ticket system.

We recommend switching to the subscription model to increase the number of connections for your Access Server. However, if you need to keep using a fixed license, you can activate multiple fixed license keys on the same Access Server. So, if you have ten allowed connections on a server now with a fixed activation key, you can activate another key for ten to get a total of 20 allowed connections.

That depends on what software license you have. Our software subscription license model allows you to activate on multiple Access Servers at the same time. They will share the subscription. In that situation, you only need one subscription for the Access Servers you want to license under this one subscription. If you still use the fixed license activation key model, once you activate the key on a single Access Server, it can no longer be activated on any others. Fixed license keys cannot be shared across multiple servers. You would need to purchase a separate fixed license key for each Access Server.

In the case of subscription, sharing allowed connections occurs in the following way: Each node can individually allow connections up to the full number allowed by the subscription. The total number of connected VPN clients on all Access Server nodes with the same subscription cannot exceed the allowed number. Should that occur, the subscription system will eventually lower the number of permitted VPN connections just enough to be back within limits.

To view the information about each Access Server activated with a specific subscription key, you can sign in to your account on our site. Click on the subscription name, then Access Server Information, and the servers and hostnames display. You may be able to update the hostname that displays there if you’d prefer. To do so, please refer to Subscription Model Licensing Configuration Options.

Yes.

Five connections on a software license activation key is the minimum for the BYOL licensing system. A subscription with two connections, which is equivalent to an unlicensed Access Server, is available. Higher numbers of VPN connections are offered, but the minimum is five. The software subscription license model does allow users to activate a single subscription on multiple Access Servers, so they can share the same subscription.

On Amazon AWS it is possible to use the Amazon AWS tiered instances licensing system and one of the instances we offer on the AWS Marketplace is available for 5 connections. It also comes with a 7 day free trial giving you the option to try the product out before paying software licensing costs. Please note that on Amazon AWS costs do apply for running an AWS instance. This tiered license instance for 5 connections is the smallest amount of license you can get for OpenVPN Access Server and applies only on Amazon AWS.

If you're using the Amazon AWS tiered instances instead of using separately purchased and activated license keys then check the troubleshooting page regarding Amazon AWS tiered instance software licensing. In short if this licensing model doesn't work the problem is likely caused by a security group blocking access to the licensing systems.

If you are using license keys that you have purchased from our openvpn.net website and they have suddenly stopped functioning then check the troubleshooting page regarding OpenVPN Access Server license key issues. In short if your license key used to work before but now suddenly doesn't, the license key is either expired or something has altered the hardware/software significantly enough to make the licensing system believe it is now running on a different system, and the license key is not valid for the new configuration.

Years ago, with Access Server version 1.8.4 and older, we sold what were labeled perpetual license keys. The conditions with these keys were the same as they are now with one exception; when the expiration date was reached, the license key would not disappear off the server by itself. It would instead remain activated as long as the server was not altered. When Access Server 1.8.5 was released, we have introduced a new licensing system and stopped selling these type of license keys. License keys sold now will disappear off the server when the expiration date is reached. But we still honor the old perpetual license keys under the conditions they were sold under.

If you have upgraded your older OpenVPN Access Server program to a modern version and your perpetual license key has disappeared, then downgrade your OpenVPN Access Server program back to 1.8.4 or older. That type of license key only works on the older versions of OpenVPN Access Server. If during your upgrade you didn't only upgrade the OpenVPN Access Server installation package, but instead did an installation on a new operating system or new server, or otherwise changed the hardware/software properties of the system that the license key was originally activated on, and your license key is expired, then your license key is lost and we point out the paragraph below which applied in the past just as it does now:

All license keys sold for OpenVPN Access Server are single-activation and lock to the hardware and software properties that you installed the license key on. If you want to move your license key to another installation, this is only ever possible when the license key is not expired. We only provide support on license keys if the license key is not expired. This was the case in the past, and still is the case now. So if you come to us with a request to move a license key from one Access Server to another, and the license key is expired, we cannot help you. If the license key is not expired, we will gladly help you to move the license key.

That depends on the software license model you're using.

If you do not know what type of software license you are using now, then consult the software licensing troubleshooting guide to determine this.

Software subscription licenses are monthly or yearly subscriptions for OpenVPN Access Server VPN connections. They are valid for a predetermined period and can be set to renew automatically. Renewing a subscription on our Access Server Portal will take effect immediately on any Access Server that is using that subscription. So any changes you make to the subscription, even changing the size of the subscription, takes effect immediately. If you allow a subscription to end and you do not have it set to renew, then the Access Servers using this expired subscription will eventually only allow 2 concurrent VPN connections. You will receive email notifications before a subscription needs to be renewed.

Fixed license software licenses for OpenVPN Access Server are valid for a predetermined amount of time, and require action on your part to renew. When you purchase a fixed license activation key, the choices are for a period of 1, 2, 3, 4, or 5 years. At the end of that time, when the license key reaches it end date and expires, it will disappear off your server automatically. If the last license key on your Access Server expires, it allows only 2 concurrent VPN connections. When you renew within the last month before the fixed license key is going to expire, then the Access Server has the ability to retrieve the renewal key automatically. You can also force this renewal retrieval immediately by going to the Admin UI and clicking the Get renewal keys button. If the key has already expired you'll have to go in and activate the new key yourself. You will receive email notifications before a fixed license expires.

Amazon AWS tiered instances have no end date for the license. They are licensed as long as the Access Server is up and running on Amazon AWS. The billing for the software license is hourly and can be changed to annual so that you get a discount. For information on that we recommend you read the pricing information carefully on the AWS Marketplace offerings for OpenVPN Access Server with a specific allowed amount of connections. Software license billing for such an Amazon AWS instance only stops when the instance is in 'stopped' state, or 'terminated'.  This is billed directly through Amazon AWS.

Perpetual type license keys which were sold in the past will still continue to function on the original hardware and software they were activated on, as per the conditions for the perpetual license keys.

On Amazon AWS we offer tiered instances that should be billed and licensed through Amazon AWS directly. These are recognizable from the (xx connected devices) in the title of the offering on the Amazon AWS Marketplace. These should be automatically licensed within seconds after startup of Access Server. If it doesn't get licensed automatically, then it falls back to an unlicensed state where only 2 connections are allowed.

The most likely problem is that contact with the software licensing server was not possible. Make sure that the server can reach awspc1.openvpn.net on port TCP 443. There are also backup licensing servers available (awspc2.openvpn.net, awspc3.openvpn.net, awspc4.openvpn.net). Most commonly the issue is that people launch the AWS Marketplace OpenVPN Access Server offering while specifying custom security groups settings that block this access, or set up such security group settings afterwards and block this access.

More information on IP addresses and ports of our licensing servers for Amazon AWS is available in the troubleshooting guide for OpenVPN Access Server AWS tiered instance licensing.

When OpenVPN Access Server is used without any software license at all, it will automatically allow 2 connections. This allows to try out the product for free.

On our Access Server portal, we also offer the ability to generate subscription keys with 2 connections allowed for free. The advantage of using and activating this is that you can then manage the amount of allowed connections on a subscribed OpenVPN Access Server simply by changing the subscription from our Access Server portal.

That depends on the software licensing method used. If you do not know which software licensing method your Access Server is using now, you can consult our software licensing troubleshooting guide to determine this.

We have a subscription licensing model that can be managed from our website. If you have a subscription for OpenVPN Access Server, you can go to our website, find your subscription, and change the number of connections. You will either pay extra for additional connections, or be credited some amount if you lower the number of connections on your subscription. This model is the most flexible and easiest to work with. It can be activated on a single or on multiple Access Servers, is perfect for automated deployments, LAN model failover, and clustering setups. You can easily adjust the number of allowed connections from our website portal at any time.

We also offer OpenVPN Access Server on Amazon AWS on the AWS Marketplace as tiered instances. These are billed directly through Amazon AWS and you can recognize these on the AWS Marketplace because they have (xx connected devices) in the title of the offering on the AWS Marketplace. The number of allowed VPN connections on these instances can't be adjusted. This is due to a limitation in how licensing is implemented and billed directly through Amazon AWS systems. The only way to change the number of allowed VPN connections on a tiered AWS instance is to switch to a newly launched instance in a different tier or of the BYOL type that allows you to use a software subscription license as described above. On Amazon AWS that means doing a launch of a new instance. In almost all cases it is possible to migrate your OpenVPN Access Server data so that already installed VPN clients do not need to be reinstalled or adjusted. It is important to note that you should try to associate the Elastic IP from the old instance to the new one, or if you were using a DNS host name for the VPN connections, to update that DNS record to point to the new IP of the new Access Server instance.

We also offer the fixed license activation key method. With this option the number of VPN connections allowed on a license key is fixed and cannot be changed. However, you can add multiple fixed license activation keys on the same Access Server, so if you have a fixed license activated on your Access Server for 10 connections, you can add another one for 20 connections, to make a total of 30.

Depends on the choices you make on where to deploy, how many simultaneous connections you need, for how long you want to purchase the software license.

You can find information on the software license pricing for OpenVPN Access Server on our software license pricing page.

You may notice different wording and terminology used in documentation and on the website. In this section our goal is to provide clarification. The most critical element of our subscription licensing system is the number of active VPN tunnels because that’s what enables various scenarios. For example, you can configure one user account on your OpenVPN Access Server and set it up so that with that same user name and password you can establish a VPN connection from multiple different devices at the same time. You can set up an account called "andrew", set a password for it, then use that same account on an iPad, a Windows computer, and two Macintosh computers — all at the same time. In that scenario, if all devices are connected at the same time, you're using 3 connections on the license. If your subscription is for 5, then that leaves 2 connections available.

It also works the other way around. You can have 500 user accounts on your OpenVPN Access Server but only license it for 100 connections, and if 25 of those 500 users are connected then you can still connect 75 VPN tunnels with any of the 500 accounts. So in other words, the subscription licensing system does not look at how many user accounts you have, but how many VPN tunnel are connected at the same time. So if you have 500 user accounts but you anticipate that only about 90 of them will ever be online at the same time, then a subscription for 100 VPN connections is perfectly fine.

And if for example you have 10 VPN tunnel connections active on a server that is on a subscription for 10 connections, then anyone trying to establish the 11th connection will be denied access and receive a message that the licensed amount has been exceeded. When one of the currently connected tunnels is stopped, then that opens up 1 license and the user can then log in.

A subscription can be activated on multiple Access Server at the same time. This allows for automatic sharing of the subscription across multiple Access Servers. The way this works is that as long as the total number of VPN connections on all Access Servers using the same subscription stays at or below the number of allowed VPN connections on the subscription, then all servers will be allowed to connect the maximum number of connections. Only when you go over, does the subscription system start forcing the Access Servers to kick some users off to stay within the limits.

To give an example, if you have a subscription for 100 connections, and Access Servers A and B are both using that same subscription, then each server will be allowed to connect 100 connections each. This is done to allow a situation where you might want 99 connections on server A and 1 connection on server B, just to give an example. It is only when the total number of the connections on both servers added up go over 100, that users will start to be kicked off. For example if you have 30 users on Access Server A, and 71 users on Access Server B, then you have 101 connections, which exceeds 100 connections allowed on your subscription. Then 1 user will be kicked off, and that will most likely be the user that last connected. At such a point, the number of allowed connections on Access Server B might be lowered to 70, forcing the 71st connection to be kicked off. Once you are at or below the limit again, the subscription licensing system 'resets' and tells both servers the maximum number of connections are allowed again.

Yes, there are multiple ways of trying Access Server without paying for a software license.

The OpenVPN Access Server can be downloaded from our website and installed on any compatible Linux operating system, and during installation you may be asked for an activation key, but if you do not provide one, it will allow 2 simultaneous VPN connections. All functionality is available and there is no time limit. However, you are limited to only 2 simultaneous active VPN tunnels to the Access Server. This allows for testing all the functions of the Access Server without having to pay for a software license. So if you want to try out the Access Server, install Access Server on your Linux OS or choose any of the other available Access Server deployment options and you can start testing. Upon request we will also grant a free temporary trial subscription license for a larger number of connections if you require this for your testing purposes.

OpenVPN Access Server is also available on Amazon AWS as a ready-to-deploy system from the AWS Marketplace in 3 different types:

  1. One type is the BYOL licensing type OpenVPN Access Server instance which is known on the AWS Marketplace simply as "OpenVPN Access Server", and functions as described above when you do not provide an activation key. With the BYOL type no software licensing costs are added on Amazon AWS but you only pay for the Amazon AWS costs for the running instance.
  2. Another type are the Amazon AWS OpenVPN Access Server tiered instance licensing type instances which aside from Amazon AWS costs for running an instance also have licensing software costs which are shown on the right hand side on the AWS Marketplace when you click on a tiered instance on the AWS Marketplace. These are billed through Amazon AWS directly.
  3. The third type is the OpenVPN Access Server for 5 connected devices. This one is different from the others because it comes with a 7 day free trial for the licensing costs. This means that for the first 7 days of running this instance type you pay only the Amazon AWS costs for having the instance up and running, but no software licensing costs are added. If after 7 days you continue using the instance, software licensing costs are added.

Amazon AWS in most cases charges for the use of running an instance on their systems, and this is separate from any software licensing costs, so please be aware of this and understand that that component of the costs you pay on Amazon AWS, or for that matter any cloud provider, are not caused or billed by us. It's also important to note that if you launch a tiered instance of OpenVPN Access Server that is licensed for a number of connected devices, and leave it running even if you're not using it, will mean you are still incurring costs on Amazon AWS.

On Amazon AWS Marketplace you can look for "OpenVPN Access Server". You'll see a number of results. Most of these include (xx connected devices) in the title. This indicates an image automatically licensed for the specified amount of connections when you launch it from the AWS Marketplace. This gets billed through Amazon directly. The costs are separated into software licensing costs and AWS instance costs, billed hourly. If you launch an OpenVPN Access Server (xx connected devices) type instance on Amazon AWS you 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 stop incurring additional costs for the software licensing and running the instance. Some charges may apply for simply having the instance, like storage costs, but those are typically minimal. You could use such a system on demand if you wanted have an instance on cold standby ready to be launched when needed.

The OpenVPN Access Server for 5 connected devices comes with a temporary free trial. That means that when you launch it, for the first seven days, there isn't a software licensing cost billed to you. This allows you to test it out with five connections. You still pay for the infrastructure costs of running an EC2 instance on Amazon AWS, although you might be able to make use of the free trial options that Amazon AWS offers as well. If you're still running this instance after seven days, then the software license billing starts. Day eight will then be day one in terms of software license billing.

We also have an offering on the AWS Marketplace with no connected devices specified. This is our bring your own license (BYOL) image. This Marketplace image allows two concurrent connections when launched. To increase your connections, purchase an activation key from our website. This activation key gets billed by OpenVPN Inc. directly and doesn't get billed through Amazon AWS. The infrastructure costs for running an EC2 instance on Amazon AWS still applies and gets billed by Amazon itself.

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.

With a license for the OpenVPN Access Server program you can unlock a certain amount of simultaneous VPN tunnel connections to your OpenVPN Access Server installation. You also get access to our professional support via the support ticket system. You are expected to provide your own server with the OpenVPN Access Server program installed on it, or to hire a server or a cloud based virtual system like Amazon AWS or such with the OpenVPN Access Server program installed on it.

If your Access Server is not licensed, it will only function in a sort of demonstration mode where only 2 simultaneous VPN connections are allowed. To allow more, a license is required.

Please also note that having a license does not mean you can connect to one of our servers. A license key is meant for an OpenVPN Access Server installation on a server you provide and manage. Purchasing and having a license key does not mean that you can connect to openvpn.net with your OpenVPN client program. That is not a service we offer on openvpn.net. However if you are looking for a VPN termination service where you can connect your computer to an already existing VPN server for the purposes of securing your Internet traffic, take a look at our offering called Private Tunnel instead. But if you want to set up your own OpenVPN server based on our OpenVPN Access Server product, and need more than 2 simultaneous connections, then purchasing a license for OpenVPN Access Server is the way to go.

We understand that customers may need to comply with their accounting departments when making purchases—this may require submitting a Purchase Order to OpenVPN for purposes of purchasing or renewing software licensing. We're happy to facilitate POs. Here's how it works:

Let us know if you require a quote at sales@openvpn.net

Email a copy of the completed purchase order to sales@openvpn.net

Once we've received the Purchase Order, we'll email an invoice to your AP dept. email or whomever handles your Accounts Payables. Your software licenses will be added or renewed when we receive your Purchase Order.

Please be sure to pay the invoice / 30 net terms.

OpenVPN TAX ID / W9

If you need W9, please click here to download. 
Note: Please right click "click here" and choose "Target save as..." to download W9 or click it to open directly

The OpenVPN open source project is free to use if you keep to the software license agreement, but the commercial OpenVPN Access Server product sold by OpenVPN Inc. is not free. There are some vast differences between the two programs, and while Access Server does use at its core the OpenVPN open source program, it is much more than just that program.

error parsing certificate : X509 - The date tag or value is invalid
This is not a bug in OpenVPN but is because of a faulty certificate. See this detailed forum post for more info.

certificate verification failed : x509 - certificate verification failed, e.g. crl, ca or signature check failed
This is an error that tells you that the certificate could not be verified properly. This can occur for example if you are using an MD5 signed certificate. With such a type of certificate, the security level is so low, that the authenticity of the certificate simply cannot by any reasonable means be assured. In other words, it could very well be a fake certificate. The solution is to use a certificate not signed with MD5, but with SHA256 or better. You can find more information in the MD5 signature algorithm support section.

digest_error: NONE: not usable
This can occur if you specify auth none and also tls-auth in your client profile. This occurs because tls-auth needs an auth digest, but none was specified. There's a straightforward fix: just remove the tls-auth directive, since it can't be enabled anyway unless you have anything other but 'none' in the auth directive.

SSL - Processing of the ServerKeyExchange handshake message failed
There's a good chance this may be related to using older versions of OpenVPN/OpenSSL on the server side. Some users have solved this issue by updating their OpenVPN and/or OpenSSL software on the server side.

BIO read tls_read_plaintext error: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
This is usually remedied by going to the OpenVPN Preferences menu and selecting "Force AES-CBC ciphersuites".

There are more general OpenVPN client connectivity error messages and solutions available.

Use the steps here to configure Tasker for use with the OpenVPN Connect app for Android 3.3.2 and newer.

Note: The Profile_ID mentioned in the Connect Action below is defined during the import process — it doesn't change even if you change the name of your profile after the import procedure has concluded.

Tasker can launch VPN connections autonomously when a profile doesn't require additional authorization steps or the user has previously saved connectivity credentials for the profile in Connect. Otherwise, the user is prompted to authenticate manually.

Tasker can control the following Actions:

  • Connect VPN (with specified profile).
  • Disconnect VPN.

Follow the steps below to set up Tasker for each Action above.

Connect VPN

Step 1:

  1. Open OpenVPN Connect.
  2. Tap the Edit icon for the preferred profile.
  3. Find the Profile ID at the bottom of the screen and tap the copy to clipboard icon.

Step 2:

  1. Open Tasker.
  2. Create an Action with the following parameters:
    Action: net.openvpn.openvpn.CONNECT
    Extra: net.openvpn.openvpn.AUTOSTART_PROFILE_ID:'{your_profile_id}'
    Extra: net.openvpn.openvpn.AUTOCONNECT:true
    Package: net.openvpn.openvpn
    Class: net.openvpn.unified.MainActivity
    Target: Activity

Disconnect VPN

Step 1:

  1. Open Tasker.
  2. Create an Action with the following parameters:
    Action: net.openvpn.openvpn.DISCONNECT
    Cat: None
    Mime Type: {blank}
    Data: {blank}
    Extra: net.openvpn.openvpn.STOP:true
    Extra: {blank}
    Extra: {blank}
    Package: net.openvpn.openvpn
    Class: net.openvpn.unified.MainActivity
    Target: Activity

You can provide OpenVPN with a list of servers to connect to. On connection failure, OpenVPN will rotate through the list until it finds a responsive server. For example, the following entries in the profile will first try to connect to server A via UDP port 1194, then TCP port 443, then repeat the process with server B. OpenVPN will continue to retry until it successfully connects or hits the Connection Timeout, which can be configured in the Preferences.

remote server-a.example.tld 1194 udp
remote server-a.example.tld 443 tcp
remote server-b.example.tld 1194 udp
remote server-b.example.tld 443 tcp

PKCS#12 files on Android are used somewhat differently than on desktop versions of OpenVPN. In desktop versions, PKCS#12 files can be bundled or referenced in the OpenVPN profile. On Android, however, PKCS#12 management is built into the Android Keychain. This approach is much better from a security perspective, because the Keychain can then leverage on hardware features in the device such as hardware-backed keystores. However, it does require that the PKCS#12 file is loaded into the Android Keychain as a separate step from importing the OpenVPN profile. It also moves the responsibility for managing PKCS#12 files to the Android Keychain, and away from OpenVPN, so it can potentially introduce compatibility issues.

To use a PKCS#12 file on Android, see the FAQ item above: How do I use a client certificate and private key from the Android Keychain?

A: Using the Android keychain to store your private key has the added security advantage of leveraging on the hardware-backed keystores that exist on many Android devices, allowing the key to be protected by the Android-level device password, and preventing key compromise even if the device is rooted.

If you already have your client certificate and private key bundled into a PKCS#12 file (extension .p12 or .pfx), you can import it into the Android Keychain using either the Import menu or the Settings app.

If you don't have a PKCS#12 file, you can convert your certificate and key files into PKCS#12 form using this openssl command (where certkey, and ca are your client certificate, client key, and root CA files).

openssl pkcs12 -export -in cert -inkey key -certfile ca -name MyClient -out client.p12

Then import the client.p12 file from the previous step into the app using the Import / Import PKCS#12 menu option.

Once this is done, remove the cacert, and key directives from your .ovpn file and re-import it. When you connect the first time, the app will ask you to select a certificate to use for the profile. Just select the MyClient certificate and you should be able to connect normally.

Doing a "long touch" on the proxy field will bring up a context menu for that proxy that includes edit, delete, etc.

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.

Doing a "long touch" on the profile field will bring up a context menu for that profile that includes delete, rename, etc.

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.

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 Android VPN API supports only TUN-style or routed tunnels on Layer 3 at the moment. TAP-style or bridged tunnels on Layer 2 are not possible on Android. This is a limitation of the Android platform. If you try to connect a profile that uses a TAP-based tunnel, you will get an error that says only Layer 3 tunnels are currently supported.

If you really want to see TAP-style tunnels supported in OpenVPN Connect, we would encourage you to contact the Google Android team and ask that the VpnService API be extended to allow this. Without such changes to the VpnService API, it is not possible for non-root apps such as OpenVPN Connect to support TAP-style tunnels. Currently we have very little demand for this feature because Layer 3 is for a number of reasons the better choice anyways.

If you want to use an OpenVPN connection profile in OpenVPN Connect that connects to a server without a client certificate/key, you will need to add the following directive to your profile:

setenv CLIENT_CERT 0

This is necessary because the OpenVPN3 client library used in OpenVPN Connect assumes that a client and server certificate are used for verifying the identity of the client and the server in both directions. The client needs to be told not to expect a client key/certificate, because otherwise the client app can't know whether an external certificate/key pair should be obtained from the system certificate store, or whether the server actually doesn't require a client certificate/key (for example if the server is configured with the client-cert-not-required directive). The option is given as a "setenv" to avoid breaking other OpenVPN clients that might not recognize it.

The save password switch on the authentication password field is normally enabled, but can be disabled by the following:

  • The following OpenVPN directive, if present in a profile, will disable the password save switch:
setenv ALLOW_PASSWORD_SAVE 0

Note however that the above directive only applies to the authentication password. The private key password, if it exists, can always be saved.

Yes, it is safe using OpenVPN Connect 3.x. OpenVPN Connect on every platform (Android, iOS, macOS and Windows) stores passwords and external certificates in a safe system repository: Android Keychain, iOS/macOS Keychain and Windows Credential Vault. This approach protects saved sensitive information taking advantage of operation system security tools.

  • The most sensitive piece of data in a profile is the private key. Consider removing the client certificate and private key from the profile and save them in the device Keychain instead (this is discussed below).
  • Use a strong device-level password. This is critical to protect data stored in the device Keychain.

Some cellular networks are incapable of maintaining a data connection during a voice call. If Android detects this as a loss of network connectivity, the VPN should enter a pause state during the duration of the call, and automatically resume after the call is complete. However if the loss of data connectivity isn't detected by Android, the VPN connection may time out and disconnect.

In the Preferences menu, select the Reconnect on reboot option. Also, consider setting the Connection Timeout preference to "continuously retry". If you want to prevent apps from accessing the internet, except through the VPN, select the Seamless Tunnel preference.

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

Consider selecting the Battery Saver option in the Preferences menu to Pause the VPN when the device screen is blanked. This will cause the VPN to disconnect when the screen is blanked and automatically reconnect when the screen becomes visible again. While this option can extend battery life, it should not be used if you have apps running in the background that require continuous access to the internet via the VPN (such as a new email notifier).

Note that if you select both the Battery Saver and Seamless Tunnel options, you will block any app from reaching the internet while the VPN is active but the device screen is blanked. This can be useful for additional energy savings, as long as you don't have any background apps that need constant internet access.

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.

This is something Android requires to affirm that the VPN session is high priority and should not be arbitrarily terminated by the system.

Yes. The OpenVPN app supports IPv6 transport and IPv6 tunnels as long as the server supports them as well.

Here are some basic pointers for importing .ovpn files:

  • When you import a .ovpn file, make sure that all files referenced by the .ovpn file such as cacert, and key files are in the same directory on the device as the .ovpn file.
  • Profiles must be UTF-8 (or ASCII) and under 256 KB in size.
  • Consider using the unified format for OpenVPN profiles which allows all certs and keys to be embedded into the .ovpn file. This eases management of the OpenVPN configuration because it integrates all elements of the configuration into a single file.For example, a traditional OpenVPN profile might specify certs and keys as follows:
    ca ca.crt
    cert client.crt
    key client.key
    tls-auth ta.key 1
    

    You can convert this usage to unified form by pasting the content of the certificate and key files directly into the OpenVPN profile as follows using an XML-like syntax:

    <ca>
    -----BEGIN CERTIFICATE-----
    MIIBszCCARygAwIBAgIE...
    . . .
    /NygscQs1bxBSZ0X3KRk...
    Lq9iNBNgWg==
    -----END CERTIFICATE-----
    </ca>
    
    <cert>
    -----BEGIN CERTIFICATE-----
    . . .
    </cert>
    
    <key>
    -----BEGIN RSA PRIVATE KEY-----
    . . .
    </key>
    
    key-direction 1
    <tls-auth>
    -----BEGIN OpenVPN Static key V1-----
    . . .
    </tls-auth>
    

    Another approach to eliminate certificates and keys from the OpenVPN profile is to use the Android Keychain as described below.

    NOTE: when converting tls-auth to unified format, check if there is a second parameter after the filename (usually a 0 or 1). This parameter is known as the key-direction parameter and must be specified as a standalone directive when tls-auth is converted to unified format. For example if the parameter is 1, add this line to the profile:

    key-direction 1

    If there is no second parameter to tls-auth, you must add this line to the profile:

    key-direction bidirectional

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.

No, all versions of OpenVPN Connect for Android use the mbedTLS library, which is immune to Heartbleed.

It has been known for a very long time (since 2005 or so) that using MD5 as an algorithm for signing a certificate is a bad idea. It has been shown that with, at the time standard home computer equipment, it took about 8 hours to falsify a certificate signed this way, and as such the identity of the server could be faked. This could lead to an MiTM attack which could lead to interception of traffic. Therefore, MD5 support has been around only to allow connections to older equipment. We discovered that when we tried to cut support in November of 2017 during a security and functionality upgrade of OpenVPN Connect for Android that a lot of people were still using devices that use MD5 signed certificates. This is extremely insecure. It is recommended that any installations that still use MD5 signed certificates are converted to a setup with SHA256 signed certificates, or better. If the device you are using does not offer you the option to do so, then you should try updating the device to add this function if possible, or replace the device with a solution that does support it.

We have therefore decided to implement a transitional period in which we will still allow MD5 signed certificates to function, until May 2018, when we will start cutting support for MD5 out of OpenVPN entirely. You should plan accordingly. We have a list of deprecated options and ciphers here: https://community.openvpn.net/openvpn/wiki/DeprecatedOptions

To learn why MD5 signatures are bad, see these articles:

To determine if you are using an MD5 type certificate now using openssl as testing tool:

openssl x509 -in ca.crt -noout -text | grep "Signature Algorithm"

Example result if certificate is using MD5:

Signature Algorithm: md5WithRSAEncryption

If you see this result on the CA certificate or client certificate, then you must convert to a new and properly secure signed certificate set that uses at least SHA256 or better. For our OpenVPN Access Server users, it is good to know that we do not use MD5 certificate signatures at all in Access Server. For open source OpenVPN users, or users that have a third-party device that includes OpenVPN functionality, and you discover you have MD5 type certificates, you should investigate the option to update the software on your device, or to change the signature algorithm type, if possible. If it is not possible, you could try contacting the manufacturer of your device to see if they still support your device, and if they can create a means by which to replace the certificates with a properly secure type certificate.

The default settings of a program like EasyRSA 3, which is used by open source OpenVPN for generating client certificates and keys, are pretty secure and will generate certificate that are not signed with MD5.

OpenVPN Connect 1.0.6 and higher installs the openvpn:// URL scheme and can be detected with the following code:

BOOL installed = [application canOpenURL:[NSURL URLWithString:@"openvpn://"]];

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

UI Settings

  • Raise Keyboard — When ON, the app will try to raise the iOS soft keyboard whenever an input field is selected.

Connection Settings

  • Seamless tunnel (requires iOS 8 or higher) — Make a best-effort to keep the tunnel active during pause, resume, and reconnect states. Typically, during VPN pause, resume, or reconnect (for example when transitioning between WiFi and Cellular data), the VPN tunnel may disengage for a short period of time, normally on the order of seconds or less. During this time, network traffic can potentially bypass the tunnel and route directly to the internet. This option can reduce the incidence of packet leakage by keeping the tunnel continuously engaged until it is manually disconnected, even across sleep/wakeup or network reconfiguration events. Consider also enabling the Layer 2 reachability setting (below) when using Seamless Tunnel.
  • Connect via — Connect to the VPN server by WiFi, Cellular Data, or either.
  • Reconnect on wakeup — Automatically reconnect a VPN profile if it was active prior to device sleep.
  • Protocol — Force a particular transport protocol (UDP or TCP).
  • Compression — Select tunnel compression options.
  • Connection timeout — How long should OpenVPN try to connect before giving up? If set to None, OpenVPN will retry indefinitely.
  • Network state detection — How should OpenVPN handle network state changes or network reconfiguration events where the network comes up, goes down, or transitions between WiFi and Cellular data?
    • Active (default) : When connected, always attempt to reconnect after network reconfiguration events.
    • Lazy : When connected, attempt to preserve existing connection during network reconfiguration events.
    • Disabled : Don't consider network state when initially connecting, and don't use network state changes to trigger pause/reconnect/disconnect behaviour.

Advanced Settings

  • Force AES-CBC ciphersuites — When ON, the connection MUST use one of the following two ciphersuites:
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA, or
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA

    When OFF, no specific ciphersuites are forced.

  • Minimum TLS version — Set the minimum TLS version. If a specific TLS version is selected it will override any profile setting. If Profile Default is selected, the app will use the tls-version-min profile directive if it exists, or TLS 1.0 otherwise. If Disabled is selected AND Force AES-CBC ciphersuites (above) is enabled, the app will NOT require a minimum TLS version from the server, which means that the SSL version negotiated could be as low as SSL 3.
  • Google DNS fallback — If ON, use Google DNS servers (8.8.8.8 and 8.8.4.4) as a fallback for connections that route all internet traffic through the VPN tunnel but don't define any VPN DNS servers.
  • Layer 2 reachability — If ON, and if Seamless Tunnel (above) is also ON, use a more robust test of network reachability when transitioning between WiFi and Cellular networks.

Proxy Settings and Credentials

  • Enable Proxy — When ON, connect to the VPN server via an HTTP proxy.
  • Host — HTTP proxy hostname or IP address.
  • Port — HTTP proxy port number.
  • Allow Basic auth — If ON, allow authentication methods that transmit the proxy password in cleartext.
  • Username — HTTP proxy username. OpenVPN supports NTLMv2, Digest, and Basic authentication.
  • Password — HTTP proxy password.

When trying to resolve a PQDN (Partly Qualified Domain Name), the iOS DNS subsystem first tries to solve the hostname as provided and, in case of failure, concatenates it with the system domain prefix (normally assigned by your uplink gateway, for example: ".lan"). In order to specify a different domain to append, the server can push a special directive including the new name:

push "dhcp-option ADAPTER_DOMAIN_PREFIX foo.tld"

Note that this can work only when redirect-gateway or a VPN specific DNS has been configured. See the previous FAQ "How does iOS interpret pushed DNS servers and search domains?" to learn how to specify a DNS.

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"

On a split-tunnel, where redirect-gateway is not pushed by the server, and at least one pushed DNS server is present:

  • route all DNS requests through pushed DNS server(s) if no added search domains.
  • route DNS requests for added search domains only, if at least one added search domain.

For example, the following directive on the server will tell the client to route all DNS requests to 172.16.0.23:

push "dhcp-option DNS 172.16.0.23"

while these directives on the server will only route foo.tld and bar.tld DNS requests to 172.16.0.23:

push "dhcp-option DNS 172.16.0.23"
push "dhcp-option DOMAIN foo.tld"
push "dhcp-option DOMAIN bar.tld"

Note that with redirect-gateway, the above discussion is moot, since all DNS requests are always routed through the VPN regardless of the presence or absence of added search domains.

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.

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?

When you import a PKCS#12 a password must always be specified. If you have set an empty password, just tap OK without entering any text.

Starting with 1.2.6 PKCS#12 files are now imported in the iOS keychain as OpenVPN Connect specific key material. For this reason they are not visible in the iOS Settings.

To delete an imported PKCS#12 file touch Manage Certificates (or Certs on iPhones/iPods) at the top of the main app screen and then touch Delete. This will cause red "-" icons to appear to the left of all PKCS#12 files. Touch the "-" icon to actually delete a file.

Using the iOS keychain to store your private key has the added security advantage of leveraging on the hardware-backed keystores that exist on many iOS devices, allowing the key to be protected by the iOS-level device password, and preventing key compromise even if the device is rooted.

If you already have your client certificate and private key bundled into a PKCS#12 file (extension .p12 or .pfx), you can import it into the app private section of the iOS Keychain using Mail, Safari or iTunes. Note sure that the file extension has to be changed to .ovpn12 for the file to be picked up by the OpenVPN Connect App (and not by iOS).

Note that on iOS, when you import a PKCS#12 file into the Keychain, only the client certificate and private key are imported. The CA (certificate authority) certificates are NOT imported (unless you manually extract the CA certificates and import them separately, one-at-a-time). Therefore, the CA list must be given in the profile using the ca directive. If you already have a PKCS#12 file, the CA list may be extracted from the file using this openssl command, where the CA certs in client.p12 are written to ca.crt:

openssl pkcs12 -in client.p12 -cacerts -nokeys -out ca.crt

Then add a reference to ca.crt to your profile:

ca ca.crt

or paste the contents of ca.crt directly into your profile:

<ca>
paste contents of ca.crt here
</ca>

If you don't have a PKCS#12 file, you can convert your certificate and key files into PKCS#12 form using this opensslcommand (where certkey, and ca are your client certificate, client key, and root CA files).

openssl pkcs12 -export -in cert -inkey key -certfile ca -name MyClient -out client.ovpn12

Then import the client.ovpn12 file from the previous step into the app using Mail or Safari.

Once this is done, remove the cert and key directives from your .ovpn file and re-import it, making sure that the cadirective remains. Once imported, any profile that lacks cert and key directives will cause a Certificate row to appear on the main view, allowing the profile to be linked with an Identity from the iOS Keychain (on iOS, an Identity refers to a certificate/private-key pair that was previously imported using a PKCS#12 file). Touch the Certificate row and select the MyClient certificate. At this point, you should be able to connect normally.

Note that the iOS Keychain is accessible by the app only after the user has unlocked the device at least once after restart. For this reason a profile requiring a certificate stored in the Keychain to connect won't be able to do so automatically after restart.
This is a security measure to prevent an unknown person to access a VPN network using a device that was previously switched off.

Go to the Settings App and select OpenVPN in the left pane. All proxy options are available here. Proxy options can also be specified in the OpenVPN profile itself using the http-proxy and http-proxy-option directives.

Touch the Profile row to bring up the Select Profile page, then select the profile you wish to rename by touching it. Touch the Rename link in the upper-right corner. This will cause the profile name to become editable. Pressing "Done" on the soft keyboard will save the change.

Touch the Profile row to bring up the Select Profile page. Touch the Delete link in the upper-right corner. This will cause red "-" icons to appear to the left of all profiles. Touch the "-" icon to actually delete a profile.

Yes, but with some important exceptions:

  • Many Apple services such as Push Notifications and FaceTime are never routed through the VPN tunnel, as per Apple policy.
  • During pause, resume, and reconnect states (for example when transitioning between WiFi and Cellular data), the VPN tunnel may temporarily disengage, allowing network traffic to bypass the tunnel and route directly to the internet. If you are running iOS 8 or higher, consider enabling the Seamless Tunnel Setting in the OpenVPN section of the Settings App. It will make a best-effort to keep the tunnel active during pause, resume, and reconnect states to prevent packet leakage to the internet.

The iOS VPN API supports only tun-style tunnels at the moment. This is a limitation of the iOS platform. If you try to connect a profile that uses a tap-based tunnel, you will get an error that only layer 3 tunnels are currently supported.

There is a known issue where IPv6 tunnel routes may not be added to the routing table on iOS 7.0.x. This issue was fixed in iOS 7.1 Workaround: use redirect-gateway instead of pushing specific IPv6 routes. For example, in the server configuration file:

push "redirect-gateway ipv6"

Or the client configuration file:

redirect-gateway ipv6

Note that iOS 7 and higher requires that if redirect-gateway is used, that it is used for both IPv4 and IPv6 as the above directive accomplishes.

In 1.0.1, the default value for the key-direction directive was changed to "bidirectional" for compatibility with the OpenVPN 2.x branch (in 1.0.0, the default was "1"). In general, profiles imported before upgrading should continue to work, because the previous default is retained for such profiles, however if you are importing a new profile in unified format, be sure to follow the updated FAQ entry above for setting the key-direction directive.

Also note that for iOS VPN-on-Demand profiles, it is necessary to specify the key-direction as a key-value setting, if it is "0" or "1". This could potentially cause breakage in VPN-on-Demand profiles previously imported with 1.0.0 if they don't declare a key-direction key/value pair on the assumption that it defaults to "1". The solution is to explicitly declare key-direction in VPN-on-Demand profiles if the OpenVPN configuration file they are derived from declares it as well.

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

No, all versions of OpenVPN Connect for iOS use the mbedTLS library, which is immune to Heartbleed.

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.

This can occur if you specify auth none and also tls-auth in your client profile. This occurs because tls-auth needs an auth digest, but none was specified. There's a straightforward fix: just remove the tls-auth directive, since it can't be enabled anyway unless you have a non-none auth directive.

This is usually remedied by going to the OpenVPN section of the iOS Settings app and selecting "Force AES-CBC ciphersuites".
Another reason why this may happen is that you are using EC (Ecliptic Cryptography) certificates. OpenVPN Connect does not support the ECDSA algorithm at the moment, therefore those kind of certificates can't be used.

This may be related to using older versions of OpenVPN/OpenSSL on the server side. Some users have solved this issue by updating their OpenVPN server-side software and/or OpenSSL.

This is not a bug in OpenVPN or mbedTLS but is actually caused by incorrectly formatted certificates. See this detailed forum post for more info.

From version 1.1.1 the format check has been relaxed to accept also those certificates that were previously rejected with this error.

The vanishing settings appear to be a known iOS issue.

A suggested workaround is to "quit Settings by double-tapping the home button, and then dragging Settings out of the list of apps. The next time you launch Settings, your app's settings ought to show up."

Yes, you can connect simultaneously to multiple OpenVPN servers using open-source-based Windows, macOS, or Linux clients. You can’t on Android or iOS clients where the API only allows one connection. You can’t on OpenVPN Connect, our VPN client, as we deliberately limited it to one connection.

While OpenVPN Connect only allows one active VPN connection at a time, you can import multiple connection profiles and switch between them. You’re limited to one active server connection at a time. This is done intentionally. Connecting to multiple VPN servers with conflicting routes causes routing conflicts and unintended traffic paths that may cause failures or security issues. We don’t expect the average end-user to have the necessary knowledge to deal with the security and functional implications of running multiple simultaneous VPN connections that can interfere with each other.

If you’re a power user or system administrator managing multiple networks, you may need to connect to multiple VPN servers simultaneously. In that case, use an OpenVPN open-source-based client software that supports this use case. Client apps such as OpenVPN GUI for Windows, Tunnelblick for macOS, or the OpenVPN Linux client, all support connecting to multiple servers simultaneously. You need to know how to avoid or deal with routing conflicts, unintended traffic paths, or possible security implications that can arise from doing this.

If you currently have an OpenVPN deployment where your end-users are expected to connect to multiple VPN servers at the same time, consider implementing one central VPN solution, such as an OpenVPN Access Server or OpenVPN Cloud setup with site-to-site connections to all the various resources they need to access. This way, a single VPN connection gives access to all needed resources.

On older versions of OpenVPN, where IPv6 transport through the VPN tunnel was not supported, but the VPN client did have the IPv6 protocol enabled on the VPN tunnel adapter, and was attempting to send IPv6 traffic through the OpenVPN tunnel, this error could show up. If you do not need IPv6 you can either ignore this message safely, or disable the IPv6 protocol on the virtual network adapter. Alternatively you can update your software to a more recent version, server and client side, to resolve this problem.

We Are Here To Help

For additional assistance, submit a support ticket. Simply create a free account, or log in if you already have one, and let us know how we can help. Our experienced support team is standing by to assist you.

Support