Troubleshooting guide to resolve problems with an SSL VPN connection.
Last adaption: 04.2020 11.8.8
notempty
This article refers to a Resellerpreview
-
This guide should be worked through step by step.
A systematic approach is important
First measures
First measures
possible reason
checking
Solution approach
Port filter rules do not work
Menu → Firewall →Port FilterRefresh Rules is flashing
Existing rules must be taken over with Update Rules
Client download not possible
Client download not possible
User interface is not displayed
User interface is not displayed
possible reason
checking
Solution approach
Wrong port for user web interface
Menu → Network →Appliance Settings 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 → Firewall →Implicit Rules or (better) → Firewall →Port Filter
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)
→ Firewall →Portfilterhttps
The port for the user interface must be changed
Reverse proxy set up for https
Menu → Applications →Reverse Proxy
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
User cannot log in to the user interface
possible reason
checking
Solution approach
User is locked by FailToBan
Menu → Applications →IDS / IPSTab 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 → Authentication →UsersTab 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
Download option for the client is not displayed
possible reason
checking
Solution approach
User / group has no authorization
Menu → Authentication →UserTab User Button SSL-VPNClient downloadable in user interface:Yes
This option must be enabled in the User PreferencesYes.
If Use group settings:Yes has been enabled, this option must be enabled in the Group PreferencesYes.
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: → Firewall →Implicit RulesTab VPNSSL VPN UDP (possibly TCP) Off
There must be a network object for the roadwarriors:→ Authentication →UserTab Groupsssl-vpn-user (or corresponding group) Tab SSL-VPNAvailable 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
Connection
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:
Login on the UTM via terminal or e.g. putty as root.
Start packet sniffer tcpdump -ni eth0 port 1194 No packets arrive.
Check the IP address of the addressed interface in the UTM
Do the packets ever leave the local machine / network? (Local Firewall?)
Packages arrive, but are discarded immediately
Menu → Log 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.
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 → LOG ) 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.
An error occurred during the verification of the CA
Menu → Authentication →CertificatesTab 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.
Assign a new password for the user if the old one is no longer available.
→ Authentication →UsersTab Groups Button Permissions Assign SSL VPN permission for the user's group
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
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 → VPN →SSL-VPN Edit the used connection Tab GeneralShare Server Networks: Select additional networks in the clickbox or enter individual servers
Packages do not leave the client
Login to the UTM via terminal or e.g. putty as root.
Start packetsniffer tcpdump -i tun0 -nnp
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
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
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: → Authentication →UsersTab Groups (or Users) Edit Group or User Tab SSL-VPNRemote Gateway:Select the Gateway the Client will connect through
m.mueller/192.168.178.114:62242MULTI: 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:
Login on the UTM via terminal or e.g. putty as root.
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.
Is the target host powered up?
Is the target host in the addressed network?
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