SSL VPN-Troubleshooting

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

notempty

This article refers to a Resellerpreview

12.5.3

notempty

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 Firewall Packetfilter Refresh Rules is flashing	Existing rules must be taken over with Update Rules

Client download not possible

SSL-VPN Client Download UTMuser@firewall.name.fqdnfirewall-user

User interface is not displayed

show details

User cannot log in to the user interface

show details

Download option for the client is not displayed

show details

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: → Firewall →Implicit RulesTab VPN SSL VPN UDP (possibly TCP) Off
- There must be a network object for the roadwarriors: Authentication User 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

Connection

show details

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
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 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.	Authentication Certificates Area Recall Button Unblock Certificate
VERIFY ERROR	An error occurred during the verification of the CA	Menu Authentication Certificates 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.	Assign a new password for the user if the old one is no longer available. Authentication Users Area 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

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

show details

Check Gateway

Check Gateway

show details

Check target host

Check target host

show details

Possible reason	Checking	Solution approach	Server settings UTMuser@firewall.name.fqdnNetwork
Wrong port for user web interface	Menu Network Appliance Settings 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.	Implizide rules UTMuser@firewall.name.fqdnFirewall
			Implizide rules UTMuser@firewall.name.fqdnFirewall
Port 443 is already occupied in the set of rules (DESTNAT)	Firewall Packetfilter https	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.

Possible reason	Checking	Solution approach	IDS/IPS UTMuser@firewall.name.fqdnApplications
User is locked out by FailToBan	Menu Applications IDS / IPS 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 Authentication User Area User Button SSL-VPN 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.	Edit user UTMuser@firewall.name.fqdnAuthenticationUser
			Edit user UTMuser@firewall.name.fqdnAuthenticationUser

Possible reason	Checking	Solution approach	Edit user UTMuser@firewall.name.fqdnAuthenticationUser
User / group has no authorization	Menu Authentication User Area User Button SSL-VPN 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.

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.
	Log file in the client	Add the required networks under VPN SSL-VPN Edit the used connection Tab General Share Server Networks: Select additional networks in the clickbox or enter individual servers	SSL-VPN UTMuser@firewall.name.fqdnVPNSSL-VPN
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

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: Authentication Users 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

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. Start packetsniffer tcpdump -i eth1 host 192.168.175.10 -nnp
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.	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.
ICMP echo request	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