Jump to:navigation, search
Wiki

Die Seite Vorlage:Ui-icon.css hat keinen Inhalt.



























































































De.png
Fr.png


Troubleshooting guide to resolve problems with an SSL VPN connection.

New article 04.2020 11.8.8


A systematic approach is important
This guide should be worked through step by step.



First measures

First measures
possible reason checking Solution approach
Port filter rules do not work Menu → Firewall →Port Filter Refresh Rules is flashing Existing rules must be taken over with Update Rules



UTM v11.8.8 Userinterface RW-en.png

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: 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 UTM v11.8.8 Netzwerk Servereinstellungen Webserver-en.png
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. UTM v11.8.8 SSL-VPN RW-Implied-Rules-en.png
Port 443 is already occupied in the set of rules (DESTNAT) → Firewall →Portfilter 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

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
UTM v11.8.8 Anwendungen IDS-IPS Sperrungen-user-en.png
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). UTM v11.8.8 Authentifizierung Benutzer Gruppen RW Berechtigung-en.png


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-VPN 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.

UTM v11.8.8 Authentifizierung Benutzer Client-en.png



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 VPN SSL VPN UDP (possibly TCP) Off

    There must be a network object for the roadwarriors:→ Authentication →UserTab 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 ╶╮
Ipsetgroup.svg  ssl-vpn-user Network.svg  internal-network Service-group.svg  ssl-vpn Short or Long

does not come into effect or is aborted

Connection
SSL-VPN-CLient Error.PNG

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. UTM v11.8.8 tcpdump ssl-vpn.PNG
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 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.
UTM v11 Logdateien SSL-VPN.png
TLS Error: TLS handshake failed
TLS ERROR: TLS key negotiation faied
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 →CertificatesTab 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 →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 SSL-VPN-Client Error TAP-Treiber-fehlen.PNG



No connection to the target host

VPN tunnel is established, but 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
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. SSL-VPN Routen.PNG
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
UTM v11.8.8 SSL-VPN Servernetzwerke-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
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: → Authentication →UsersTab 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
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?
Tcpdump eth1-arp.png
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