Ein Kunde hat diverse Standorte, die größtenteils mit Firewalls der Sophos XGS-Serie ausgestattet sind. Im Rechenzentrum steht einige Servertechnik des Kunden, welche durch eine Cisco ASA Firewall geschützt wird. Zwischen den Sophos Firewalls und der ASA gibt es jeweils ein IKEv2 VPN. Sowohl in den Außenstellen, wie auch im Rechenzentrum existieren mehrere IP-Netze. Die laut VPN-Policy erlaubten Kommunikationsbeziehungen ermöglichen insgesamt acht Phase-2-Tunnel. Eigentlich eine ziemlich geradlinige VPN-Konfiguration.
Im laufenden Betrieb beschwerte sich der Kunde allerdings mehrfach über Konnektivitätsprobleme. Jedes Mal waren einige SAs zwischen den Firewalls vorhanden, die über die sich der Kunde beschwerte, allerdings nicht. Ein kurzer Ping aus dem Rechenzentrum in Richtung des Kunden und die fehlenden SAs wurden anstandslos aufgebaut. Nachdem das Problem hinreichend oft die Nerven mehrerer Kollegen belastet hatte, musste eine dauerhafte Lösung her. Natürlich hätte man etwas skripten können, um z.B. im Stundentakt Pings in die Außenstellen zu schicken, aber das Problem schien interessant genug, um es grundhaft zu lösen.
Die Sophos Firewalls zeigten im Fehlerfall den folgenden Zustand:
Das linke Lämpchen Active beschreibt den administrativen Zustand des VPN-Tunnels: grün bedeutet aktiviert und rot bedeutet deaktiviert. Ein Klick auf das Lämpchen ändert diesen Zustand. Das rechte Lämpchen Connection zeigt den Betriebszustand des VPN-Tunnels: grün bedeutet, der Tunnel ist aufgebaut und rot bedeutet, der Tunnel ist nicht aufgebaut. Ein Klick auf das Lämpchen im grünen Zustand trennt den aufgebauten Tunnel. Ein Klick im roten Zustand initiiert einen Verbindungsaufbau. Natürlich wird es dann nur von rot auf grün wechseln, wenn alle VPN-Parameter auf beiden Gegenstellen passend konfiguriert sind.
Und genau das passierte im Fehlerfall: Ein Klick auf das rote Connection Lämpchen und das VPN wurde auch von der Außenstelle aus aufgebaut. Danach funktionierte der Tunnel wieder anstandslos. Eine fehlerhafte Konfiguration (IPsec Proposals, Key Lifetime, Encryption Domains, …) konnte also ausgeschlossen werden. Was allerdings nicht funktionierte, war der Verbindungsaufbau durch einen Ping von einem System in der Außenstelle in Richtung des Rechenzentrums. Und das obwohl die Pakete nachweislich an der Sophos Firewall ankamen. Ganz klar, dass sie dann einen Tunnelaufbau initiieren müsste!
Es stand also die folgende Vermutung im Raum: Die Sophos Firewalls bauen selbst keinen VPN-Tunnel auf, auch wenn entsprechender Traffic – oft bezeichnet als Interesting Traffic – vorhanden ist. Und das obwohl der Gateway type in Abbildung 1 sogar Initiate the connection lautet. Mit dieser Vermutung öffnete ich also einen Case beim Sophos Technical Support. Nachdem man sich das Problem angeschaut hatte, erhielt ich schließlich die folgende Antwort:
I would like to inform you that the feature you are looking for on XGS where the IPSec tunnel should get connect, when traffic initiated from any machine behind Local subnet to Any machine in Remote subnet, is currently not available on the XGS SFOS.
Sophos Technical Support, 29.11.2023
If you want to raise a feature request do let me know […]
Diese Aussage kam nicht etwa am 1. April, sondern am 29.11.2023, einem ganz gewöhnlichen Tag. 🙁 Neben einigen Erklärungen fiel schließlich auch die folgende Aussage zum Verhalten eines IKE Initiators:
Initiator only initiates the connection or send IPSec packets to the remote firewall when we click on the connection button. […] I suggest you to please refer the below provided articles for more information.
Spätestens damit war klar, dass es sich zu kämpfen lohnt, denn was die Aufgaben und Eigentschaften eines Initiators und eines Responders sind, das definiert der IKE-Standard. Und mir wäre neu, dass darin die Rede von Connection Buttons ist…
Die Aufgabe, welche es nun zu lösen galt, war also klar. Ich startete mit RFC 7296 – Internet Key Exchange Protocol Version 2 (IKEv2). Bei der ersten Suche, inbesondere nach Initiator und Responder, fand ich keine Aussagen, die mich wirklich zufrieden stellten. Schließlich wurde ich im Abschnitt 2.9. Traffic Selector Negotiation fündig:
When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a „protect“ selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it.
Was aber ist ein RFC4301-comliant IPsec subsystem genau? Das erfährt man wohl in RFC 4301 – Security Architecture for the Internet Protocol. Tatsächlich kommt das Wort subsystem dort aber nur einmal vor und wird dabei auch nicht näher erklärt. Eigentlich ist es auch egal, denn in Abschnitt 1.1. Summary of Contents of Document steht schon der entscheidende Satz:
This document describes the requirements for systems that implement IPsec, the fundamental elements of such systems, and how the elements fit together and fit into the IP environment.
Das ist also eine heiße Spur. Etwas detailreicher wird es dann in Abschnitt 5.1. Outbound IP Traffic Processing (protected-to-unprotected):
IPsec MUST perform the following steps when processing outbound packets: […] 2. Match the packet headers against the cache for the SPD […] 3b. If no match is found in the cache, search the SPD […] If the SPD entry calls for PROTECT, i.e., creation of an SA, the key management mechanism (e.g., IKEv2) is invoked to create the SA.
Das ist eindeutig! Und die RFCs sollten hinsichtlich Gültigkeit wohl über den drei Links zur Sophos Doku stehen. Ein Auszug aus meiner Antwort:
The three links you provided are nice to read. They obviously describe what the Sophos IPsec implementation does, but they are not relevant when we are talking about IPsec standard compliance. In fact, my sources are the relevant ones. It would be nice if you now would open a bug instead of a feature request.
Finally, I would like to ask you about a certain scenario: What if we had two Sophos XGS with an IPsec site-to-site VPN configured between them but without an active tunnel (Active Green, Connection Red). Neither the left site nor the right site are able to initiate a tunnel on behalf of their own connected subnets. So the tunnel always remains disconnected until the admin hits the connection button? Without all the RFC quotes above, even this simple example should convince you, that your implementation is buggy.
Und dennoch sollte es nicht für einen Bug ausreichen… Warum, das erkläre ich im nächsten Beitrag zu diesem Thema.