Jump to:navigation, search
Wiki





























De.png
En.png
Fr.png






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 UTM v12.6.0 Userinterface RW-en.png

User interface is not displayed

Possible reason Checking Solution approach Server settings UTMuser@firewall.name.fqdnNetwork UTM v12.6.0 Netzwerk Servereinstellungen Webserver-en.png
Wrong port for user web interface Menu Network Appliance Settings
Webserver
User Webinterface Port: 443Link=
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 UTM v12.6.0 Firewall Implizite Regeln SSL-VPN-RW-en.png
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.


User cannot log in to the user interface

Possible reason Checking Solution approach IDS/IPS UTMuser@firewall.name.fqdnApplications UTM v12.6.0 Anwendungen IDS-IPS Sperrungen-user-en.png
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 UTM v12.6.0 Authentifizierung Benutzer SSL-VPN-en.png


Download option for the client is not displayed

Possible reason Checking Solution approach Edit user UTMuser@firewall.name.fqdnAuthenticationUser UTM v12.6.0 Authentifizierung Benutzer SSL-VPN-en.png
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.


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
Dragndrop.png 4 Ipsetgroup.svg ssl-vpn-user Network.svg internal-network Service-group.svg ssl-vpn Accept On


Does not come into effect or is cancelled

SSL-VPN-CLient Error.PNG


Connection
Error message Possible reason Solution approach SSL-VPN-Client Link-remote.PNG
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?)
UTM v11.8.8 tcpdump ssl-vpn.PNG
Packages arrive, but are discarded immediately UTM v11 Logdateien SSL-VPN.png
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 SSL-VPN 2016 Kein Zertifikat2.png

UTM v11 Log SSL-VPN Kein-Zertifikat2.png
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. SSL-VPN-Client Error TAP-Treiber-fehlen.PNG


No connection to the target host

SSL-VPN-CLient Connected.PNG

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:

  1. 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.
  2. 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
  3. 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 SSL-VPN Routen.PNG
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. SSL-VPN Client Routen-geladen.PNG
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 UTM v12.6.0 SSL-VPN RW Servernezwerke-en.png
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 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


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.
  • Start packetsniffer tcpdump -i eth1 host 192.168.175.10 -nnp
Message in the LOG Problem description Solution approach Tcpdump eth1-arp.png
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.
Tcpdump eth1-icmp-echo.png
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 Tcpdump eth1-subnetz.png