Troubleshooting guide to resolve problems with an SSL VPN connection
Last adaptation to the version: 12.6.0
New:
- Updated to Redesign of the webinterface
This article refers to a Beta version
notempty
This guide should be worked through step by step.
A systematic approach is important!
A systematic approach is important!
First measures
| Possible reason | Checking | Solution approach |
|---|---|---|
| Port filter rules do not work | Menu is flashing | Existing rules must be taken over with |
Client download not possible
UTMuser@firewall.name.fqdnfirewall-user 
User interface is not displayed
| Possible reason | Checking | Solution approach | UTMuser@firewall.name.fqdnNetwork 
|
|---|---|---|---|
| Wrong port for user web interface | Menu Webserver User Webinterface Port: 443 |
If a value other than port 443 (https) is entered here, the port must also be specified in the URL of the browser, e.g: firewall.ttt-point.de:xxx | |
| The UTM is located behind a router (Fritzbox etc.) | Example Fritzbox: Menu Internet / Shares / Port Shares | The Fritzbox or the router must allow port forwarding to the external IP address of the UTM. | |
| Access to port 443 is not enabled | Menu or (better) |
Either access to the user interface is enabled via the implicit rules or (better) via dedicated port filter rules. | UTMuser@firewall.name.fqdnFirewall 
|
| Port 443 is already occupied in the set of rules (DESTNAT) | The port for the user interface must be changed. | ||
| Reverse proxy set up for https | Menu | If a reverse proxy was also set up for https, the port for the user interface must be changed. | |
User cannot log in to the user interface
| Possible reason | Checking | Solution approach | UTMuser@firewall.name.fqdnApplications 
|
|---|---|---|---|
| User is locked out by FailToBan | Menu Area Locks | It is possible that the password for the user name has already been entered incorrectly several times. Check current lock and unlock if necessary | |
| User / group has no authorization | Menu Area User button Client downloadable in user interface: Yes | This option must be enabled in the User Preferences. If Use group settings: has been enabled, this option must be enabled in the Group Preferences. | UTMuser@firewall.name.fqdnAuthenticationUser 
|
Download option for the client is not displayed
| Possible reason | Checking | Solution approach | UTMuser@firewall.name.fqdnAuthenticationUser
|
|---|---|---|---|
| User / group has no authorization | Menu Area User button Client downloadable in user interface: Yes | This option must be enabled in the User Preferences. If Use group settings: has been enabled, this option must be enabled in the Group Preferences. | |
Connection problems
As a general rule:
If no connection is established ( indicated by the red lock symbol in the info bar), the error can only be on the physical level.
Evaluation of the log file of the SSL VPN client:
- Double click on client icon in the taskbar
- Right click on connection entry
- Log (Larger font with CtrlMousewheel up)
Evaluation of the network traffic on the UTM:
- To use the tcpdump command on the UTM, a root user is required.
- The livelog shows messages from the packet filter by default. By default, however, it only shows when the default policy discards packets for which there is no matching firewall rule. But you can configure logging for firewall rules you have created yourself, so that an entry appears when this rule is effective.
- The corresponding implicit rule is deactivated for this purpose: Tab VPN SSL VPN UDP (possibly TCP)
- There must be a network object for the roadwarriors: Area Groups ssl-vpn-user (or corresponding group) area SSL-VPN Available in Port Filter: Yes
- There must be a port filter rule:
| # | Source | Destination | Service | NAT | Action | Active | |||
 |
4 |  ssl-vpn-user |
 internal-network |
 ssl-vpn |
Accept | On |
Does not come into effect or is cancelled
| Error message | Possible reason | Solution approach |  |
|---|---|---|---|
| link remote: [AF_INET] 192.0.2.192:1194 TLS Error: TLS key negotiation failed |
The connection is not established. | ||
| The client cannot reach the UTM at the IP address shown in the client log. No packets arrive. | Cross-check on the UTM:
|
 | |
| Packages arrive, but are discarded immediately |  | ||
| TLS Error: TLS handshake failed TLS ERROR: TLS key negotiation failed |
Authentication fails. A connection has been initiated and the server certificate has been verified by the client. However, the connection setup terminates with a timeout. The Gateway's Livelog (UTM Menu ) shows an error message in the application and kernel messages stating that the client's certificate could not be verified. Here the Client Certificate was revoked. |
Area Recall button |   |
| VERIFY ERROR | An error occurred during the verification of the CA | Menu Area Certificates Do server certificate and client certificate use the same CA? Is the CA still valid? | |
| ERROR: Received AUTH_FAILED Control Message | User authentication failed. Username and password do not match or the authorization to establish an SSL VPN connection is missing. |
| |
| ERROR: There are not TAP-Windows adapters on this system ERROR: Application Exiting |
Missing tap driver | Installation of the latest version of the client from the Reseller Portal or in the UTM user interface. These versions include a current TAP driver. |  |
No connection to the target host
If an existing connection is displayed, the error is no longer in the connection setup. If a connection through the tunnel cannot be established (e.g. PING to a host in the network behind the gateway), the reason must be found at the virtual level. Again, it's a good idea to first update the 'port filter ruleset and take a look at the livelog.
There are three possibilities for troubleshooting:
- The packet you're looking for doesn't show up
→ If no packet is visible in the livelog, then probably none is reaching the firewall. So the error is to be found in this case on the client. - The package you are looking for shows up and is dropped (DROP)
→ When a package is dropped, the matching FW rule is missing, incorrectly formulated or not yet effective (rule set not yet updated). The error is therefore on the gateway - The packet you are looking for shows up and is accepted (ACCEPT)
→ If a packet is accepted, the error is in the direction of the destination host.
Check Client
Check Client
| Possible reason | Checking | Problem description / Solution approach |  |
|---|---|---|---|
| Missing routes | Command line in the Client: route print | If the correct routing entries are not found there, it must be checked in the log of the VPN client whether they were transferred from the server or whether they could not be set correctly. | |
| Log file in the client | If the routes were not transmitted correctly, they must be added or corrected in the SSL VPN server settings. In the example, the route to subnet 10.20.30.0/24 was transferred correctly. |  | |
| Add the required networks under Edit the used connection Tab General Share Server Networks: Select additional networks in the clickbox or enter individual servers |
UTMuser@firewall.name.fqdnVPNSSL-VPN 
| ||
| Packages do not leave the client |
|
If no packets are displayed here, nothing arrives through the tunnel. If necessary, check whether a client-side or intermediate firewall filters the packets | |
Check Gateway
Check Gateway
| Possible reason | Checking | Problem description / Solution approach | DROP: (DEFAULT DROP) 10.10.0.2:49874 → tun0 → eth1 192.168.175.22:80 |
|---|---|---|---|
| Packages are dropped | Livelog of the UTM → Show packet filter messages only | If there are packets that are discarded, the set of rules must be adapted | |
| Wrong gateway for tunnel connection | Livelog of the UTM → Show application and kernel messages only | If the message bad source address is found here, the corresponding packets are discarded. The gateway of the SSL-VPN connection must be adapted: Area Groups (or Users) Edit Group or User Tab SSL-VPN Remote Gateway: Select the Gateway the Client will connect through | m.mueller/192.168.178.114:62242 MULTI: bad source address from client [::] packet dropped |
| Packages are accepted | Livelog of the UTM | If there are packages that are not dropped, the problem must be with the target host | |
Check target host
Check target host
The communication to the target host can be traced with the packet sniffer tcpdump on the corresponding interface of the UTM:
| |||
| Message in the LOG | Problem description | Solution approach |  |
|---|---|---|---|
| ARP, Request who-has | Target host is not reachable. If the target host is physically not reachable, no IP packets are visible at the internal interface, but ARP requests sent by the gateway to determine the MAC address of the target host are. These are not answered. |
| |
| ICMP echo request | As soon as TCP/IP packets can be seen at this point, the target host can be reached, since the delivery of these packets requires a successful ARP request. However, no packets are returned. | Is a local firewall activated on the target host? Check local firewall. |
 |
| If the target host has set a different / wrong default gateway, the ARP requests for this gateway are visible at the UTM | Check the default gateway in the target host and correct it if necessary. If a different default gateway is required than the one used to establish the SSL-VPN connection, a route for the transfer network must be entered in the target host. | ||
| ICMP echo request ARP, Request who-has |
Errors in the network configuration can be further localized based on the ARP requests arriving at the UTM. Here the target host tries to determine the MAC address of the source host, which suggests an incorrect subnet mask | Check subnet mask in target host |  |