Access Server

Follow us

Troubleshooting OpenVPN Connectivity Issues


Connectivity issues are a pain to deal with, especially if they are impacting your business. Because there are many variables involved in such an issue, the problem can be seemingly impossible to solve despite the amount of effort you put in to attempt to correct the issue. That said, with the correct diagnostic tools, troubleshooting such a problem can be a manageable task.

Before you begin...

Before you begin troubleshooting the issue(s) you are having, it might be wise to look at these common culprits:

  1. If you are unable to connect to the remote local subnet, make sure that the proper access is delegated inside Access Server. (e.g. Make sure your local subnets are listed under VPN Settings, and under the Specify the private subnets to which all clients should be given access (as 'network/netmask_bits', one per line): textbox.) If you are using the Yes, using routing (advanced) option, make sure that you have added the proper static routes on your local router. If you do not know how to or cannot do this, it is preferable that you use the default Yes, using NAT option. If you are using the NAT option, make sure that you DO NOT list your subnets inside the Advanced VPN section, under the Private Routed Subnets (Optional) section. Doing so will result in lost connectivity.
  2. If you are using the Layer 3 operating mode within Access Server, make sure that you do not use the same dynamic IP address range you are using for your remote network. In other words, if your VPN side LAN has a network of with a subnet mask of, do NOT use the same address range inside VPN Settings, Dynamic IP Address Network. Instead, use something that does not conflict with the remote network (e.g., subnet mask:
  3. If you are unable to connect to the VPN server at all, make sure that you have forwarded all the necessary ports (TCP: 443, UDP: 1194, TCP: 943) if you are using NAT. If not, make sure that your firewall is allowing inbound access to these ports. Moreover, make sure that the VPN client's ISP is not blocking outbound access to the aforementioned port numbers. You may change these port numbers to your specifications inside the Web Admin UI, if needed.
  4. If you installed Access Server on a ESXi platform, make sure that the NIC type is not set to Flexible. If supported by your OS and ESXi software, select VMXNET3 as the NIC type. If your NIC type for your Access Server appliance is currently set to Flexible, shut down the VM, remove the NIC, and readd the NIC as another supported type (preferably VMXNET3).
  5. Ensure that Jumbo Frames are not enabled on any nodes on your network (e.g. your VPN server, your VPN client, and the destination server your client is trying to connect to).
  6. If a software or hardware firewall is in place (especially if the firewall is whitelisting connections), make sure it is allowing ICMP Destination Unreachable: Fragmentation Needed (ICMP Type 3, Code 4) into your network. Windows Firewall, by default, has this rule configured, and there is no need to add this rule explicitly on Windows machines.
  7. Unless it is an absolute requirement that you need to use TCP mode for your VPN connections, consider using UDP or Multi-daemon mode inside Access Server. Running TCP based connections over a TCP based VPN can result in intermittent connection failures, as well as other performance problems, and as such, is not recommended as the primary method for establishing a VPN link between two nodes.
  8. Make sure your VPN client is using a reliable Internet connection that has a low error packet rate. If your clients are using a less reliable Internet connection (e.g. satellite Internet, 3G Mobile / Aircard connection), then it is very important that you configure your server to use UDP or multidaemon modes, as mentioned previously.
  9. Use a network cable tester and/or built in cable testing tools to ensure that your Ethernet cables are in good shape. Replace any defective cables reported by your testing tools.
  10. Make sure that your hardware firewall software/firmware are up-to-date, and update them if necessary/appropriate.
  11. Disable any Internet security and antivirus related products installed on your client's computers while trying to identify your network issue(s). Some Internet security and antivirus products are known to cause interference with VPN connections and should be disabled during your testing to rule out this possibility.

Determining the Issue with a Network Sniffer

If none of the aforementioned solutions resolve your problem, you may want to look into using a network sniffer to help identify the problem.
For Windows/Mac based machines, the sniffer can be downloaded here:
Wireshark is usually also available via most GUI based package managers within Linux, if you would prefer using a graphical interface.
For Linux (console, text based) based machines, the sniffer can be used by downloading the tcpdump package. This can be installed using the apt-get install tcpdump command in Ubuntu/Debian Linux distributions.

Using the Sniffer

If using Wireshark, the network capture can be started by selecting the Capture menu, then the Options... option.

In the options dialog that appears, select the proper interface you would like the capture on. This is usually the outbound interface that provides the Internet connection to your other nodes. If you are using a WLAN connection, for example, this will usually be the Wireless Network Connection entry in the list. If you are uncertain which interface correlates to which network card in your system, consult the IP address field that appears when you select an interface from the dropdown list.

After the proper interface has been selected, populate a capture filter in the Capture Filter: field. This is usually provided by one of our support technicians.

Click Start to start the capture process.

To stop the capture, press the Stop button on the toolbar panel.

Once the capture has been stopped, you may save the capture data to a file by using the File -> Save As option.

If using tcpdump, you can either have tcpdump write its capture data directly to a file (without showing it on the screen), or simply display everything on the screen (without saving it to a file).
Unless directed by our support staff otherwise, use the writing to a file option. This allows our staff to look at the capture data more precisely than if only the screen data was captured.

To do a "write to file" capture, use the following command syntax:
tcpdump -i eth0 -w capture.pcap host
where eth0 is the interface you want to capture on, capture.pcap represents the file you want to write to, and host is the capture filter provided by our support staff. If your system is not using eth0 as its outgoing interface, replace eth0 with the correct interface name as depicted by the ifconfig command.

After you invoke the command, you will see a message similar to the one below:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
and it might seem like nothing is happening. This is normal, as all the capture data is written to the file, and not to the screen. To interrupt or finish the capture process, simply press CTRL+C on your keyboard.

To do a screen capture instead, simply omit the -w capture.pcap command line option in the tcpdump command, and the results will be printed on the screen. Press CTRL+C to interrupt or finish the capturing process.

Capture Scenarios

The follow capture scenarios are provided to help you setup your packet captures as such to complement your support ticket case. If you do not already have a ticket open, please visit the ticketing system at to open a case. Please be advised that support is only provided to paying customers with an active support license. Due to the high volume of inquiries received at our ticketing system, we are unable to provide assistance to free users or users with expired support licenses.

1) Cannot connect to VPN server, and receiving "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)", "twisted.internet.error.TimeoutError", or similar errors.

PRIOR to connecting to the server, start the packet capture on both the VPN server and the VPN client. If there is currently an connection attempt, cancel the connection attempt and wait 30 seconds prior to starting the packet captures. After the packet captures are started, initiate the VPN connection. Stop the packet capture when an error message is shown.

a) VPN Client Side Capture Filter: host [vpn server hostname or ip address here] or icmp or arp (e.g. host or icmp or arp) - capture on outgoing interface (e.g. WLAN)
b) VPN Server Side Capture Filter: host [vpn client external ip address here] or icmp or arp (e.g. host or icmp or arp - if you do not know what the external IP of your VPN client is, go to and note the numerical IPv4 address) - capture on outgoing interface (e.g. eth0)

Note: If you are using a proxy server to connect to your VPN server, use host [proxy server ip address / hostname here] or host [vpn server hostname or ip address here] or icmp or arp for your VPN client side capture filter instead (e.g. host or host or icmp or arp).

2) Poor network share transfer speeds and/or error messages when trying to access network shares.

PRIOR to connecting to the server, start the capture on all three nodes. If a network share is currently open, close it, and wait 30 seconds prior to starting the packet captures. After the packet captures are started, start the file transfer across your VPN connection. If an error message is shown, or a significant degradation is obvious, cancel the file transfer, wait 15 seconds, and then stop the packet captures.

In order to reduce the amount of data you need to send to our ticketing system, please use a highly compressible test file for testing your VPN connection. To download a compressed test file which is highly compressed (100MB, compressed down to ~100KB, please use the following link:

a) VPN Client Side Capture Filter: tcp port 445 or icmp or arp - capture on TAP32 or tun0 interface (OpenVPN's interface)
b) VPN Server Side Capture Filter: tcp port 445 or icmp or arp - capture on outgoing interface (e.g. eth0)
c) File Server Side Capture Filter: tcp port 445 or icmp or arp - capture on outgoing interface (e.g. LAN)

Gathering Capture Files and Sending Them to Support for Analysis

After you are done with the packet captures, please gather all the capture filters from all the involved machines, and rename the files descriptively as to the origin of the capture. For example, if the packet capture came from the VPN server, it would be appropriate for you to name the packet capture vpnserver.pcap. For Linux computers, you may need to use a SFTP client such as Filezilla or Cyberduck to retrieve these capture files remotely if you do not have direct access to the server itself.

Next, using an archiving (ZIP) tool, compress all of these files and attach them to your support ticket. A support specialist will analyze your network captures, and will provide you with the overall findings.