notempty Dieser Artikel bezieht sich auf eine nicht mehr aktuelle Version!
notempty Der Artikel für die neueste Version steht hier
notempty Zu diesem Artikel gibt es bereits eine neuere Version, die sich allerdings auf eine Beta-Version bezieht
Troubleshooting guide to resolve problems with an SSL VPN connection.
Last adaptation to the version: 04.2020 11.8.8
notemptyThis article refers to a Beta version
-
This guide should be worked through step by step.
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
Client download not possible
User interface is not displayed
| possible reason | checking | Solution approach | |
|---|---|---|---|
| Wrong port for user web interface | Menu Box 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. |  |
| 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 | |
|---|---|---|---|
| User is locked by FailToBan | Menu Tab 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 has no authorization | Menu Tab Groups What group is the user in? What permissions does the user's group have? |
The user must be a member of a group that is allowed to access the user interface (and has the SSL VPN authorization). |  |
Download option for the client is not displayed
| possible reason | checking | Solution approach | |
|---|---|---|---|
| User / group has no authorization | Menu Tab User Button Client downloadable in user interface: Yes | This option must be enabled in the User Preferences Yes. If Use group settings: Yes has been enabled, this option must be enabled in the Group Preferences Yes. |
 |
Connection problems
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:
- Doppelklick auf Client-Icon in der Taskleiste
- Rechtsklick auf Verbindungseintrag
- Log (Größere Schrift mit StrgMausrad nach oben)
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:Tab Groups ssl-vpn-user (or corresponding group) Tab SSL-VPN Available in Port Filter: Yes- There must be a port filter rule:
Source |
Destination |
Service |
Logging
|
|---|---|---|---|
 ssl-vpn-user |
 internal-network |
 ssl-vpn |
None or Short, for debugging also Long |
does not come into effect or is aborted
| 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 | Menu If the packets sent to the UTM for the connection setup appear, but are dropped, the set of rules or the implicit rules of the appliance must be checked. |
 | |
| 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. |
Tab Recall Button |   |
| VERIFY ERROR | An error occurred during the verification of the CA | Menu Tab 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
|
| |
| 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
VPN tunnel is established, but 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
| 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 |
 | ||
| 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
| possible reason | checking | Problem description / Solution approach | |
|---|---|---|---|
| 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 | DROP: (DEFAULT DROP) 10.10.0.2:49874 → tun0 → eth1 192.168.175.22:80 |
| 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: Tab 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
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 |  |