Wechseln zu:Navigation, Suche
Wiki




























Erste Maßnahmen
mögliche Ursache Prüfen Lösungsansatz
Portfilter Regeln greifen nicht Menü → Firewall →Portfilter Regeln aktualisieren blinkt Vorhandene Regeln müssen übernommen werden mit Regeln aktualisieren

UTM v11.8.8 Userinterface RW.png

Client Download nicht möglich

Userinterface wird nicht angezeigt
mögliche Ursache Prüfen Lösungsansatz
Falscher Port für User Webinterface Menü → Netzwerk →ServereinstellungenReiter Servereinstellungen Kasten
Webserver
User Webinterface Port: 443Link=
Ist hier ein anderer Wert als Port 443 (https) eingetragen, muss der Port im URL des Browsers mit angegeben werden, z.B.: firewall.ttt-point.de:xxx UTM v11.8.8 Netzwerk Servereinstellungen Webserver.png
Die UTM befindet sich hinter einem Router (Fritzbox etc.) Beispiel Fritzbox: Menü Internet / Freigaben / Portfreigaben Die Fritzbox bzw. der Router muss eine Portweiterleitung zur externen IP-Adresse der UTM zulassen.
Zugriff auf Port 443 ist nicht freigegeben Menü → Firewall →Implizite Regeln
oder (besser)
→ Firewall →Portfilter
Entweder der Zugriff auf das User Interface wird über die Impliziten Reglen freigegeben oder (besser) über dezidierte Portfilter Regeln. UTM v11.8.8 SSL-VPN RW-Implied-Rules.png
Im Regelwerk (DESTNAT) ist Port 443 schon belegt → Firewall →Portfilter https     Der Port für das Userinterface muss geändert werden
Reverse Proxy für https eingerichtet Menü → Anwendungen →Reverse Proxy Wurde ein Reverse Proxy auch für https eingerichtet, muss der Port für das Userinterface geändert werden


Benutzer kann sich nicht im Userinterface anmelden
mögliche Ursache Prüfen Lösungsansatz
Benutzer wird durch FailToBan gesperrt Menü → Anwendungen →IDS / IPSReiter Sperrungen Evtl. wurde schon mehrmals das Kennwort für den Benutzernamen falsch eingegeben.
Aktuelle Sperrung prüfen und ggf. entsperren
UTM v11.8.8 Anwendungen IDS-IPS Sperrungen-user.png
Benutzer hat keine Berechtigung Menü → Authentifizierung →BenutzerReiter Gruppen
In welcher Gruppe ist der Benutzer?
Welche Berechtigungen hat die Gruppe des Benutzers?
Der Benutzer muss Mitglied einer Gruppe sein, die auf das Userinterface zugreifen darf (und über die SSL-VPN-Berechtigung verfügt). UTM v11.8.8 Authentifizierung Benutzer Gruppen RW Berechtigung.png


Download-Option für den Client wird nicht angezeigt
mögliche Ursache Prüfen Lösungsansatz
Benutzer / Gruppe hat keine Berechtigung Menü → Authentifizierung →BenutzerReiter Benutzer Schaltfläche SSL-VPN Client im Userinterface herunterladbar: Ja

Diese Option muss in den Benutzereinstellungen Ja aktiviert sein.

Falls Einstellungen aus der Gruppe verwenden: Ja aktiviert wurde, musse diese Option in den Gruppeneinstellungen Ja aktiviert sein.

UTM v11.8.8 Authentifizierung Benutzer Client.png



Grundsätzlich gilt:
Wird keine Verbindung aufgebaut (erkennbar an dem roten Schloss-Symbol in der Infoleiste), kann sich der Fehler nur auf der physikalischen Ebene befinden.

Auswertung der Logdatei des SSL-VPN-Clients:

  • Doppelklick auf Client-Icon in der Taskleiste
  • Rechtsklick auf Verbindungseintrag
  • Log


Verbindung kommt nicht zustande
SSL-VPN-CLient Error.PNG
mögliche Ursache Prüfen Lösungsansatz
Unter der konfigurierten IP ist die UTM nicht zu erreichen Log im Client
Meldung: link remote: [AF_INET] 192.0.2.192:1194
Gehen die Meldungen über link remote nicht hinaus (bzw. gefolgt von TLS Error: TLS key negotiation failed), kann der Client die UTM unter der im Client-Log angezeigten IP-Adresse nicht erreichen.
  • IP-Adresse der angesprochenen Schnittstelle in der UTM überprüfen
  • Verlassen die Pakete überhaupt den lokalen Rechner / das okale Netz? (Lokale Firewall?)
SSL-VPN-Client Link-remote.PNG
Es kommen keine Pakete an der UTM an
  • Login auf der UTM per Terminal oder z.B. putty als root.
  • Paketsniffer starten tcpdump -ni eth0 port 1194
Kommen keine Pakete an, befindet sich der Initiator der Verbindung sehr wahrscheinlich selber hinter einer Firewall, die den Port 1194 nicht ins Internet lässt. UTM v11.8.8 tcpdump ssl-vpn.PNG
Es kommen Pakete an, die aber sofort verworfen werden Menü → Log  Tauchen die für den Verbindungsaufbau an die UTM gesendeten Pakete auf, weil sie vom Regelwerk der Appliance verworfen werden, sind das Regelwerk bzw. die impliziten Regeln zu überprüfen. UTM v11 Logdateien SSL-VPN.png




Verbindung kommt nicht zustande oder wird abgebrochen
SSL-VPN-CLient Error.PNG
Fehlermeldung mögliche Ursache Lösungsansatz
link remote: [AF_INET] 192.0.2.192:1194
TLS Error: TLS key negotiation failed
Der Verbindungsaufbau kommt nicht zustande. SSL-VPN-Client Link-remote.PNG
Der Client kann die UTM unter der im Client-Log angezeigten IP-Adresse nicht erreichen. Es kommen keine Pakete an. Gegenprüfung auf der UTM:
  • Login auf der UTM per Terminal oder z.B. putty als root.
  • Paketsniffer starten tcpdump -ni eth0 port 1194

Es kommen keine Pakete an:

  • IP-Adresse der angesprochenen Schnittstelle in der UTM überprüfen
  • Verlassen die Pakete überhaupt den lokalen Rechner / das okale Netz? (Lokale Firewall?)
UTM v11.8.8 tcpdump ssl-vpn.PNG
Es kommen Pakete an, die aber sofort verworfen werden Menü → Log 
Tauchen die für den Verbindungsaufbau an die UTM gesendeten Pakete auf, werden aber gedroped, sind das Regelwerk bzw. die impliziten Regeln der Appliance zu überprüfen.
UTM v11 Logdateien SSL-VPN.png
TLS Error: TLS handshake failed
TLS ERROR: TLS key negotiation faied
Die Authentifizierung schlägt fehl
Es wurde eine Verbindung initiiert und das Serverzertifikat vom Client verifiziert. Der Verbindungsaufbau bricht aber mit einem Timeout ab. Das Livelog des Gateways (UTM Menü → LOG ) zeigt bei den Applikations-und Kernelmeldungen eine Fehlermeldung, die besagt, dass das Zertifikat des Clients nicht verifiziert werdenkonnte. Hier wurde das Client-Zertifikat revoked
→ Authentifizierung →ZertifikateReiter Wiederrufen Schaltfläche Entsperren des Zertifikats SSL-VPN 2016 Kein Zertifikat2.png

UTM v11 Log SSL-VPN Kein-Zertifikat2.png
VERIFY ERROR Ein Fehler bei der Verifizierung der CA Menü → Authentifizierung →ZertifikateReiter Zertifikate Verwenden Server-Zertifikat und Client-Zertifikat die gleiche CA?
Ist die CA noch gültig?
ERROR: Received AUTH_FAILED Control Message Benutzerauthentifizierung fehlgeschlagen
  • Username und Passwort stimmen nicht überein

oder

  • die Berechtigung zum Aufbau einer SSL VPN-Verbindung fehlt.
  • Neues Kennwort für den Benutzer vergeben, falls das alte nicht mehr vorliegen sollte.
  • → Authentifizierung →BenutzerReiter Gruppen Schaltfläche   Berechtigungen SSL-VPN-Berechtigung für die Gruppe des Benutzers erteilen
ERROR: There are not TAP-Windows adapters on this system

ERROR: Application Exiting!

fehlender Tap-Treiber Installation der aktuellsten Version des Clients aus dem Reseller-Portal oder im Userinterface der UTM. Diese Versionen beinhalten einen aktuellen TAP-Treiber SSL-VPN-Client Error TAP-Treiber-fehlen.PNG

SSL-VPN-CLient Connected.PNG

Wird eine bestehende Verbindung angezeigt, liegt der Fehler nicht mehr im Verbindungsaufbau. Sollte nun eine Verbindung durch den Tunnel nicht zustande kommen (z.B. PING auf einen Host im Netzwerk hinter dem Gateway), ist die Ursache auf der virtuellen Ebene zu suchen. Auch hier ist es eine gute Idee, zunächst das Portfilter-Regelwerk zu aktualisieren und einen Blick ins Livelog zu werfen.
Das Livelog zeigt per Default Meldungen des Paketfilters an. Standardmäßig ist allerdings nur zu sehen, wenn die Default Policy Pakete verwirft, für die es keine passende Firewall-Regel gibt. Es läßt sich aber für selbst angelegte Firewall-Regeln das Logging konfigurieren, so daß auch ein Eintrag erscheint, wenn diese Regel greift.
Dazu wird die zugehörige implizite Regel deaktiviert: → Firewall →Implizite RegelnReiter VPN SSL VPN UDP (ggf. TCP) Aus

Es muss ein Netzwerkobjekt für die Roadwarrier geben: → Authentifizierung →BenutzerReiter Gruppen ssl-vpn-user (bzw. entsprechende Gruppe) Reiter SSL-VPN Im Portfilter verfügbar: Ja


Es muss eine Portfilter Regel geben:

Quelle
Ziel
Dienst
Logging
Ipsetgroup.svg ssl-vpn-user Network.svg internal-network Service-group.svg ssl-vpn Short or Long



Bei der Fehlersuche ergeben sich drei Möglichkeiten:

  1. Das gesuchte Paket taucht nicht auf
    → Ist kein Paket im Livelog sichtbar, dann kommt vermutlich auch keins an der Firewall an. Der Fehler ist hier also auf dem Client zu suchen.

  2. Das gesuchte Paket taucht auf und es wird verworfen (DROP)
    → Wenn ein Paket verworfen wird, fehlt die passende FW-Regel, sie ist inkorrekt formuliert oder noch nicht wirksam (Regelwerk noch nicht aktualisiert). Der Fehler liegt also auf dem Gateway

  3. Das gesuchte Paket taucht auf und es wird akzeptiert (ACCEPT)
    → Wenn ein Paket angenommen wird, dann liegt der Fehler in Richtung Zielhost.


Prüfung Client
mögliche Ursache Prüfen Problembeschreibung / Lösungsansatz
fehlende Routen Commandozeile im Client: route print Finden sich die korrekten Routingeinträge dort nicht, muss im Log des VPN-Clients geprüft werden, ob sie vom Server übertragen oder ob sie nicht korrekt gesetzt werden konnten. SSL-VPN Routen.PNG
Log-Datei im Client Wurden die Routen nicht korrekt übertragen, müssen sie in den Einstellungen des SSL VPN-Servers ergänzt bzw. korrigiert werden. Im Beispiel wurde die Route zum Subnetz 10.20.30.0/24 korrekt übergeben. SSL-VPN Client Routen-geladen.PNG
Ergänzen der benötigten Netzwerke unter → VPN →SSL-VPN bearbeiten der genutzten Verbindung Reiter Allgemein Servernetzwerke freigeben:
Auswahl in der Clickbox von weiteren Netzwerken oder Eingabe einzelner Server
UTM v11.8.8 SSL-VPN Servernetzwerke.png
Pakete verlassen den Client nicht
  • Login auf der UTM per Terminal oder z.B. putty als root.
  • Paketsniffer starten tcpdump -i tun0 -nnp
Werden hier keine Pakete angezeigt, kommt auch nichts durch den Tunnel an.

Ggf. prüfen, ob eine Clientseitige oder dazwischen liegende Firewall die Pakete filtert


Prüfung Gateway
mögliche Ursache Prüfen Problembeschreibung / Lösungsansatz
Pakete werden gedropt Livelog der UTM → Nur Paketfiltermeldungen anzeigen Finden sich hier Pakete, die verworfen werden, muss das Regelwerk angepasst werden DROP: (DEFAULT DROP) 10.10.0.2:49874 → tun0 → eth1 192.168.175.22:80
Falsches Gateway für Tunnelverbindung Livelog der UTM → Nur Applikations- und Kernelmeldungen anzeigen Findet sich hier die Meldung bad source address werden die entsprechenden Pakete verworfen. Das Gateway der SSL-VPN-Verbindung muss angepasst werden: → Authentifizierung →BenutzerReiter Gruppen (bzw.Benutzer) Gruppe bzw. Benutzer bearbeiten Reiter SSL-VPN Remote Gateway: Auswahl des Gateways, über das der Client die Verbindung herstellt m.mueller/192.168.178.114:62242 MULTI: bad source address from client [::] packet dropped
Pakete werden accepted Livelog der UTM Finden sich Pakete, die nicht verworfen werden, muss das Problem beim Zielhost liegen

Die Kommunikation zum Zielhost kann mit dem Paketsniffer tcpdump auf der zugehörigen Schnittstelle der UTM verfolgt werden:

  • Login auf der UTM per Terminal oder z.B. putty als root.
  • Paketsniffer starten tcpdump -i eth1 host 192.168.175.10 -nnp

Prüfung Zielhost
Meldung im LOG Problembeschreibung Lösungsansatz
ARP, Request who-has Host ist nicht erreichbar
Ist der Zielhost physikalisch nicht erreichbar, sind am internen Interface keine IP-Pakete sichtbar, wohl aber ARP-Requests, die das Gateway zur Ermittlung der MAC-Adresse des Zielhosts verschickt. Diese werden nicht beantwortet.
  • Ist der Host angeschaltet?
  • Ist der Host im angesprochenen Netz?
Tcpdump eth1-arp.png
ICMP echo request Sobald an dieser Stelle TCP/IP-Pakete zu sehen sind, ist der Zielhost erreichbar, da die Zustellung dieser Pakete einen erfolgreichen ARP-Request voraussetzt. Es kommen jedoch keine Paket zurück. Ist auf dem Zielhost eine lokale Firewall aktiviert?
Lokale Firewall prüfen
Tcpdump eth1-icmp-echo.png
Hat der Zielhost ein anderes / falsches Defaultgateway eingestellt, sind an der UTM die ARP-Requests für dieses Gateway sichtbar Defaultgateway im Zielhost überprüfen und ggf. korrigieren.
Wird ein anderes Defaultgateway benötigt als dasjenige, über welches die SSL-VPN-Verbindung hergestellt wird muss eine Route für das Transfernetz im Zielhost eintragen werden.
ICMP echo request
ARP, Request who-has
Fehler in der Netzwerkkonfiguration lassen sich anhand der an der UTM ankommendenARP-Anfragen weiter eingrenzen. Hier versucht der Zielhost, die MAC-Adresse des Quellhosts zu ermitteln, was auf eine falsche Subnetzmaske schliessen lässt Subnetzmaske im Zielhost überprüfen Tcpdump eth1-subnetz.png