SSL VPN-Troubleshooting

Troubleshooting-Guide um Probleme bei einer SSL-VPN-Verbindung zu beheben

Letzte Anpassung zur Version: 12.6.0

Neu:

Aktualisierung zum Redesign des Webinterfaces

notempty

Dieser Artikel bezieht sich auf eine Resellerpreview

12.5.3

notempty

Dieser Leitfaden sollte Schrittweise abgearbeitet werden.
Wichtig ist dabei ein systematisches Vorgehen!

Erste Maßnahmen

Mögliche Ursache	Prüfen	Lösungsansatz
Portfilter Regeln greifen nicht	Menü Firewall Paketfilter Regeln aktualisieren blinkt	Vorhandene Regeln müssen übernommen werden mit Regeln aktualisieren

Client Download nicht möglich

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

Userinterface wird nicht angezeigt

Mögliche Ursache	Prüfen	Lösungsansatz	Servereinstellungen UTMbenutzer@firewall.name.fqdnNetzwerk
Falscher Port für User Webinterface	Menü Netzwerk Servereinstellungen Bereich Servereinstellungen Webserver User Webinterface Port: 443	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

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 Paketfilter	Entweder der Zugriff auf das User Interface wird über die Impliziten Regeln freigegeben oder (besser) über dezidierte Portfilter Regeln.	Implizite Regeln UTMbenutzer@firewall.name.fqdnFirewall
			Implizite Regeln UTMbenutzer@firewall.name.fqdnFirewall
Im Regelwerk (DESTNAT) ist Port 443 schon belegt	Firewall Paketfilter 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	IDS/IPS UTMbenutzer@firewall.name.fqdnAnwendungen
Benutzer wird durch FailToBan gesperrt	Menü Anwendungen IDS / IPS Bereich Sperrungen	Evtl. wurde schon mehrmals das Kennwort für den Benutzernamen falsch eingegeben. Aktuelle Sperrung prüfen und ggf. entsperren

Benutzer / Gruppe hat keine Berechtigung	Menü Authentifizierung Benutzer Bereich Benutzer Schaltfläche SSL-VPN Client im Userinterface herunterladbar: Ja	Diese Option muss in den Benutzereinstellungen aktiviert sein. Falls Einstellungen aus der Gruppe verwenden: aktiviert wurde, muss diese Option in den Gruppeneinstellungen aktiviert sein.	Benutzer bearbeiten UTMbenutzer@firewall.name.fqdnAuthentifizierungBenutzer

Download-Option für den Client wird nicht angezeigt

Mögliche Ursache	Prüfen	Lösungsansatz	Benutzer bearbeiten UTMbenutzer@firewall.name.fqdnAuthentifizierungBenutzer
Benutzer / Gruppe hat keine Berechtigung	Menü Authentifizierung Benutzer Bereich Benutzer Schaltfläche SSL-VPN Client im Userinterface herunterladbar: Ja	Diese Option muss in den Benutzereinstellungen aktiviert sein. Falls Einstellungen aus der Gruppe verwenden: aktiviert wurde, muss diese Option in den Gruppeneinstellungen aktiviert sein.

Verbindungsprobleme

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 (Größere Schrift mit StrgMausrad nach oben)

Auswertung des Netzwerk-Verkehrs auf der UTM:

Für die Nutzung des Befehls tcpdump auf der UTM wird ein root-Benutzer benötigt.
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ässt 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 Regeln Bereich VPN SSL VPN UDP (ggf. TCP) Aus
- Es muss ein Netzwerkobjekt für die Roadwarrior geben: Authentifizierung Benutzer Bereich Gruppen ssl-vpn-user (bzw. entsprechende Gruppe) Bereich SSL-VPN Im Portfilter verfügbar: Ja
- Es muss eine Portfilter Regel geben:

		#	Quelle	Ziel	Dienst	NAT	Aktion	Aktiv
		4	ssl-vpn-user	internal-network	ssl-vpn		Accept	Ein

Kommt nicht zustande oder wird abgebrochen

Verbindung

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.
	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 lokale Netz? (Lokale Firewall?)
	Es kommen Pakete an, die aber sofort verworfen werden
TLS Error: TLS handshake failed TLS ERROR: TLS key negotiation failed	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 werden konnte. Hier wurde das Client-Zertifikat revoked.	Authentifizierung Zertifikate Bereich Widerrufen Schaltfläche Entsperren des Zertifikats
VERIFY ERROR	Ein Fehler bei der Verifizierung der CA.	Menü Authentifizierung Zertifikate Bereich 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 Benutzer Bereich 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.

Keine Verbindung zum Zielhost

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.
Bei der Fehlersuche ergeben sich drei Möglichkeiten:

Das gesuchte Paket taucht nicht auf
→ Ist kein Paket im Livelog sichtbar, dann kommt vermutlich auch keines an der Firewall an. Der Fehler ist hier also auf dem Client zu suchen.
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
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

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.
	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.
	Log-Datei im Client	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.	SSL-VPN UTMbenutzer@firewall.name.fqdnVPNSSL-VPN
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 Client seitige oder dazwischen liegende Firewall die Pakete filtert

Prüfung Gateway

Prüfung Gateway

Mögliche Ursache	Prüfen	Problembeschreibung / Lösungsansatz	DROP: (DEFAULT DROP) 10.10.0.2:49874 → tun0 → eth1 192.168.175.22:80
Pakete werden gedroped	Livelog der UTM → Nur Paketfiltermeldungen anzeigen	Finden sich hier Pakete, die verworfen werden, muss das Regelwerk angepasst werden
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 Benutzer Bereich 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

Prüfung Zielhost

Prüfung Zielhost

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
Meldung im LOG	Problembeschreibung	Lösungsansatz
ARP, Request who-has	Zielhost 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 Zielhost angeschaltet? Ist der Zielhost im angesprochenen Netz?

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.
ICMP echo request	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 ankommenden ARP-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