K (||) |
K (||) |
||
Zeile 162: | Zeile 162: | ||
|} | |} | ||
---- | ---- | ||
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. | * Login auf der UTM per Terminal oder z.B. putty als root. | ||
* Paketsniffer starten {{code|tcpdump -i eth1 host 192.168.175.10 -nnp}} | * Paketsniffer starten {{code|tcpdump -i eth1 host 192.168.175.10 -nnp}} | ||
--- | |||
{| class="sptable pd5" | {| class="sptable pd5" | ||
Zeile 172: | Zeile 172: | ||
! mögliche Ursache !! Meldung im LOG !! Problembeschreibung / Lösungsansatz | ! mögliche Ursache !! Meldung im LOG !! Problembeschreibung / Lösungsansatz | ||
|- | |- | ||
| Host ist nicht erreichbar || ARP, Request who-has || 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 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. | |||
| class="bild width-m" rowspan="1"| {{Bild| Tcpdump_eth1-arp.png }} | | class="bild width-m" rowspan="1"| {{Bild| Tcpdump_eth1-arp.png }} | ||
|- | |- | ||
| Lokale Firewall || Sobald an dieser Stelle TCP/IP-Pakete zu sehen sind, ist der Zielhost erreichbar, da die Zustellung dieser Pakete einen erfolgreichen ARP-Request voraussetzt. Ist keine Antwort zu sehen, ist anzunehmen, dass auf dem Zielhost eine lokale Firewall aktiviert ist | | Lokale Firewall || 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. Ist keine Antwort zu sehen, ist anzunehmen, dass auf dem Zielhost eine lokale Firewall aktiviert ist | ||
| class="bild width-m" rowspan="1"| {{Bild| Tcpdump_eth1-icmp-echo.png }} | | class="bild width-m" rowspan="1"| {{Bild| Tcpdump_eth1-icmp-echo.png }} | ||
|- | |- | ||
| Subnetzmaske || 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 || ICMP echo request<br>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 | ||
| class="bild width-m" rowspan="1"| {{Bild| Tcpdump_eth1-subnetz.png }} | | class="bild width-m" rowspan="1"| {{Bild| Tcpdump_eth1-subnetz.png }} | ||
|- | |- | ||
| Defaultgateway || || Hat der Zielhost ein falsches Defaultgateway eingestellt, sind an der UTM die ARP-Requests für dieses Gateway sichtbar | | Defaultgateway || || Hat der Zielhost ein falsches Defaultgateway eingestellt, sind an der UTM die ARP-Requests für dieses Gateway sichtbar | ||
|} | |} |
Version vom 2. April 2020, 15:57 Uhr
mögliche Ursache | Prüfen | Lösungsansatz |
---|---|---|
Portfilter Regeln greifen nicht | Menü | blinktVorhandene Regeln müssen übernommen werden mit |
Grundsätzlich gilt:
Solange noch keine Verbindung aufgebaut wurde (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 | |
---|---|---|---|
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 | ||
TLS Error: TLS handshake failed
Wed Apr 01 16:12:37 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) ERROR: TLS error! See log for details Wed Apr 01 16:12:37 2020 TLS Error: TLS handshake failed Wed Apr 01 16:12:37 2020 SIGUSR1[soft,tls-error] received, process restarting Wed Apr 01 16:12:37 2020 Restart pause, 5 second(s) |
UTM verwirft die Pakete, die zum Verbindungsaufbau benötigt werden. | ||
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 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 jede Firewall-Regel 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:
Feld | Wert |
---|---|
Name | RW-Netz-Name |
Typ | VPN Netzwerk |
Adresse | Netzwerk-IP des Transfernetzes Ersichtlich im der Übersicht |
Zone | (Wird automatisch gewählt) vpn-ssl-xxx |
Es muss eine Portfilter Regel geben:
Quelle |
Ziel |
Dienst |
Logging
|
---|---|---|---|
RW-Netz-Name | internal-network | ssl-vpn | Short or Long |
Bei der Fehlersuche ergeben sich drei Möglichkeiten:
- Das gesuchte Paket taucht nicht auf
- Das gesuchte Paket taucht auf und es wird verworfen (DROP)
- Das gesuchte Paket taucht auf und es wird akzeptiert (ACCEPT)3
Dadurch kann die Fehlerursache zumindest grob lokalisiert werden:
- 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.
- 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
- Wenn ein Paket angenommen wird, dann liegt der Fehler in Richtung Zielhost.
mögliche Ursache | Prüfen | Problembeschreibung / Lösungsansatz |
---|---|---|
Pakete werden gedropt |
|
|
Pakete werden gedropt |
|
|
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
---