Common VPN issues

Since networking and routing scenarios can vary there is a range of common VPN issues that can occur.

The following tables show a list of common error messages that may be reported in the VPN Panel and logging. Also listed are common problems that can occur when accessing VPN Participants.

VPN Error messages

There are a range of error messages that can be displayed in either the appropriate WinGate VPN log file, or on the VPN Panel.

VPN Error message	Solution
Connection refused or Connection to remote host timed out	These error messages happen before the SSL connection is established. It means that a TCP/IP connection could not be established to the remote server. To establish that the Master Node server is present on the Internet (and responding), try running ping & or tracert from the command line. Read more on testing IP connectivity If the server is online, a firewall or other problem might be preventing incoming connections. Read about configuring ports on the router firewalls Note If the Master Node is located behind a third party firewall/router, then all incoming VPN traffic to the Internet side of the router must be redirected to the VPN Master Node machine behind it.
Unable to connect using SSL - Error code 5	This error can relate to several issues during the SSL negotiation stage of connecting to a VPN: Incorrect VPN Name The name specified in the Name of the Remote VPN field of the Join VPN properties that the remote Node uses when joining the VPN, needs to match the Name field on the General tab of the Host VPN properties on the Master Node. This name is case sensitive. Please check that it is identical on each end of the VPN. User is not allowed to access the VPN The username and password credentials entered in the Join VPN properties, belong to a user that has not been given the Connect to this VPN permisson so they can connect their VPN Node to the VPN. (Set via the Permissions tab in the Host VPN properties on the Master Node) Expired Certificate The X509 security certificate used with the hosted VPN configuration has expired. You should contact the administrator of the hosted VPN to generate a new certificate and reconfigure the hosted VPN. They will then need to redistribute the new VPN configuration file to remote VPN Client Nodes who wish to join the VPN.
The server certificate fingerprint does not validate	The fingerprint is a public identifier of the server. This is your easiest way to authenticate the servers identity. If you receive this error message, it means that: The fingerprint you entered when configuring the VPN you're joining was incorrectly entered. Check that this value is correct. Please remember, this value is case insensitive. Also, 0 (zero) sometimes looks a lot like O (the letter) mixing these up is a common mistake. Note It will never be the letter O the fingerprint only uses the letters A - F). The server has changed its certificate. In this case, you should contact the hosted VPN administrator to obtain a new certificate. Alternatively you can deselect the Check Server Fingerprint option in the Join VPN properties, so the finger print will not be checked when connecting to the VPN.
Invalid Username and Password	The username and password combination is used after a secure connection has been established and after you've verified the servers fingerprint. If you get this message, it means that either the username, or the password you specified on the Join VPN properties, are incorrect. This could commonly be caused by typing mistakes. If you are sure that the values you entered are correct, you should contact the VPN administrator. It could be that the user account specified in the Join VPN configuration has not been given the Connect to this VPN permission so they can to connect their VPN Node to the VPN, or the user account with this permission is disabled. Remember that the username and password specified in the VPN configuration file, should be a valid user account in the user database used by the WinGate VPN Master Node, that has been given permission to connect their VPN Node to the VPN.
There is already a connection to a VPN hosted by this machine from I.P. X.X.X.X - Circular connections are not allowed	This shows up as a system message in WinGate VPN log file when you attempt to connect to a remote VPN Node that has already joined a VPN hosted on this machine. Circular connections are prohibited in WinGate VPN. Consider scheduling when VPN Nodes connect or will be connected to avoid this from happening. You can achieve this by creating a scheduled event in the WinGate Scheduled Events system. Alternatively one VPN Node could be designated to always host the VPN, since the sharing of VPN Participant resources across all Nodes (and their networks) is possible when they are connected to the VPN.
Published routes - in conflict or are ignored	This occurs when there are IP address conflicts within the VPN. Each network involved in the VPN must use distinct IP subnet ranges within the scope of the VPN. When an IP address conflict occurs with the routes published by any Node in the VPN, then the conflicting routes will show up as Ignored or in conflict. Read more about published routes in the VPN

VPN Participation issues:

Issue	Solution
The VPN connects but you cannot see or connect to VPN Participant machines in Windows explorer.	This is normally caused by incorrect routing set up. For WinGate VPN to function, the VPN Node must be able to route any network packets between the appropriate VPN Participant on their network and the remote side of the VPN. So each VPN Participant machine will need to know how to send traffic to the other side of the VPN. You can test that routing is working correctly to the remote VPN Participant by pinging the LAN IP address of the VPN Participant machine from the command line. Read about configuring machines to participate in the VPN Note If the VPN Node machine only has one interface (Dial-up modem, Cable modem or similar) without a network card you will need to enable File and Printer Sharing on the interface that provides you with Internet access. Enabling this allows the networking subsystem to start which in turn allows you to browse and share files across a network. The WinGate firewall will prevent unauthorized access to your computer. If you do not have File and Printer Sharing enabled on at least one of your interfaces the appropriate network sub-systems that allow access to files, printers and browsing will not be running and you will be unable to access any of those services and so machines will not be enumerated.
VPN Participant machines and their shares are visible across the VPN, but the resources are not accessible	On some types of connection, there is a reduction in the MTU (Maximum Transmission Unit), which is a measure of the largest packet payload that may be sent over a network interface or point to point link. For instance PPPoE connections reduce the MTU by 8 bytes. The standard MTU for Ethernet is 1500 bytes, which means you can have up to 1500 bytes of payload over Ethernet. The Ethernet frame itself has a 14-byte header, so the actual maximum packet size (as opposed to the MTU) is 1514. WinGate VPN reduces the MTU as well, since the encryption and tunnelling require approx 50 - 60 bytes per packet. If there are MTU issues, you can find that large (maximum size) packets can be lost. This produces strange effects such as: Able to connect to a network share, prompted for a password, etc. but unable to browse large directories or transfer files. Network drive mappings are disconnected and are generally unreliable. Using Ping, you can send packets of different sizes. WinGate VPN fragments packets (if allowed) when it transfers them across the VPN. Therefore you should be able to send large ping packets successfully across the VPN if everything is working properly. If not, then once you get to a certain size, they will stop working. By working out the ping size that works versus the size that doesn't you can calculate what the effective MTU really is. For dialup connections and some network interfaces, it is then possible to modify the MTU so that your client machines will no longer send packets that are too big. Read instructions on testing the MTU

Issue

Solution

The VPN connects but you cannot see or connect to VPN Participant machines in Windows explorer.

This is normally caused by incorrect routing set up. For WinGate VPN to function, the VPN Node must be able to route any network packets between the appropriate VPN Participant on their network and the remote side of the VPN. So each VPN Participant machine will need to know how to send traffic to the other side of the VPN.

You can test that routing is working correctly to the remote VPN Participant by pinging the LAN IP address of the VPN Participant machine from the command line.

Read about configuring machines to participate in the VPN

Note

If the VPN Node machine only has one interface (Dial-up modem, Cable modem or similar) without a network card you will need to enable File and Printer Sharing on the interface that provides you with Internet access.

Enabling this allows the networking subsystem to start which in turn allows you to browse and share files across a network.

The WinGate firewall will prevent unauthorized access to your computer. If you do not have File and Printer Sharing enabled on at least one of your interfaces the appropriate network sub-systems that allow access to files, printers and browsing will not be running and you will be unable to access any of those services and so machines will not be enumerated.

VPN Participant machines and their shares are visible across the VPN, but the resources are not accessible

On some types of connection, there is a reduction in the MTU (Maximum Transmission Unit), which is a measure of the largest packet payload that may be sent over a network interface or point to point link.

For instance PPPoE connections reduce the MTU by 8 bytes. The standard MTU for Ethernet is 1500 bytes, which means you can have up to 1500 bytes of payload over Ethernet. The Ethernet frame itself has a 14-byte header, so the actual maximum packet size (as opposed to the MTU) is 1514.

WinGate VPN reduces the MTU as well, since the encryption and tunnelling require approx 50 - 60 bytes per packet.

If there are MTU issues, you can find that large (maximum size) packets can be lost.

This produces strange effects such as:

Able to connect to a network share, prompted for a password, etc. but unable to browse large directories or transfer files.

Network drive mappings are disconnected and are generally unreliable.

Using Ping, you can send packets of different sizes. WinGate VPN fragments packets (if allowed) when it transfers them across the VPN. Therefore you should be able to send large ping packets successfully across the VPN if everything is working properly. If not, then once you get to a certain size, they will stop working.

By working out the ping size that works versus the size that doesn't you can calculate what the effective MTU really is. For dialup connections and some network interfaces, it is then possible to modify the MTU so that your client machines will no longer send packets that are too big.

Read instructions on testing the MTU

Max Howells
2019-08-28 17:45:08
A lot of issues anyone can face regarding VPN. I just read the above article. It's quite helpful. While I was facing VPN issues I was facing exactly this type of errors.