KKeine Bearbeitungszusammenfassung |
KKeine Bearbeitungszusammenfassung |
||
Zeile 58: | Zeile 58: | ||
Wird keine Verbindung aufgebaut (erkennbar an dem roten Schloss-Symbol in der Infoleiste), kann sich der Fehler nur auf der physikalischen Ebene befinden.</p> | Wird keine Verbindung aufgebaut (erkennbar an dem roten Schloss-Symbol in der Infoleiste), kann sich der Fehler nur auf der physikalischen Ebene befinden.</p> | ||
<p>Auswertung der Logdatei des SSL-VPN-Clients: | <p>'''Auswertung der Logdatei des SSL-VPN-Clients:''' | ||
* Doppelklick auf Client-Icon in der Taskleiste {{spc|vpn1|o|-|c=rot}} | * Doppelklick auf Client-Icon in der Taskleiste {{spc|vpn1|o|-|c=rot}} | ||
* Rechtsklick auf Verbindungseintrag | * Rechtsklick auf Verbindungseintrag |
Version vom 6. April 2020, 08:01 Uhr
mögliche Ursache | Prüfen | Lösungsansatz |
---|---|---|
Portfilter Regeln greifen nicht | Menü | blinktVorhandene Regeln müssen übernommen werden mit |
Client Download nicht möglich
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
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:
Es kommen keine Pakete an.
|
|||
Es kommen Pakete an, die aber sofort verworfen werden | Menü 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. |
|||
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ü ) zeigt bei den Applikations-und Kernelmeldungen eine Fehlermeldung, die besagt, dass das Zertifikat des Clients nicht verifiziert werdenkonnte. Hier wurde das Client-Zertifikat revoked |
Wiederrufen Schaltfläche | Reiter||
VERIFY ERROR | Ein Fehler bei der Verifizierung der CA | Menü Zertifikate Verwenden Server-Zertifikat und Client-Zertifikat die gleiche CA? Ist die CA noch gültig? | Reiter ||
ERROR: Received AUTH_FAILED Control Message | Benutzerauthentifizierung fehlgeschlagen
oder
|
| ||
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 | ||
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: Reiter VPN SSL VPN UDP (ggf. TCP) Aus
Es muss ein Netzwerkobjekt für die Roadwarrier geben:
Reiter 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
|
---|---|---|---|
ssl-vpn-user | internal-network | ssl-vpn | Short or Long |
Bei der Fehlersuche ergeben sich drei Möglichkeiten:
- 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. - 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.
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: Gruppen (bzw.Benutzer) Gruppe bzw. Benutzer bearbeiten Reiter SSL-VPN Remote Gateway: Auswahl des Gateways, über das der Client die Verbindung herstellt | Reiterm.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