Currently there are two different licensing models available. There is the BYOL or "Bring Your Own License" licensing model, and the Amazon AWS tiered instances licensing model. These are explained below.

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.

In order to transfer licenses from one system configuration to another, your license keys must have an active support/upgrade period. This period is listed under your license area on our website. Then, prior to your system reconfiguration, submit a ticket on our ticketing system requesting that your old license key to be deactivated and a new one be reissued to you. You will have approximately 1 week to complete the system reconfiguration before the old license key will stop working on your system. For license keys outside of their support/upgrade periods, new license keys will have to be purchased for such reconfigurations, as you are no longer entitled to our license replacement program.

No, because load balanced servers allow more concurrent users to be connected at the same time, each load balanced server is licensed individually. For example, if you want each load balanced server in your pool to handle 25 concurrent connections, and you have 4 of these servers in the pool, then you would need 4 x 25 = 100 concurrent licenses total.

No, a failover license key is issued free of charge upon request for users using our integrated failover functionality. Third party failover solutions are not covered under this provision and license keys will have to be purchased on our website to cover these solutions. To request a failover license key, please submit a ticket on our ticketing system (note that existing keys cannot be applied to failover servers.)

OpenVPN Access Server is a piece of software that you install on your own server, which then provides VPN services to your clients. The licenses you have bought are designed to lift the restrictions on the concurrent connection counts for users connecting to your server. If you do not already own a server in which you can install Access Server on, the licenses themselves will not grant you access to any VPN services. If this was not your intention, and you have not yet activated the licenses you have bought, please submit a refund request on our ticketing system, and look at our Private Tunnel offering instead.

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

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

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

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

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

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

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

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

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

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

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

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

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.

It refers to the same thing as the license key reissue mentioned in the section just above.

This is where we take an existing already activated license key, and remove it from our system (revoke it) and replace it with a new license key that can be activated on an OpenVPN Access Server installation. We call this a license 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 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.

We are only able to process license key reissue requests for the license keys that are valid, and not expired.

When a license key reissue is requested, we revoke the old 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 license key file from the file system of the old server, if you wish to keep the old server on.

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

No, a license key is a single-activation key that locks to just one system. You can't share it between servers. So if you want to run 3 servers, each server will need its own license key. If however you have just purchased a license key and it's still unactivated, and you've just now realized you need separate keys, and need too split this license key up so each server can have its own license key, then this is possible under certain conditions. The minimum size of a single license key must contain 10 licenses. So if you purchase a single license key for 30 connections, and you want to have it split up, you can create a maximum of 3 license keys of 10 connections each. We normally only consider requests to split license keys up if the license key has not already been used for activating an Access Server. To request your license key to be split up contact us on the support ticket system.

Yes and no. To clarify, 10 connections on a license key is the minimum for the BYOL licensing system. It's important to note here that any value higher is possible, but lower is not. For example you can buy a license key licensed for 11 connections, or 35, or 524, and so on. But a value lower than 10 on an OpenVPN Access Server BYOL type license key is never possible. So if you intend to buy a license key for 10 connections and then ask us to split it up into 2 license keys of 5 connections each, that is not possible.

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

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.

Yes, they do expire. When you purchase a license key for the BYOL licensing system you purchase it for a certain amount of time. The choices are 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 reverts back to its demonstration mode where only 2 simultaneous connections are allowed. A few weeks before the license key expires, you will receive emails from our automated licensing system on the email address of your account on our main website where license keys can be purchased, to remind you that the key is about to expire, and to ask that you renew it.

If you have in the past purchased a perpetual license key, then read the section below if you are having a problem with such a license key.

If you encounter the problem where an OpenVPN Access Server with x amount of connected devices is showing you that your server is only licensed for 2 connections, while you launched an instance for 10 connected devices, or any of the instances that should come licensed for the chosen amount, but it won't allow more than 2 connections, then the most likely explanation here is that you are using a security group on this instance that is blocking access to the licensing servers. If that happens the OpenVPN Access Server cannot check to see if you are licensed and will fall back to its automatic built-in demonstration mode which allows all functionality without time limit, but allows only 2 simultaneous VPN connections. For more information see the troubleshooting page regarding Amazon AWS tiered instance software licensing.

That system has been cancelled. In the past, years ago, Access Server would not allow any connections at all if you didn't have a license key. We would then issue free 2 user license keys for trial purposes upon request. We have cancelled that system and instead when you install the OpenVPN Access Server product now, and do not provide a license key, it will automatically allow 2 simultaneous VPN tunnel connections. Therefore you do not need to contact us anymore to try the product out. You will very easily be able to confirm that your Access Server allows 2 simultaneous connections by logging in to the Admin UI and looking on the right hand side at how many connections your server is licensed for. It will say 2, unless you have activated a license key to change that amount.

This is possible but with some caveats. If you are using the BYOL licensing system and have an existing license key active on your Access Server, it is not possible to change the licensed amount on the existing license key. But what you can do is purchase an additional license key and activate it on the same Access Server. The licensing system will then simply add them up. For example, if you have a license key that unlocks 10 connections installed on your Access Server and find that you need 30 in total, you can purchase a license key for 20 connections and activate it on that same Access Server. The license key for 10 connections and the license key for 20 connections then are both active and are added up to a total of 30 connections. The caveat here is that the license start date and end date of the newly purchased license key will be different for these two license keys. However when you renew license keys on our website you do have the option to select both license keys and set a single future date for both of them. The renewal system calculates and adjusts the costs automatically in such a case.

If you are using the Amazon AWS tiered instances licensing system then things are unfortunately not quite so easy, but still possible. Due to the way the licensing system works on Amazon AWS, the instance properties are very firmly tied to the amount of licensed connections. At this time you cannot click a button to switch from a 10 connected devices instance to a 25 connected devices instance. The solution here is to make a backup of the your existing AWS instance's OpenVPN Access Server configuration databases, and bring up a new instance with the desired amount of connected devices, and restore the backup of the configuration to that system. There are some caveats. If the old system was configured to function on IP basis instead of an FQDN DNS address, then clients that were installed on the old Access Server instance will continue to attempt to reach the old IP address. If possible, move the IP address to the new instance so that clients can find the server again. But the best option is always to set up an FQDN DNS address, which we recommend for any Access Server installation. With that, you can simply update the DNS record to point it to the IP address of the new instance, and clients will then automatically find the correct instance. And finally of course, the old instance should be stopped to avoid continuing to incur costs on the old instance.

We have a migration guide that will help you to move the existing server configuration from one installation of Access Server, to another. With the configuration of the Access Server moved in this manner, the clients will not need to be reinstalled or adjusted, they will just be able to connect to the new server installation automatically.

Depends on the choices you make on where to deploy and how many simultaneous connections you need and for how long you want to purchase the license key. There is clear pricing information available on our software license pricing page.

You may notice that different wording is used here and there in documentation and on the website. Here we aim to provide some clarification. What the licensing system really counts is the amount of active VPN tunnels. This means various scenarios are possible. For example, you can configure 1 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 could set up an account "andrew" and a password for it, and use that account on an iPad, a Windows computer, and two Macintosh computers, all at the same time. In such a situation if all those devices are connected at the same time you're using 4 connections on the license. If your server says it is licensed for 10, then that leaves 6 connections free.

It also works the other way around. You can have 500 user accounts on your 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 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 license key for 100 is perfectly fine.

And if for example you have 10 VPN tunnel connections active on a server that is licensed for 10, 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.

Yes, 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 a license key, but if you do not provide one, it will automatically go into a sort of demonstration mode. In this demonstration mode, all functions are 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 a license key. So if you want to try out the Access Server, install Access Server on your Linux OS and you can start testing. Upon request we will also grant free temporary trial license keys 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 if installed without a license key, will go into a demonstration mode with full functionality and no time limit, but allows only 2 simultaneous VPN connections to be establish. 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 clearly shown on the right hand side on the AWS Marketplace when you click on a tiered instance on the AWS Marketplace.
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. One of these will simply be titled "OpenVPN Access Server". This Marketplace image is suitable for the BYOL licensing system as long as you do not use auto-scaling and do not change the instance type after activating a license key. If you do then the virtual hardware that the license key has locked to will change and the license key may become invalid. In such a case you will have to contact us through the support ticket system to request a license key reissue. With this licensing model you pay for the AWS instance itself and any license keys that you purchase through us and activate on your Access Server installation. If no license key is installed, the Access Server goes into a demonstration mode where all functions work without time limitations, but it will only allow 2 simultaneous VPN connections to be established. A license key unlocks more connections.

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

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

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.

You can use the following options:

1. CONNECT

a) Access Server module
Action: net.openvpn.openvpn.CONNECT
OR
Action: android.intent.action.VIEW
Cat: None
Mime Type: {blank}
Data: {blank}
Extra: net.openvpn.openvpn.AUTOSTART_PROFILE_NAME:AS {your_profile_name}
Extra: net.openvpn.openvpn.AUTOCONNECT:true
Extra: net.openvpn.openvpn.APP_SECTION:AS
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

b) OVPN Profile module
Action: net.openvpn.openvpn.CONNECT
OR
Action: android.intent.action.VIEW
Cat: None
Mime Type: {blank}
Data: {blank}
Extra: net.openvpn.openvpn.AUTOSTART_PROFILE_NAME:PC {your_profile_name}
Extra: net.openvpn.openvpn.AUTOCONNECT:true
Extra: net.openvpn.openvpn.APP_SECTION:PC
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

2. DISCONNECT
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 cert, key, 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 ca, cert, 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 have a profile 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 to resolve an ambiguity when the profile contains no client certificate or key, because otherwise the client app can't know whether an external certificate/key pair should be obtained from the Android Keychain, 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.

If you check the Save checkbox on the authentication or private key password fields, the app will store your password in an encrypted form, however a determined attacker with physical possession of the device would still be able to recover the password with some reverse engineering.

Currently, the best options for security are to avoid saving passwords, and to use the Android Keychain as a repository for your private key (see below).

The Android developers are in the process of implementing an API for secure storage of passwords that will leverage on the hardware-backed keystore and master device password, however this development is not complete as of Android 4.2. This approach will protect saved passwords even if the device is rooted. When this development is complete, we plan to support it in the app.

• 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 ca, cert, 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:

• https://tools.ietf.org/html/rfc6151#section-2
• https://eprint.iacr.org/2005/067.pdf
• https://eprint.iacr.org/2005/102.pdf

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-auth, key-direction, comp-lzo, cipher, ns-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 remote, ca, cert, key, tls-auth, key-direction, auth-user-pass, comp-lzo, cipher, auth, ns-cert-type, remote-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 ca, cert, key 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 cert, key, 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.

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

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

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.