Im zweiten Teil dieser Beitragsreihe habe ich erklärt, weshalb Sophos für das beschriebene Problem nur einen Feature Request, nicht aber einen Bug öffnen wollte. Nach langem Kampf mit dem Support war man schließlich der Meinung, mein Case hätte sich in die vollkommen falsche Richtung entwickelt. Es wurde ein neuer Case geöffnet, der die Untersuchungen nun in die richtige Richtung lenken sollte.

Dass die XGS trotz Interesting Traffic keine SA aufbaut, war jetzt also ein Fakt und offenbar so gewollt. Stattdessen sollte nun untersucht werden, weshalb sie ihre SAs nicht automatisch „auf Vorrat“ aufbaut. Das sollte die XGS laut Sophos Support sofort nach Abschluss der Konfiguration des VPN tun (im vorigen Artikel als „Pre-populate SA’s“ bezeichnet). Meinem Hinweis, dass ein Tunnel wegen etwaigen Internet-Ausfällen möglicherweise zusammenbrechen könnte und ein einmaliger Aufbau direkt nach Konfiguration deshalb nicht ausreicht, entgegnete man wie folgt:

On disruption like ISP down/ interface down/ re-key etc. Initiator side IPsec profile should take care of clearing SA’s post DPD trigger and re-initiate.

Genau das zu verifizieren, war Gegenstand des neuen Cases. Tatsächlich kam dabei heraus, dass Dead Peer Detection im IPsec-Profil nicht aktiviert war. Zugegebenermaßen ein Problem in unserer Konfiguration – dass DPD aber Voraussetzung für den selbstständigen Tunnelaufbau eines VPN-Gateways ist, davon habe ich zuvor noch nie gehört. In der Sophos Doku ist mir auch kein Hinweis zu dieser, nennen wir es „proprietären Erweiterung“, ins Auge gesprungen. Das sollten die mal ergänzen…

Jedenfalls konnten wir das Fehlerbild nun zuverlässig reproduzieren: eine kurze Trennung der Internetverbindung und die SAs waren aus. In der Regel wurde eine SA danach wieder aufgebaut, der Rest blieb „grün-rot“ (d.h. Active grün, Connection rot; vgl. Abbildung 1). Das Witzige daran: das blieb auch nach der Aktivierung von DPD so. 😀

Um ehrlich zu sein, hätte es mich auch sehr gewundert, wenn DPD hier die Lösung gebracht hätte. Die Begründung ist einfach: Wenn das Peer „tot“ ist, gehen alle zugehörigen SAs kaputt und wenn das Peer „lebendig“ ist, dann müssen – korrekte Konfiguration vorausgesetzt – auch alle SAs wieder aufgebaut werden können. Das Problem betrifft aber nur einige und nicht alle SAs. Außerdem, ist der Zweck von Dead Peer Detection schlicht ein anderer. Und wieder ein kurzer Blick in den entsprechenden Standard: RFC 3706 – A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers ist zum Glück sehr überschaubar. In Abschnitt 1. Introduction ist das durch DPD zu lösende Problem klar beschrieben:

When two peers communicate with IKE [2] and IPSec [3], the situation may arise in which connectivity between the two goes down unexpectedly. This situation can arise because of routing problems, one host rebooting, etc., and in such cases, there is often no way for IKE and IPSec to identify the loss of peer connectivity. As such, the SAs can remain until their lifetimes naturally expire, resulting in a „black hole“ situation where packets are tunneled to oblivion. It is often desirable to recognize black holes as soon as possible so that an entity can failover to a different peer quickly. Likewise, it is sometimes necessary to detect black holes to recover lost resources.

Es geht also hauptsächlich um die Erkennung eines ausgefallenen VPN-Peers, damit eventuell ein Failover ausgeführt werden kann. Bezüglich Maßnahmen, die zu treffen sind, sobald das Peer wieder erreichbar ist, trifft der Standard keine Aussage.

Da das Verhalten nun aber definitiv von der Aussage des Sophos Technical Support abwich, witterte ich erneut eine Chance:

You wrote on 7 December 2023: „I cannot raise this as a bug as it is not implemented yet.“

So the reason why you couldn’t open a bug simply was that the feature was not implemented. Now, as I understood, your statement “On disruption like ISP down/ interface down/ re-key etc. Initiator side IPsec profile should take care of clearing SA’s post DPD trigger and re-initiate.” describes an implemented feature. So I would like you to open a bug now since the feature doesn’t work as described.

Und wie die Reaktion zeigte, traf mein Argument tatsächlich ins Schwarze:

Your case requires additional assistance from our global escalation specialists (GES). GES engineers are the highest technical tier within support and are responsible for interacting with our development teams. A GES engineer will review your case and provide the necessary expertise needed for resolution. […] If GES identifies a product defect or needs further assistance, the Development Team will be engaged. […] Upon completion of the investigation, the Development Team will determine when the issue will be resolved. GES will communicate the plan to you. Once the fix has been released, you will be notified.

Das klingt doch mal richtig gut! Einige Tage später meldete sich ein GES Engineer bei mir, Informationen wurden ausgetauscht und ein paar weitere Tage später erhielt ich ein erstes Feedback aus der Entwicklungsabteilung:

The differentiating factor will be configuring alteast one of local-id or remote-id to be different for each of the connection. This will ensure we have unique IKE connection-id for each of the VPN connections and the Phase-1 Ipsec profile parameters will be applied to each of the connections.

May we know also what is use case is that he has to build multiple tunnels between the same gateway for the different networks?

Bevor ich auf den Vorschlag mit den verschiedenen IKE IDs eingehe, möchte ich ein paar Sätze zum zweiten Teil der Antwort schreiben: An dieser Frage merkt man, wie intensiv sich die Entwicklung Gedanken zum operativen Einsatz des Systems macht. Verdeutlichen soll das Abbildung 2:

In der linken Auswahlbox befinden sich die lokalen Subnetze, in der rechten die entfernten Subnetze. Speichert man diese Config, versucht die XGS insgesamt 4 SAs aufzubauen, nämlich jedes lokale mit jedem entfernen Subnetz. Das ist unter Umständen nicht gewollt und flutet die Logs mit Unmengen an Fehlermeldungen, sofern die Gegenseite ausschließlich die tatsächlich gewollten SAs zulässt. Mit obiger GUI lässt es sich in realistischen Szenarien also kaum vermeiden, mehrere Tunnel zwischen den gleichen VPN-Gateways aufzubauen – so wie es auch in Abbildung 1 getan wurde.

Nun also zu dem Vorschlag, verschiedene IKE IDs für die unterschiedlichen Verbindungen zu verwenden. Erst einmal verwenden wir die IP-Adressen als IKE IDs. Das ist soweit nicht unüblich. Man erwartet jetzt also, dass wir von dieser Konvention abweichen und z.B. irgendwelche alpha-numerischen IKE IDs verwenden. Und dann am liebsten noch acht verschiedene, da wir ja acht Tunnel haben… Aus Operations-Sicht ein Albtraum… Aber was sagen denn die RFCs dazu? In Abschnitt 2.6. IKE SA SPIs and Cookies aus RFC 7296 steht Folgendes:

The initial two eight-octet fields in the header, called the „IKE SPIs“, are used as a connection identifier at the beginning of IKE packets. Each endpoint chooses one of the two SPIs and MUST choose them so as to be unique identifiers of an IKE SA.

Das heißt, die beiden „IKE SPIs“ (oft auch als Local ID und Remote ID bezeichnet) bilden gemeinsam einen eindeutigen Wert, welcher eine IKE SA identifiziert. Wenn ich also mehrere Tunnel (siehe Abbildung 1) mit dem gleichen ID-Paar definiere, meine ich damit, dass all diese Tunnel zur gleichen IKE SA gehören. Und da die XGS diese Eingaben so akzeptiert, sollte das auch funktionieren. Das war also der Inhalt meiner Antwort. Es folgte eine längere Diskussion, was denn nun wann und wie eindeutig zu sein hat. Der Technical Support monierte dabei immer wieder, dass man bei gleichen Peers (d.h. gleiche IP-Adressen) verschiedene IKE SPIs braucht, da man andernfalls die IKE SAs zwischen den beiden Peers nicht unterscheiden kann. Ja, das stimmt – zumindest wenn man verschiedene IKE SAs zwischen den gleichen Peers haben möchte. Für unseren Use-Case ist aber eine IKE SA ausreichend und wenn es nur eine gibt, braucht man sich keine Gedanken darüber zu machen, wie man zwischen mehreren unterscheiden kann…

Während dieser Diskussion kam erstmals ernsthafte Gegenwehr: Das Sophos Dev Team zitierte aus RFC 7296:

The Peer Authorization Database (PAD) as described in RFC 4301 describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy […]. The PAD is intended to provide a link between the SPD and the IKE Security Association management. See Section 4.4.3 of RFC 4301 for more details.

Der Begriff der Peer Authorization Database war mir zu diesem Zeitpunkt tatsächlich neu. Dennoch beschreibt das Zitat ja nur, was die Aufgaben der PAD sind. Von eindeutigen IKE SPIs steht da nichts. Da muss man sich wohl mal Abschnitt 4.4.3. in RFC 4301 anschauen…

To perform these functions, the PAD contains an entry for each peer or group of peers with which the IPsec entity will communicate. An entry names an individual peer (a user, end system or security gateway) or specifies a group of peers (using ID matching rules defined below).

[…]

The ID for each entry acts as the index for the PAD, i.e., it is the value used to select an entry.

Die PAD enthält also einen Eintrag je Peer. Als Index fungiert dabei die IKE ID des Peers. Das bestätigt meine oben beschriebenen Erwartungen: Die IKE ID ist eindeutig; wann immer ich dieselbe IKE ID verwende, beziehe ich mich auf denselben PAD-Eintrag. Daran hängt unter anderem auch der Pre-shared Key (vgl. S. 43 in RFC 4301), welcher für die Authentifizierung der IKE SA verwendet wird. Wenn ich also z.B. verschiedene Pre-shared Keys zwischen den gleichen Gateways haben möchte, muss ich natürlich dafür Sorgen, dass ich deren PAD-Einträge unterscheiden kann. Aber genau das ist ja nicht notwendig. Daher kann ich keinen Grund erkennen, weshalb ich ein und dasselbe Peer mehrfach unter verschiedenen Namen in die PAD eintragen sollte, wo eine IKE SA und ein Pre-shared Key doch völlig ausreichend für mich sind. Und einen Zusammenhang zu DPD finde ich dort schon gar nicht.

Tatsächlich hatte ich zu diesem Zeitpunkt aber gerade Urlaub. Mein Kollege Lutz, der ebenfalls einen tollen IT-Blog betreibt, sah das aber genau so und war so nett, für mich zu antworten. Lutz ist ein alter Hase und kann immer mit interessantem Wissen punkten. So verwies er hier z.B. auf RFC 4718 – IKEv2 Clarifications and Implementation Guidelines – der war mir auch vollkommen neu. Wirklich lesenswert für VPN-interssierte.

Unfortunately some of the RfCs are written with the use case of the Roadwarrior in mind. […] For the Lan2Lan case, we are discussing here, several of the phrases in the RfCs can be misleading. Hence an extra RfC exists to clarify several of the imprecise wordings.

Im letzten Satz seiner E-Mail lieferte Lutz dann einen Hinweis, der sich später noch als der entscheidende herausstellen sollte:

If you allow me to ask a final question. I assume, that you are based on StronSwan, so can you please check, that your GUI does really generate a start_action=”start trap” for *each* of the multiple child entries for a single VPN. Reference: https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html#_connections_conn_children

Dass Sophos strongSwan verwendet, war uns natürlich schon länger bekannt. Nach meiner Rückkehr aus dem Urlaub schaute ich mir also zuerst die entsprechenden Config-Files auf der Kommandozeile der XGS an. Diese liegen im Verzeichnis /_conf/ipsec/connections/. Tatsächlich fand ich dort die folgenden Einstellungen für meine VPNs:

...
auto=start               # entspricht <child>.start_action=start
closeaction=restart      # entspricht <child>.close_action=start
dpdaction=restart        # entspricht <child>.dpd_action=start
...

Erst einmal ist die von Sophos verwendete strongSwan-Version schon ziemlich alt. Der Link von Lutz passt also nicht genau zu unserer Config. Im Internet findet man aber eine Gegenüberstellung von altem und neuem Config-Schema. Die entsprechende „Übersetzung“ habe ich oben als Kommentar hinzugefügt. Im Kern besagen die obigen Zeilen, dass 1. das VPN automatisch beim Laden der Config aufgebaut werden soll (auto=start), 2. sobald die Gegenseite eine Child SA abbaut, die XGS sofort wieder eine neue aufbaut (closeaction=restart) und 3. die XGS bei einem DPD-Timeout automatisch einen erneuten Tunnelaufbau versucht (dpdaction=restart).

Es ist also tatsächlich der Fall, dass strongSwan DPD zum Tunnelaufbau benutzen kann. Wer strongSwan kennt, dem wird das sicher nichts neues sein – für mich war es jedoch neu. Dennoch funktioniert es in unserem Use Case nicht. Und tatsächlich scheint die Einstellung trap genau das fehlende Feature zu sein: „trap installs a trap policy, which will catch matching traffic and tries to re-negotiate the tunnel on-demand.“ Um das zu verifizieren, änderte ich also testweise die obige Config zu auto=route, closeaction=hold und dpdaction=hold. Nach einer kurzen Unterbrechung der Internetverbindung in der Außenstelle blieben die Tunnel „grün-rot“, aber diesmal konnte ich durch Pings in Richtung Zentrale selektiv die Erstellung von Child SAs triggern. Erfolg! Und auch der Befehl zur Auflistung der Trap-Policies zeigte nun endlich eine Ausgabe, wo vorher nur gähnende Leere herrschte:

XGS3100_RL01_SFOS 20.0.0 GA-Build222# swanctl --list-pols --trap
Tunnel_1/Tunnel_1, TUNNEL
  local:  10.10.1.0/24
  remote: 172.29.1.0/24
Tunnel_1/Tunnel_2, TUNNEL
  local:  10.10.1.0/24
  remote: 172.29.2.0/24
Tunnel_1/Tunnel_3, TUNNEL
  local:  10.10.1.0/24
  remote: 172.29.3.0/24
...

Die Namen und IP-Netze habe ich geändert. Das Namensschema Tunnel_1/Tunnel_X wird aber tatsächlich so angezeigt. Die erste aufgebaute Child SA Tunnel_1 ist offensichtlich auch der Namensgeber für die IKE SA, sodass mit Schema IKE SA/Child SA der Name Tunnel_1/Tunnel_1 entsteht. Alle weiteren Child SAs gehören zur selben IKE SA, daher also Tunnel_1/Tunnel_2usw…

Nun wäre nur noch interessant, wie man diese Config persistent bekommt, denn nach einem Reboot war meine Änderung wieder verschwunden. Aber das war auch nicht die einzige Beobachtung, die ich auf der Kommandozeile machte: Für jeden von mir konfigurierten Tunnel findet sich ein Config-File auf der XGS. Darin enthalten sind unter anderem die Einstellungen leftid und rightid, die den oben genannten Werten Local ID bzw. Remote ID entsprechen und die Sophos gern für jede Child SA verschieden hätte. Die Config-Files existierten dort aber nicht nur einmal je konfiguriertem Tunnel. Sobald man für einen Tunnel mehr als ein lokales oder ein entferntes Subnetz einträgt (analog Abbildung 2), wird für jede Kombination ein Config-File angelegt. Und jetzt kommts: In jedem dieser Config-Files verwendet man die gleichen Werte für leftid und rightid. Erstens macht es also gar keinen Unterschied, ob ich in der Sophos GUI meine gewünschten Child SAs alle in einem gemeinsamen Tunnel oder jeweils in einem eigenen Tunnel konfiguriere und zweitens hält sich Sophos bei der Generierung der der Config-Files selbst nicht an die Forderung, eindeutige ID-Paare zu verwenden. Mit dieser Argumentation hatte ich das Thema der eindeutigen IDs dann endlich abgehakt – der Support gab nach:

Our development team has provided an update. Please let us know when you are available for a live remote session to address this issue.

Dazu aber mehr im nächsten Teil dieser Beitragsreihe.

Foto von Claudia Soraya auf Unsplash