DE
Keine Ergebnisse gefunden
Wir konnten mit diesem Begriff nichts finden. Bitte versuche, nach etwas anderem zu suchen.
SSL VPN-Troubleshooting
{{var | Pakete werden verworfen--prüfen | Menü Troubleshooting-Guide um Problem be
{{var | Pakete werden verworfen–prüfen
| Menü
Troubleshooting-Guide um Problem bei einer SSL-VPN-Verbindung zu beheben
Letzte Anpassung zur Version: 12.6.0
Neu:
- Aktualisierung zum Redesign des Webinterfaces
notempty
Dieser Artikel beziehen sich auf eineResellerpreview
12.5.3
notempty
Dieser Leitfaden sollte Schrittweise abgearbeitet werden.
Wichtig ist dabei ein systematisches Vorgehen!
Erste Maßnahmen
| möglich Ursache | Prüfen | Lösungsansatz |
|---|---|---|
| Portfilter Regel greifen nicht | Menü Regel aktualisieren blinken | vorhanden Regel müssen übernehmen werden mitRegel aktualisieren |
Client Download nicht möglich
Userinterface wird nicht angezeigt
Benutzer kann sich nicht im Userinterface anmelden
| möglich Ursache | Prüfen | Lösungsansatz | 
|
|---|---|---|---|
| Benutzer wird durch FailToBan sperren | Menü BereichSperrungen | 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ü BereichBenutzer Schaltfläche SSL-VPN Client im Userinterface herunterladbar: Ja | Diese Option muss in den Benutzereinstellung aktivieren sein . FallsEinstellung aus der Gruppe verwenden : aktivieren wurde , muss diese Option in denGruppeneinstellung aktiviert sein. | 
|
Download-Option für den Client wird nicht angezeigt
| möglich Ursache | Prüfen | Lösungsansatz | 
|
|---|---|---|---|
| Benutzer / Gruppe hat keine Berechtigung | Menü BereichBenutzer Schaltfläche SSL-VPN Client im Userinterface herunterladbar: Ja | Diese Option muss in den Benutzereinstellung aktivieren sein . FallsEinstellung aus der Gruppe verwenden : aktivieren wurde , muss diese Option in denGruppeneinstellung aktiviert sein. | |
Verbindungsproblem
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-Client :
- Doppelklick auf Client-Icon in der Taskleiste
- Rechtsklick auf Verbindungseintrag
- Log (Größere Schrift mit StrgMausrad nach oben)
Auswertung des Netzwerk-Verkehr 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: BereichVPN SSL VPN UDP (ggf. TCP) Aus
- Es muss ein Netzwerkobjekt für die Roadwarrior geben: BereichGruppen ssl-vpn-user ( bzw. entsprechend 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 abbrechen
Verbindung
| Fehlermeldung | möglich 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 angezeigt IP-Adresse nicht erreichen . Es kommen keine Paket an . | Gegenprüfung auf der UTM:
|
|
|
| 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ü) 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. |
BereichWiderrufen Schaltfläche Entsperren des Zertifikats | 
|
| VERIFY ERROR | Ein Fehler bei der Verifizierung der CA . | Menü BereichZertifikate 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. |
|
|
| 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öglichkeit :
- 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 annehmen wird , dann liegen der Fehler in Richtung Zielhost .
Prüfung Client
Prüfung Client
| möglich Ursache | Prüfen | Problembeschreibung / Lösungsansatz | 
|
|---|---|---|---|
| Fehlende Routen | Commandozeil 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. | 
|
|
| Ergänzen der benötigten Netzwerke unter bearbeiten der genutzten Verbindung Reiter allgemein Servernetzwerke freigeben: Auswahl in der Clickbox von weiteren Netzwerken oder Eingabe einzeln Server . |
|
||
| Pakete verlassen den Client nicht |
|
Werden hier keine Pakete angezeigt, kommt auch nichts durch den Tunnel an. Ggf . prüfen , ob eine Client seitig oder dazwischen liegend Firewall die Paket filtern |
|
Prüfung Gateway
Prüfung Gateway
| möglich 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 Paketfiltermeldungo anzeigen | Finden sich hier Paket , die verwerfen werden , muss das Regelwerk anpassen werden | |
| Falsches Gateway für Tunnelverbindung | Livelog der UTM → Nur Applikations- und Kernelmeldung anzeigen | Findet sich hier die Meldung bad source address werden die entsprechenden Pakete verworfen. Das Gateway der SSL-VPN-Verbindung muss angepasst werden: BereichGruppe(bzw.Benutzer) Gruppe bzw. Benutzer bearbeiten ReiterSSL-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:
|
|||
| 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. |
|
|
| 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. |
|
| Hat der Zielhost ein anderer / falsch Defaultgateway einstellen , sind an der UTM die ARP-Request für dieses Gateway sichtbar | Defaultgateway im Zielhost überprüfen und ggf. korrigieren. Wird ein anderer Defaultgateway benötigen als dasjenige , über welches die SSL-VPN-Verbindung herstellen 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 ankommend ARP-Anfrag weiter eingrenzen . Hier versuchen der Zielhost , die MAC-Adresse des Quellhost zu ermitteln , was auf eine falsch Subnetzmaske schliessen lässt | Subnetzmaske im Zielhost überprüfen | 
|