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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

192.168.1.4/30
192.168.1.4 -- Network address
192.168.1.5 -- Virtual IP address in the OpenVPN Server
192.168.1.6 -- Assigned to the client
192.168.1.7 -- Broadcast address.
Then to reach the rest of the network on behind the OpenVPN server, you push a route to the client, so traffic is routed through 192.168.1.5.

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

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

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

Hope I made things a little clearer.

Mathias Sundman

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

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

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

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

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.

Absolutely, as long as you make sure that:

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

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

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

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

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

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

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

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

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

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

push "dhcp-option DNS 1.2.3.4"

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

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

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

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

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

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

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

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

• Define each OpenVPN directive as a key, with arguments specified as the value. As in the OpenVPN configuration file, arguments are space-delimited and may be quoted.
• Key value pairs for 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.

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"

Yes, of course.

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

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

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.

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

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

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

Here is the config file example:

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

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

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

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

# compression (optional)
comp-lzo

# UID (optional)
user nobody
group nobody

# verbosity (optional)
verb 4
On the other end of the connection, you would duplicate the above config file but change 'remote' appropriately, and swap the ifconfig addresses.

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

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

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

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

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

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

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

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

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

When I modify the Preshared 2048 bit Static Key on the Initiator Side of the Tunnel(don't tested the other way) I'm anyhow able to establish the Tunnel an send Packets through the Tunnel. I don't understand the Key splitting and handling as described below, but I think the Keys on both Sides of the Tunnel should be identical for the Tunnel to be established.

I can modify every Char in Line 2,3,4,7,8,9,10,11,12,13,14,15,16 without any effect and think this is possible a Bug.

A: No, this is not a bug. The 2048 bit static key is designed to be large enough to allow 512 bit encrypt, decrypt, HMAC send, and HMAC receive keys to be extracted from it.

However, this key size is far too large for current conventional OpenVPN usage. OpenVPN uses the 128 bit blowfish cipher by default. It also uses the 160 bit HMAC-SHA1 as a cryptographic signature on packets to protect against tampering. Since you probably didn't specify a key direction parameter, the encrypt/decrypt keys for both directions are the same and the HMAC keys for both directions are also the same.

That means that OpenVPN is only actually using 128 + 160 = 288 bits out of the file -- much less than the 2048 bits which are available.

Below, I will show a sample 2048 bit OpenVPN key, bracketed to show which bits are actually used for key material, assuming default crypto settings:

#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
[eac9ae92cd73c5c2d6a2338b5a22263a] 128 bits for cipher
4ef4a22326d2a996e0161d25d41150c8
38bebc451ccf8ad19c7d1c7ce09742c3
2047ba60f1d97d47c88f7ab0afafb2ce
[f702cb04c7d15ff2606736c1825e830a 160 bits for HMAC SHA1
7e30a796] 4b82825d6767a04b3c8f4583
d4928127262c3a8603776bd6da339f69
dece3bbfee35f1dceb7cbceaef4c6933
2c2cef8ac550ed15213b216b825ab31e
49840f99ff9df3c5f31156439ed6b99c
4fc1bff417d33d77134365e38c9d71cd
e294ba6e65d51703d6d4a629d5fc618e
adddb889b8173ac79b4261328770bbbe
74294bc79e357c82af9ef53f2968be6a
007e6022da0a1a39f2ed5660f94a5926
35d72e5838dd78dd680d91f6edcf6988
-----END OpenVPN Static key V1-----

As you can see, the only lines actually used are 1, 5, and 6. And of course, that matches up perfectly with what you observed.

To verify this, run OpenVPN as follows:

openvpn --dev null --verb 7 --secret key | grep 'crypt:'

where 'key' is a file containing the key shown above.

Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Encrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Encrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Decrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796

Note that the keys which are shown in the OpenVPN output exactly match the bracketed section of the key source.

Now if you want to use more of the key material, it is possible to use two sets of encrypt/HMAC keys, one for each direction:

openvpn --dev null --verb 7 --secret key 0 | grep 'crypt:'

(Note that the '0' after key chooses one symmetrical direction -- the opposite peer would use a '1' to choose the other direction).

Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Encrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Encrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: CIPHER KEY: 2c2cef8a c550ed15 213b216b 825ab31e
Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Decrypt: HMAC KEY: adddb889 b8173ac7 9b426132 8770bbbe 74294bc7

Now notice that the Encrypt and Decrypt keys are no longer identical. The encrypt keys are drawing key material from lines 1, 5, and 6 in the key file, while the decrypt keys are drawing from lines 9, 13, and 14.

Now the opposite peer will use a key-direction of 1:

openvpn --dev null --verb 7 --secret key 1 | grep 'crypt:'

Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Encrypt: CIPHER KEY: 2c2cef8a c550ed15 213b216b 825ab31e
Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Encrypt: HMAC KEY: adddb889 b8173ac7 9b426132 8770bbbe 74294bc7
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Decrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796

Notice how the Encrypt and Decrypt keys are swapped, in relation to the key-direction 1 example.

So you might ask why is the OpenVPN static key file so large, if such a small percentage of the bits are currently used? The answer is to accomodate future ciphers and HMAC hashes which use large keys. Changing a file format is obviously problematic from a compatibility perspective, so 2048 bits were chosen so that two sets of 512-bit encrypt and HMAC keys could be derived for two separate key directions.

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

Everything seems to be configured correctly, but I can't ping across the tunnel ¶
Make sure that your options match on both sides of the connection. See below for more info.

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

--cipher
--auth
--keysize
--dev tun|tap [unit number need not match]
--dev-type tun|tap--link-mtu
--udp-mtu
--tun-mtu--no-replay
--no-iv
--comp-lzo
--fragment
--tun-ipv6
--tls-auth
--secret
--key-method
--tls-client [matched with --tls-server on the other end of the connection]
--tls-server [matched with --tls-client on the other end of the connection]
--ifconfig x y [matched with --ifconfig y x on the other end of the connection]
--proto udp
--proto tcp-client [matched with --proto tcp-server on the other end of the connection]
--proto tcp-server [matched with --proto tcp-client on the other end of the connection]
It is also useful to try to isolate the problem, e.g. is the crypto support working independently of the networking code? You can test this with:

openvpn --genkey --secret key
openvpn --test-crypto --secret key
Other loopback tests are presented in the INSTALL file. Many connectivity problems start at the firewall. For example, if an OpenVPN daemon is tunneling data to and from a given TUN or TAP virtual adapter, a firewall rule must be present to permit incoming traffic on that TUN/TAP adapter. On a Linux iptables-based firewall you can enable incoming packets on a TUN device with this command:

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

iptables -A INPUT -i tap+ -j ACCEPT
tcpdump or Wireshark are also very useful tools for troubleshooting connection problems. tcpdump can be used to show encrypted tunnel traffic transiting OpenVPN's UDP port:

tcpdump -i eth0 udp port 1194
The above example assumes that your connection to the internet is via eth0, and that you are using UDP port 1194 as the tunnel port (the default). tcpdump can also be used to show unencrypted traffic on OpenVPN's virtual TUN/TAP device:

tcpdump -i tun0
In the above example, replace tun0 with the name of the TUN/TAP device. ifconfig can be used to show active network devices, both real and virtual. Also, note that you cannot mix --dev tun and --dev tap on different ends of the connection. Use one or the other consistently. If you are connecting different versions of OpenVPN, check the compatibility page.