Zufällige Paketverluste zwischen lokaler Firewall appliance und virtueller Firewall in Azure
Nahtlose Kommunikationen zwischen lokalen Netzwerken und cloudbasierten Diensten wie Azure sind ein zentraler Punkt moderner Geschäftsabläufe. Dieser Artikel beschreibt eine konkrete Situation, in der eine Organisation, die eine Infrastruktur in der Azure (Region West Europe) verwaltet, auf unerwartete Hindernisse in der Kommunikation von dem lokalen Netzwerk hin, Richtung genau dieser Azure-Umgebung stieß.
Die daraufhin folgende Untersuchung brachte ans Licht, dass das Problem nicht im Site2Site VPN zwischen der lokalen Firewall und der virtuellen Sophos in Azure, sondern in der allgemeinen Verbindung zu Azure lag. Selbst grundlegende ICMP-Pakete von dem lokalen Standort nach Azure zeigten Paketverluste.
In diesem Artikel versuche ich den Weg darzustellen, wie ich dieses Verbindungsproblem identifiziert und gelöst habe.
Fehlerbeschreibung
Die Nutzung eines Warenwirtschaftssystem mit den in Azure gehosteten Web- und Datenbankservices sollte wie geplant problemlos möglich sein. Jedoch traten während der Nutzung der Warenwirtschaft kontinuierliche Verbindungsabbrüche auf, begleitet von einer deutlichen Verlangsamung der einzelnen Arbeitsabläufe.
Die initiale Untersuchung des Problems ergab, dass die Ursache nicht im VPN selbst lag, sondern in der generellen Konnektivität in Richtung Azure. Sogar grundlegende ICMP-Pakete, die von dem lokalen Standort zu einer öffentlichen IP in Azure geschickt wurden, wiesen Paketverluste auf. Es war scheinbar klar, dass weder die Firewall am lokalen Standort noch die virtuelle Sophos Firewall in Azure das Problem verursachten.
Dieser Artikel führt durch den Prozess der Identifizierung und Lösung dieses Verbindungsproblems, das letztendlich eine reibungslose Nutzung der Warenwirtschaft behinderte. Und am Ende auch zu einer interessanten Erkenntniss.
Fehleranalyse und -behebung
Da durch erste Analysen bereits festgestellt wurde, dass es nicht an der Site2Site VPN-Verbindung scheitert, sondern bereits an der Kommunikation vom lokalen Standort zur öffentlichen IP der Firewall in Azure wurde als nächstes überprüft, ob die Netzwerkpakete, die am lokalen Standort losgeschickt werden, auch in Azure ankommen. Zudem wurde überprüft, ob die Pakete, die in Azure ankommen auch beantwortet werden und die Firewall wieder verlassen, und ob diese Antwort-Pakete wieder am lokalen Standort ankommen.
Dazu wurde über die Shell beider Sophos Firewalls (lokale Sophos und die virtuelle in Azure) ein tcpdump auf dem WAN-Interface gestartet, der auf ICMP-Pakete filtert und alles in eine PCAP-Datei schreibt, die dann ausgewertet werden kann:
Nachdem der Mitschnitt gestartet wurde, wurde auf der Firewall des lokalen Standorts ein Ping auf die öffentliche IP-Adresse der virtuellen Sophos Firewall in Azure gestartet:
Wie zu erwarten, waren hier auch wieder massive Paketverluste festzustellen.
Via WINscp habe ich dann die PCAP-Dateien aus den TCPdumps heruntergeladen und mit Wireshark analysiert:
Dazu habe ich in zwei Wireshark Fenstern jeweils eine PCAP-Datei geöffnet. Links im Bild die Datei von der Firewall am lokalen Standort und rechts im Bild die PCAP-Datei aus der Sophos in Azure:
Markiert (in schwarz) sind hier bereits die Pakete, die (links) am lokalen Standort losgeschickt wurden aber nie eine Antwort erhalten haben. Rechts im Bild sind dieselben Pakete markiert und ZUSÄTZLICH die Pakete Antwortpakete auf die erhaltenen ICMP-Pakete. Somit konnte recht schnell der Entschluss gefasst werden, dass die Pakete alle in Azure auf der virtuellen Sophos Firewall ankommen und auch beantwortet werden. Das Problem, das den Paketverlust also verursacht liegt auf dem Weg VON AZURE ZUM LOKALEN STANDORT.
Hier ein Beispiel, wie genau ich das mit den mitgeschnittenen Daten festgestellt habe:
Ich habe mir ein Paket rausgesucht, was am lokalen Standort Richtung Azure losgeschickt wurde und unbeantwortet blieb. Das wird von Wireshark entsprechend angezeigt, wenn man die Pakete durchgeht.
Im Screenshot sind folgende Dinge sichtbar:
- Das markierte und ausgewählte Paket (Nr. 73) vom Typ ICMP. Außerdem ist direkt auch zu erkennen, dass es unbeantwortet ist. In der Spalte „Info“ ist ganz am Ende beschrieben „(no response found!)“.
- In den ICMP-Informationen des Pakets wird auch nochmals drauf hingewiesen, dass das Paket unbeantwortet ist
- „Identification“ Informationen im IPv4 Header. Dies ist eine Kennung im IPv4 Header und im Prinzip eine Fortlaufende Nummerierung der Pakete. Sie besteht aus 16 Bit also 0-65536. Sie wird in Hexadezimal und Dezimal dargestellt in Wireshark.
Mit diesen Informationen, und besonders der Identifikations-Nummer des Pakets können wir nun im mitgeschnittenen tcpdump der virtuellen Sophos Firewall in Azure auf die Suche nach genau diesem Paket gehen.
Anhand des Identification Zählers des Paketes, das wir uns im Mitschnitt der lokalen Firewall herausgesucht haben können wir dieses nun auf der Azure Sophos Firewall finden.
Außerdem sehen wir, dass die Ping-Anfrage auch von der virtuellen Firewall in Azure beantwortet wurde:
Und bei der entsprechenden Gegenprobe stellen wir fest, dass genau dieses Antwort-Paket niemals am lokalen Standort ankommt.
Dazu nehmen wir auch wieder die Identification Nummer des Antwort-Pakets aus Azure und filtern im TCPdump des lokalen Standorts genau nach dieser ID:
Diesen Vorgang habe ich für mehrere Pakete durchgeführt, um auch absolut sicher zu sein.
Danach war zumindest die Ursache des Problems gefunden: Die Pakete kommen alle in Azure an, aber die Pakete aus Azure kommen teilweise nicht wieder am lokalen Standort an.
Das Problem lag also definitiv nicht am VPN zwischen den beiden Firewalls (lokal und virtuelle Sophos in Azure) sondern bereits an der Kommunikation von der öffentlichen IP, der virtuellen Sophos in Azure zum lokalen Firewall Cluster.
Einfach dargestellt wissen wir nun folgendes:
Somit konnte sowohl der Hersteller der Firewalls ausgeschlossen werden als auch der VPN.
Der Verdacht war hier kurz der ISP des lokalen Standorts des Azure-Kunden. Es könnte sein, dass dieser Probleme hat allgemein die Pakete aus der Azure Region West Europe (also Amsterdam) nach Deutschland zu Routen oder ähnliches.
Um auch die eine öffentliche IP-Adresse in Azure auszuschließen, habe ich von einer anderen Linux VM in der gleichen Azure-Umgebung, die ebenfalls eine öffentliche IP-Adresse zugewiesen hat, versucht die öffentliche IP des lokalen Standorts anzupingen und umgekehrt. Erneut bildlich dargestellt und vereinfacht also folgenden Test (in BLAU):
Mit Verwundern musste ich dabei in beide Richtungen feststellen, dass es 0% kein Paketverlust gibt. Also weder von der lokalen Firewall auf die öffentliche IP, der Linux VM, noch von dieser VM auf die öffentliche IP, der lokalen Firewall.
Wir haben nun also folgende Situation und ein Fragezeichen über dem Kopf:
Somit kommen aus der selben Azure Umgebung NUR manche Pakete von der virtuellen Sophos Firewall nicht am lokalen Standort an.
Daher habe ich die Azure Konfiguration, was das Netzwerk angeht, nochmal vergleichend mit der virtuellen Sophos Firewall und der Linux VM in Azure geprüft.
Bei dieser Überprüfung habe ich festgestellt, dass die öffentliche IP-Adresse der virtuellen Sophos Firewall in Azure mit der Routing Präferenz „Internet Routing“ konfiguriert wurde. Die Routing Präferenz der öffentlichen IP-Adresse der Linux VM ist hier „Microsoft Netzwerk„:
Somit ein Unterschied zu der IP der virtuellen Sophos Firewall und ein Punkt, den es zu überprüfen gilt.
Vermutlich wurde die IP-Adresse der Firewall beim Design der Azure-Infrastruktur mit der Routing Präferenz „Internet Routing“ angelegt um Kosten zu sparen. Denn hier wird ausgehender Verkehr nicht über das Microsoft Netzwerk, sondern über das öffentliche Internet geroutet. Somit spart man sich den Datenverkehr über das Microsoft Netzwerk, was in Azure Geld kostet. Mehr zur Routing Präferenz in Azure HIER.
Als nächsten Test wurde also eine neue, öffentliche IP-Adresse mit folgender Konfiguration erstellt:
- IPv4 Adresse
- Statische IP
- Standard SKU
- Routing Präferenz = Microsoft-Netzwerk
Nachdem diese neue IP in Azure erstellt war habe ich sie als zweite Interface Konfiguration dem WAN-Interface (PortB) der virtuellen Sophos Firewall hinzugefügt:
Außerdem habe ich die neue IP dann auch als Alias (also als zweite IP-Adresse auf dem WAN-Interface) auf der virtuellen Sophos in Azure hinzugefügt:
Dadurch konnte nun die Sophos Firewall in Azure über die neue öffentliche IP-Adresse angesprochen werden (beispielsweise ICMP/Ping).
Als Test habe ich dann direkt versucht die neue öffentliche IP-Adresse der Sophos Firewall in Azure von der lokalen Firewall ausgehend anzupingen um zu sehen, ob auch hier weiterhin Paketverluste stattfinden. Und siehe da – KEINE PAKETVERLUSTE:
Es war nun also relativ sicher, dass der Fehler von der Routing-Präferenz der öffentlichen IP-Adresse der Sophos Firewall in Azure hervorgerufen wird. Nun lässt sich dir Routing Präferenz nachträglich aber leider nicht mehr ändern.
Demnach wurde folgende Umstellung eingeplant:
- Übernahme der neuen öffentlichen IP-Adresse direkt auf das Interface der Sophos Firewall in Azure (nicht nur als Alias auf dem Interface)
- Entfernen der „alten“, öffentlichen IP-Adresse von dem Interface, welche die Routing-Präferenz „Internet Routing“ eingestellt hat
- Anpassen der öffentlichen DNS-Einträge
- Neu Aufbauen der IPsec Site2Site VPN-Verbindung
Um Punkt 1 zu erreichen habe ich die temporäre Test-Interface-Konfiguration in Azure gelöscht und die neue, öffentliche IP-Adresse auf die primäre Interface Konfiguration agewendet. Somit war das WAN-Interface (PortB) der Sophos Firewall in Azure nun unter der neuen, öffentlichen IP erreichbar:
Außerdem habe ich den Alias vom WAN-Interface der Firewall entfernt:
Ganz wichtig war es nun, alle öffentlichen DNS-Einträge anzupassen, die auf die „alte“ öffentliche IP-Adresse der virtuellen Firewall in Azure aufgelöst haben. Diese DNS-Einträge müssen nun auf die neue IP-Adresse angepasst werden, sodass die Namensauflösung weiterhin auf das richtige Ziel auflöst.
Außerdem muss natürlich der IPsec Site2Site VPN neu aufgebaut werden. Hierbei wird die öffentliche IP-Adresse in der Konfiguration verwendet. Da diese sich allerdings geändert hat muss die VPN-Konfiguration ebenfalls entsprechend angepasst werden.
Nach diesen Umstellungen wurde alles gründlichst getestet. Wir konnten keine spürbaren Paketverluste mehr feststellen und alle Verbindungen von und zur Azure Umgebung liefen Problemfrei.
Resümee / Schlusswort / Lessons learned / Das Ende halt 😉
Normalerweise sollte es egal sein, welche Routing-Präferenz bei einer öffentlichen IP-Adresse in Azure ausgewählt wird. Es sollte beim Datenverkehr keinen Unterschied machen, ob die ein und ausgehenden Datenpakete über das Internet geroutet werden oder so lange wie möglich in dem globalen Microsoft Netzwerk geroutet werden. Der einzige Unterschied hierbei sind normalerweise die kosten, da es einen preislichen Unterschied macht. Es gibt verschiedene Designs, für die die Routing Präferenz beachtet werden muss, aber in diesem Scenario sollte diese nicht mehr als eine Preis-Frage ausmachen. Technisch gesprochen sollten die Datenpakete bei beiden Präferenzen ihre Ziele erreichen.
Fakt bleibt, dass wir bei keinem der beiden Routing-Methoden eine reale Kontrolle darüber haben, welchen Weg die Pakete genau gehen. Allerdings sollte klar sein, dass die Hop-Anzahl über das globale Microsoft Netzwerk deutlich geringer ist und somit weniger Fehlerquellen auf dem Weg von A nach B vorhanden sind.
Warum genau in diesem Scenario manche Pakete von Azure nicht am lokalen Standort in Deutschland ankamen ist nicht klar. Ohne Paketfluss-Analyse ist und bleibt dies leider eine Blackbox. Vermutlich hat es sich hierbei um irgendwelche gewöhnlichen Routingprobleme im großen, weiten WWW gehandelt.