Fortigate VPN Debug log
Hallo zusammen,
ich steh anscheint auf dem schlauch, was der Fortinet Support von mir möchte. Er schreibt ich soll die CLI befehle absetzten.
melde mich also an der Fortigate an, webclient oder Seriel führe die befehle aus. lade die logs hoch aber es waren die Falschen
Die Fehler Beschreibung ist das sich nicht 2 Personen vom gleichen Gateway ins VPN netz einwählen können.
Auswirkung
Person1 5.1.1.1 wählt sich ins VPN ein. Erfolgreich
Person2 gleiche ip 5.1.1.1 wählt sich ein, Person1 fliegt raus oder Person2 kommt gar nicht erst rein.
Fortinet Support Antwort
Please run the following debug flow:
Connect the first user and after connect the second one in order to catch the behavior.
I am suspecting that might be a problem with the NATing device and what are you experiencing is actually an expected behavior.
Please attach the debug flow for further troubleshooting.
Hab das ausgeführt und dann auch nach und nach die VPN Benutzer verbunden.
Gibt es irgend wo eine Extra Log für den debugfile ?
ich steh anscheint auf dem schlauch, was der Fortinet Support von mir möchte. Er schreibt ich soll die CLI befehle absetzten.
melde mich also an der Fortigate an, webclient oder Seriel führe die befehle aus. lade die logs hoch aber es waren die Falschen
Die Fehler Beschreibung ist das sich nicht 2 Personen vom gleichen Gateway ins VPN netz einwählen können.
Auswirkung
Person1 5.1.1.1 wählt sich ins VPN ein. Erfolgreich
Person2 gleiche ip 5.1.1.1 wählt sich ein, Person1 fliegt raus oder Person2 kommt gar nicht erst rein.
Fortinet Support Antwort
Please run the following debug flow:
diag vpn ike log-filter clear
diag debug console timestamp en
diag debug app ike -1
diag vpn ike log-filter name <phase1 name>
diag debug enable
I am suspecting that might be a problem with the NATing device and what are you experiencing is actually an expected behavior.
Please attach the debug flow for further troubleshooting.
Hab das ausgeführt und dann auch nach und nach die VPN Benutzer verbunden.
Gibt es irgend wo eine Extra Log für den debugfile ?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 493720
Url: https://administrator.de/forum/fortigate-vpn-debug-log-493720.html
Ausgedruckt am: 23.12.2024 um 02:12 Uhr
4 Kommentare
Neuester Kommentar
Leider schreibst du nicht welches VPN Protokoll verwendet wird. Vermutlich aber GRE oder IPsec. Beiden ist gemein das sie jeweils ein Session loses Prokoll für den eigentlichen Tunnel nutzen. GRE (Generic Route Encapsulation, IP Protokoll 47) oder bei IPsec ESP (Encapsulation Security Payload, IP Protokoll 50)
Billige NAT Router wie sie vermutlich bei dir auf der Client Seite zum Einsatz kommen haben meist dann kein ALG in deren Firewall an Bord die diese VPN Tunnelprotokolle pro User trackt um einem Mehrfach VPN Client Betrieb zu supporten.
Das ist leider nicht ungewöhnlich z.B. bei den billigen Schrottroutern die man von Providern bekommt.
Das Fortinet TAC hat also schon ganz recht in der Vermutung der Ursache im NAT Router. Alle Symptome sprechen stark dafür.
Diese Billig Schrottrouter können immer nur eine einzige GRE oder ESP Session outbound im NAT halten. Alle weiteren werden geblockt weil sie sie nicht mehr multiplen VPN Clients zuordnen können. First come, first serve heisst da die Devise in der Firmware.
Nach Abbruch der Tunnel Session oder Schliessen der VPN Verbindung bleibt diese noch eine Zeitlang im Cache so das keine weiteren User VPNs nutzen können. Erst nach einem Timeout des Caches funktioniert es dann wieder.
Ein typisches Verhalten und Firmware bedingt bei billigen Systemen !
Lösen kannst du das letztlich nur durch neue und bessere Router Hardware am Client Standort. Ggf. hilft auch ein Firmware Update sollte die Router Firmware nicht aktuell sein.
Die Chancen das es nur mit einem Firmware Update gefixt wird sind aber mehr als gering, denn bei solchen billigen Schrottsystemen wird in der Regel niemals mehr eine neue Funktion eingeführt oder verbessert.
Sowas darf den, der sie meistens im Rahmen von Verträgen weiterreicht, natürlich nichts mehr kosten. Die sind einzig nur an langfristigen Vertragsbindungen interessiert, niemals Kunden mit guter Hardware zu beliefern.
Billige NAT Router wie sie vermutlich bei dir auf der Client Seite zum Einsatz kommen haben meist dann kein ALG in deren Firewall an Bord die diese VPN Tunnelprotokolle pro User trackt um einem Mehrfach VPN Client Betrieb zu supporten.
Das ist leider nicht ungewöhnlich z.B. bei den billigen Schrottroutern die man von Providern bekommt.
Das Fortinet TAC hat also schon ganz recht in der Vermutung der Ursache im NAT Router. Alle Symptome sprechen stark dafür.
Diese Billig Schrottrouter können immer nur eine einzige GRE oder ESP Session outbound im NAT halten. Alle weiteren werden geblockt weil sie sie nicht mehr multiplen VPN Clients zuordnen können. First come, first serve heisst da die Devise in der Firmware.
Nach Abbruch der Tunnel Session oder Schliessen der VPN Verbindung bleibt diese noch eine Zeitlang im Cache so das keine weiteren User VPNs nutzen können. Erst nach einem Timeout des Caches funktioniert es dann wieder.
Ein typisches Verhalten und Firmware bedingt bei billigen Systemen !
Lösen kannst du das letztlich nur durch neue und bessere Router Hardware am Client Standort. Ggf. hilft auch ein Firmware Update sollte die Router Firmware nicht aktuell sein.
Die Chancen das es nur mit einem Firmware Update gefixt wird sind aber mehr als gering, denn bei solchen billigen Schrottsystemen wird in der Regel niemals mehr eine neue Funktion eingeführt oder verbessert.
Sowas darf den, der sie meistens im Rahmen von Verträgen weiterreicht, natürlich nichts mehr kosten. Die sind einzig nur an langfristigen Vertragsbindungen interessiert, niemals Kunden mit guter Hardware zu beliefern.
Mmmhhh...die sollte eigentlich damit umgehen können ?! Ist das eine originale oder hat die eine gebrandete Firmware eines Providers, ist also eine Vertrags Dreingabe ?
Das Sinnvollste ist dann dort mal die Packet Capture Funktion der FB zu nutzen:
https://www.schieb.de/706106/fritzbox-packet-sniffer-die-versteckte-schn ...
und mal den ESP Traffic beider User mitzuschneiden um zu sehen was damit genau passiert nach dem NAT Prozess der FritzBox.
Das würde sicher auch dem Fortigate TAC sehr helfen.
Das Sinnvollste ist dann dort mal die Packet Capture Funktion der FB zu nutzen:
https://www.schieb.de/706106/fritzbox-packet-sniffer-die-versteckte-schn ...
und mal den ESP Traffic beider User mitzuschneiden um zu sehen was damit genau passiert nach dem NAT Prozess der FritzBox.
Das würde sicher auch dem Fortigate TAC sehr helfen.