Openvpn Udp Failed

[Firman Lamarre]

Ifall of a sudden all your VPN clients are showing this error message in the VPN client logs, the most likely explanation is that your certificate infrastructure has expired. If this affects all your clients, you will need to create a new VPN certificate infrastructure with the sa init command then and reprovision all your VPN clients with a new connection profiles. If it affects only one or a few VPN clients then most likely you just need to obtain a new connection profile from the server to get connected again.

Certificates have a certain period in which they are valid. Access Server by default generates CAs and certificates valid for 10 years. You can determine the validity of certificates using the openssl command line tool. You can give it a CA or client certificate and it will tell you how long it is valid. If you are outside of that timeframe, you will have to take action. The client certificate and CA certificate can be found in the connection profile between the [...] and [...] blocks.

Connectivity issues are often related to the network or the internet connection between the VPN client and the VPN server. These issues may prevent you from connecting successfully, while the server is otherwise operating normally.

Use your web browser to open the address of your Access Server. If you get a warning about an insecure certificate, click through that warning and access the web interface. If this loads correctly and you see the Access Server login page, the web interface is functioning normally. If it fails, but VPN connectivity works, it seems that only the web services have become unreachable. You should check that the necessary port for the web interface (TCP 443) is properly allowed through whatever system stands between you and the Access Server. We also have a troubleshooting guide for the web services that you may want to take a look at. A restart of the server may resolve a temporary issue. If the issue is resolved temporarily with a restart but later comes back, try updating your OS and the Access Server. If the problem persists then contact our support team and explain the situation:

We recommend using a custom hostname, such as vpn.example.com, which resolves to the public IP address of your Access Server through a DNS record, as the best way for users to download VPN clients and connection profiles. If you use a DNS record, verify that when you try to ping or resolve this DNS record, that it actually resolves to the correct public IP address. If only some people experience problems with this DNS record, then we suggest using an online DNS checker tool to verify the status of this DNS record from locations all over the world.

In some cases, DNS records may have problems. Try accessing the OpenVPN Access Server web interface by its public IP address in your web browser directly. For example, if your server has the IP address, 123.45.67.89, then try:

For network connectivity your server must be connected to a switch or router. Ensure that the cable is connected. On virtual platforms, the virtual switch name or settings may have changed, disconnecting the virtual machine. The network card can also be disconnected within the virtual machine settings, or it may be on the wrong VLAN. For some functionality like layer two bridging, you may need to enable promiscuous mode and MAC address spoofing. On workstations with virtualization solutions, your virtual machine may be attached to a NAT-isolated network and becomes unreachable to external machines. Setting it to bridging could be the solution there.

If you can access the server on the console and log in, but the server is not responding to any input, or you see kernel panic messages, the server may have crashed in some unexpected way. Power the server down and start it up again. Check if the server boots up normally, login, and check if you can now connect to VPN and web services.

Note: With damage to the filesystem, you may have damage to other files as well. First, determine whether the issue is recoverable and will not occur again, or if it is better to migrate to another server and copy your database configuration files to that new server, and maybe if necessary repair them on the new server. If that fails, contact us for additional assistance.

If the hard disk that the Access Server is installed on has run out of space there will be unexpected problems. Try to verify available disk space with the df command. Below is an example of a disk that has run out of available disk space. If your hard disk is out of space, free up space or increase the hard disk size.

If the first command shows that the service is not running, try starting it with the service openvpnas start command and monitoring the status. If it is started correctly, then check the output of the second command. All the components in there should state that they are on. If a component is not, that component has a problem. If all components are on, however, then the Access Server should be up and running.

My company is in the middle of deploying Sophos Connect across our devices. Several machines have been receiving the message "Service 'OpenVPN Service' (OpenVPNServiceInteractive) failed to start. Verify that you have sufficient privileges to start system services." towards the end of the installation process (during the Starting services portion). This has been happening despite running the install as Administrator, and even with users who ARE Administrators. I have also double-checked the Local Security Policy ("Log On As A Service") to make sure the users have this permission as well, and checked for Windows Updates as well.

During the install, it does create the OpenVPN Service, but not the OpenVPN Interactive service. I can set the OpenVPN service to Automatic (in the middle of the install at the error message), but it still will not start. When the installation aborts, the OpenVPN service is removed.

I was finally able to bypass this message (on a Windows 7) by FIRST installing the native OpenVPN program ( -downloads/) which installed the standalone OpenVPN service by itself, and THEN installing Sophos Connect.

This makes me think that, somewhere between client and server, there is a misbehaving NAT device, a device with very short-lived state table entries, which is changing the source port number that it applies to the client's established stream, causing the server to think that two short-lived communications are in progress, instead of one continuous one.

Such devices generally only do this with UDP, so I have advised you to confirm that you are using UDP, and try TCP instead. This you have done, and found that it fixes the problem. The next step is to identify the misbehaving NAT device, hit it with a club hammer, and replace it with one that doesn't make the cardinal mistake of assuming that all UDP communications are ephemeral; but you have indicated that you're happy with changing to TCP as a workaround, and so the matter is concluded.

The VPN on our pfSense firewall had mistakenly been put on the LAN interface instead of the WAN interface, and so the exported config was set to try and connect to the firewall's LAN IP address - which was never going to work with the client naturally being on a different LAN.

So at this stage it may still be worth checking you're actually connecting to the right place, and there are no firewall rules blocking the connection, etc. Particularly if your configuration has been automatically generated.

LE: this solved my problem but it's not the best approach as per below comments. You should use UDP instead of TCP. It helped me because I had different settings between the client and the server configs.

None of the solutions mentioned earlier worked. In my case, even though the client log showed same error TLS Error: TLS key negotiation failed to occur within 60 seconds, the server logs showed VERIFY ERROR: depth=0, error=CRL has expired.

I ran into this error in AWS, where OpenVPN was installed on a server with a public IP, but on an instance which was in a private subnet, i.e. a subnet which didn't have a route to an internet gateway.

There seems to be a lot of different causes for the error - I was seeing this on the server for one client, but successfully connecting with another (the latter client being an android device using the OpenVPN Connect App).

What it turned out to be in my case is that I'd neglected to include a CommonName value when creating the server certificate - the app was ignoring this mistake but the other clients (OpenVPN plugin for Network Manager and pfSense) were validating this and refusing to continue the connection. This could be found within the client logs, but all that was visible on the server-side logs was:

First timer here. I've managed to install and get my OpenWRT setup on an x86 machine. I've set up OpenVPN using ExpressVPN but I can't get the instance to start. When I do, the system log says the following:

When an ovpn file is used, it replaces any other settings (except enabled) that may be in /etc/config/openvpn. So attempting to set the userpass file there has no effect. It needs to be in the .ovpn file.

Yes.

option config will direct that OpenVPN instance to read the file instead of using UCI options. Without an option config, the options in /etc/config/openvpn are used to build a temporary .ovpn file that is then passed to OpenVPN. It's an either/or process. Configuration can't be combined from the two methods.

I also set it up according to the tutorial linked in the OP, and in there, the author set up not just the auth file, but also the certificate and key files as paths. And they were also not working. It's really confusing

When option config is used, the OpenWrt script that starts OpenVPN doesn't look inside the .ovpn file at all. It only passes the name to OpenVPN, which will then use the file the same as on any other system. You can see that by using ps to see the command line used to launch the OpenVPN process.

3a8082e126