Wir haben einen Kunden mit 6 Standorten, die IPsec verwenden. Hin und wieder, möglicherweise einmal pro Woche, manchmal einmal pro Monat, wird die Datenübertragung vom Remote-Fortigate-VPN-Server zum lokalen MikroTik IPsec-VPN-Client unterbrochen.
Um die Symptome des Problems zu demonstrieren, habe ich ein Diagramm angehängt. Auf der Registerkarte „Installierte SAs“ des Diagramms sehen Sie eine Quell-IP-Adresse xx186.50, die versucht, mit xx7.3 zu kommunizieren, aber 0 aktuelle Bytes hat. xx186.50 ist der Remote-Fortigate-IPsec-Server des Clients und xx7.73 ist ein MikroTik-basierter IPsec-Endpunkt. Es scheint, dass die Daten von der Remote-Seite nicht immer zu uns fließen.
Phase 1 und 2 werden immer hergestellt, aber der Datenverkehr wird immer verweigert, von der Remote-Seite zu uns zu fließen.
Wir haben im Laufe der Zeit verschiedene Dinge ausprobiert, z. B. Neustart, Uhren einstellen, an der Konfiguration herumspielen, die Konfiguration immer wieder überprüfen, aber es scheint, dass das Problem völlig zufällig ist. Und manchmal lösen zufällige Dinge das Problem. Irgendwann hatte ich die Theorie, dass es funktioniert, wenn der Tunnel von ihrer Seite aus initiiert wird, aber das Herumspielen mit „Erstkontakt senden“ hat keinen Unterschied gemacht.
Wir haben mit dem Kunden oft darüber gechattet, aber er hat viel mehr internationale IPsec-VPNs und nur unsere MikroTik-Konfiguration schlägt fehl.
Fortigate-Protokoll:
http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654
Wenn man sich die Wissensdatenbank von Fortigate ansieht, scheint es, dass die SPIs nicht übereinstimmen und DPD einen Unterschied machen würde. Aber ich habe jede einzelne DPD-Kombination auf dieser Seite ohne Erfolg ausprobiert. Ich würde DPD gerne auf der anderen Seite aktivieren, aber ich kann es aufgrund der Änderungskontrolle nicht und auch, weil der Client sagt, dass es auf allen anderen Sites mit genau derselben Konfiguration funktioniert.EDIT DPD wurde aktiviert
Diagramm des lokalen VPN-Clients, das keinen Datenverkehr zeigt:
Ich habe eine Protokolldatei beigefügt, die kontinuierliche Schleifen der MikroTik-Protokolldatei „ein gültiges RU-THERE empfangen, ACK gesendet“ zeigt:
echo: ipsec,debug,packet 84 Bytes von xx7.183[500] bis xx186.50[500]
echo: ipsec,debug,paket sockname xx7.183[500]
echo: ipsec,debug,packet sende Paket von xx7.183[500]
echo: ipsec,debug,packet sende Paket an xx186.50[500]
echo: ipsec,debug,paket src4 xx7.183[500]
echo: ipsec,debug,paket dst4 xx186.50[500]
echo: ipsec,debug,packet 1 mal 84 Bytes Nachricht wird an xx186.50[500] gesendet
echo: ipsec,debug,paket 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf
echo: ipsec,debug,paket cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979
echo: ipsec,debug,paket 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8
echo: ipsec, debug, packet sendto Informationsbenachrichtigung.
echo: ipsec,debug,Paket hat ein gültiges RU-THERE erhalten, ACK gesendet
Ich habe verschiedene Vorschläge von IPsec-Experten und MikroTik selbst erhalten, die darauf schließen lassen, dass das Problem auf der Remote-Seite liegt. Die Situation wird jedoch dadurch noch komplizierter, dass 5 andere Sites funktionieren und die Firewall des Clients einer Änderungskontrolle unterliegt. Das Setup hat auch viele Jahre lang immer funktioniert, daher behaupten sie, es könne kein Konfigurationsfehler auf ihrer Seite sein. Dieser Vorschlag erscheint plausibel, kann ihn aber aufgrund der Änderungskontrolle nicht umsetzen. Ich kann nur die Client-Seite ändern:
Stellen Sie sicher, dass für den IPSec-Responder sowohl „passive=yes“ als auch „send-initial-contact=no“ festgelegt sind.
Das hat nicht funktioniert.
BEARBEITEN 9. Dez. 2013
Ich füge zusätzliche Screenshots mit der Fortigate-Konfiguration und dem ein, was wir für die Quick Mode-Selektoren auf der Mikrotik-Seite halten.
Ich möchte noch einmal betonen, dass ich nicht glaube, dass es sich um ein Konfigurationsproblem handelt. Ich vermute, dass es sich um ein Timingproblem handelt, bei dem Seite A oder Seite B zu aggressiv versucht, Informationen zu senden, wodurch die Aushandlung der Informationen (z. B. das SPI) nicht mehr synchron ist.
BEARBEITEN 11. Dezember 2013
Leider muss ich dieses Problem aufgeben. Glücklicherweise funktioniert alles. Warum es funktioniert, ist immer noch ein Rätsel, aber um weiter zu veranschaulichen, was wir getan haben, poste ich ein weiteres Bild inline.
Wir haben das Problem wie folgt behoben:
- PPPoE am Client ausschalten.
- Habe einen komplett neuen Router (Router B) installiert und an der Grenze getestet. An der Grenze hat es funktioniert.
- Neuen Router B an der Grenze ausschalten. UND DANN, OHNE EINE EINZIGE ÄNDERUNG VORZUNEHMEN, funktionierte der Endpunkt-Router A des Clients. Durch einfaches Hinzufügen eines Duplikat-Routers an der Grenze und erneutes Offline-Schalten dieses Routers funktionierte der ursprüngliche Router also wieder.
Fügen Sie diesen Fix also der Liste der Dinge hinzu, die wir getan haben:
- Neustart. Das hat einmal funktioniert.
- Neuen Tunnel mit neuer IP erstellen. Das hat einmal funktioniert, aber nur einmal. Nach der Rückänderung der IP war der Client-Endpunkt wieder aktiv.
- Zeitserver ändern.
- Spielen Sie mit allen möglichen Einstellungen herum.
- Warte. Einmal, nach einem Tag, passte es einfach. Dieses Mal passte auch nach Tagen nichts.
Ich gehe also davon aus, dass es entweder auf der Fortigate- oder der MikroTik-Seite eine Inkompatibilität gibt, die nur in sehr zufälligen Situationen auftritt. Das Einzige, was wir nicht versuchen konnten, ist die Aktualisierung der Firmware auf Fortigate. Vielleicht gibt es versteckte beschädigte Konfigurationseinstellungen oder ein für den Konfigurator unsichtbares Timingproblem.
Ich vermute außerdem, dass das Problem durch Timing-Probleme verursacht wird, die eine SPI-Nichtübereinstimmung verursachen. Und ich vermute, dass Fortigate das alte SPI nicht „vergessen“ will, als ob DPD nicht funktionieren würde. Es passiert einfach zufällig und meines Wissens nur, wenn Endpunkt A Fortigate und Endpunkt B MikroTik ist. Die ständigen aggressiven Versuche, die Verbindung wiederherzustellen, „halten“ an alten SPI-Werten fest.
Ich werde diesen Beitrag ergänzen, wenn es wieder passiert.
BEARBEITEN 12. Dezember 2013
Wie erwartet ist es wieder passiert. Wie Sie sich vielleicht erinnern, haben wir 6 MikroTik-Client-IPsec-Endpunktrouter konfiguriertgenausoVerbindung zu einem Fortigate-Server. Der letzte Vorfall betraf wieder einen zufälligen Router, nicht den, über den ich hier ursprünglich berichtet habe. In Anbetracht des letzten Fixes, bei dem wir diesen doppelten Router installiert haben, habe ich diese Abkürzung genommen:
- Deaktivieren Sie Router A, den Router, der keine Pakete mehr von Fortigate empfangen möchte.
- Kopieren Sie die IPsec-Konfiguration von Router A auf einen temporären Router näher an der Grenze unseres Netzwerks.
- Deaktivieren Sie die neu erstellte Konfiguration sofort.
- Aktivieren Sie Router A erneut.
- Es beginnt einfach automatisch zu arbeiten.
Wenn ich mir den Kommentar von @mbrownnyc ansehe, glaube ich, dass wir ein Problem damit haben, dass Fortigate veraltete SPIs nicht vergisst, obwohl DPD eingeschaltet ist. Ich werde die Firmware unseres Clients untersuchen und sie posten.
Hier ist ein neues Diagramm, das dem letzten sehr ähnlich ist, aber nur meine „Lösung“ zeigt:
Antwort1
Dies ist möglicherweise nicht die Ursache Ihres Problems, kann aber für andere Benutzer eine nützliche Information sein. Wir hatten ein ähnliches Problem mit einem VPN zwischen einem Mikrotik und einem Sonicwall. Der Datenverkehr wurde zufällig unterbrochen, sodass die SAs gelöscht werden mussten.
Am Ende stellten wir fest, dass Sonicwall für jede Netzwerkrichtlinie eine separate SA erstellte (Ihrem Screenshot zufolge sieht es so aus, als ob Sie 2 Richtlinien/Subnetze über das VPN laufen hätten). Ich weiß nicht, ob diese Einstellung „SA pro Richtlinie“ fest codiert oder konfigurierbar ist, da ich keinen Zugriff auf Sonicwall hatte.
Unser Mikrotik verwendete die Ebene „require“ für die Richtlinien (die Standardeinstellung, wie in Ihrem Screenshot zu sehen). Dies führt dazu, dass der Router eine einzelne SA mit dem Remote-Peer erstellt. Beim Senden von Datenverkehr für eine der Richtlinien für diesen Peer wird dieselbe SA verwendet, unabhängig vom Quell-/Ziel-Subnetz.
Dies bedeutete im Grunde, dass es funktionierte, solange wir nur ein Subnetz verwendeten. Sobald unser Mikrotik versuchte, Datenverkehr für das zweite Subnetz zu senden, sendete es über die vorhandene SA (die, soweit es die Sonicwall betrifft, für ein bestimmtes Subnetzpaar gilt), die Sonicwall beschwerte sich, die SA-Sequenznummern gerieten durcheinander und das Ganze stoppte. (In unserem Fall erhielt der Kunde auf seiner Seite „Wiedergabe“-Fehler.)
Am Ende war es ganz einfach, die Richtlinienebene auf „eindeutig“ zu ändern, sodass beide Enden für jedes eindeutige Subnetzpaar eine eindeutige SA verwendeten. Die Tunnel funktionierten danach einwandfrei.
Antwort2
Ich weiß, dass Sie dies überprüft haben (genau wie ich, als ich ein ähnliches, aber völlig anderes, zeitweiliges Problem hatte), aber stellen Sie sicher, dass Sie keine doppelte IP-Adresse haben, die Router A gemeinsam nutzt. Dies würde zu dem zeitweiligen Problem führen, wenn Ihr High-Side-Router eine ARP-Suche nach Router A durchführt und verwirrt wird. Man würde meinen, dass doppelte IPs auf Routern einen konsistenten Fehler verursachen würden, aber das ist nicht der Fall.