Im ersten Beitrag zu diesem Thema habe ich das Szenario, das vermutete Problem und die ersten Reaktionen des Sophos Technical Support beschrieben. Außerdem habe ich einige Stellen aus den relevanten RFCs herausgesucht, auf deren Basis ich schließlich einen Bug bei Sophos öffnen wollte. Das ist mir bisher jedoch nicht gelungen. Warum, das erkläre ich in diesem Beitrag.

Vorher möchte ich aber noch kurz eine Anmerkung zum Fehlerbild machen. Möglicherweise ist dem aufmerksamen Leser nicht entgangen, dass nicht alle Tunnel von dem Problem betroffen sind.

Auch dafür kennen wir mittlerweile die Ursache. In manchen Netzen stehen Windows Domänencontroller und in anderen nicht. Natürlich replizieren die Domänencontroller untereinander. Vom eigentlichen Problem beim VPN-Verbindungsaufbau sind grundsätzlich alle Tunnel betroffen: Keinem Domänencontroller in einer Außenstelle wäre die Replikation in die Zentrale möglich, wenn nicht gelegentlich sein Replikationspartner Traffic in die Außenstelle schicken würde, wodurch die ASA einen Tunnelaufbau initiiert. Die Tunnel, für die kein Replikationstraffic von der Zentrale in die Außenstelle fließt, bleiben aus.

Nun also zum weiteren Verlauf meines Cases. Trotz handfester Argumente aus anerkannten Quellen bot man mir weiterhin nur einen Feature Request an. Die Begründung ist aus Sicht des Software Engineering tatsächlich nachvollziehbar, in dieser Situation dennoch sehr amüsant:

I cannot raise this as a bug as it is not implemented yet. But I can raise this as a feature request […]

Das leuchtet ein: Eine Funktion die niemand jemals implementiert hat, kann natürlich nicht fehlerhaft sein. Den scherzhaft verwendeten IT-Spruch „It’s not a bug, it’s a feature.“ würde ich nun gern wie folgt abwandeln:

It’s not a bug, it’s not a feature.

Lukas

Nachdem ich das Angebot, einen Feature Request zu öffnen, erneut ausschlug, gelangte ich mit meinem Case endlich in den Level 2 des Sophos Technical Support. Und dort holte man sich sogar noch erfahrenere Leute hinzu…

We have checked with the most senior team and they also informed us about the same that if the SAs are not connected and we are trying to initiate the traffic the tunnel will not connect automatically in this scenario.

The connection must be already established before any traffic can be sent through it – and the traffic itself does not influence the connection status. This will be considered as a feature request.

Dieses Mal öffnete man den Feature Request einfach, damit ich nicht wieder ablehnen kann. Und natürlich konnte man keine Garantien machen, wann und ob der Request tatsächlich umgesetzt wird. Einen spöttischen Kommentar konnte ich mir an dieser Stelle nicht mehr verkneifen:

Even if you ask the most-most senior team: It is clearly a bug. I did enough argumentation on that. That’s why I am now going to escalate that case.

Und so erhielt ich mein nächestes „Level Up“.

Reviewing the case, our team has identified the report issue as Feature gap. As per your argument this could be identified [as] a known issue. However, will work with our Global Escalation team for further verify on the details provided.

OK, der Begriff klingt auch toll. Unsere VPN-Probleme werden also durch eine Funktionslücke verursacht… Aber nicht vergessen: Das ist kein Bug!

Plötzlich gab es tatsächlich einige Fortschritte: Anrufe und E-Mails mehrerer Personen, die sich als Teamleader Global Support & Services bezeichneten. Ich wurde eingeladen, der Sophos Community beizutreten und sollte eine der Personen direkt „als Freund hinzufügen“. Er wolle mich auf diesem Weg gern auf dem aktuellen Stand halten, der in dem Moment wie folgt aussah:

As I informed you, we are pushing the DEV team to make this feature available for you and other customers.

Super, der steinige Weg hatte sich also gelohnt! Zumindest könnte man das meinen. Befänden wir uns jetzt in der deutschen Literatur, dann wäre dies wahrscheinlich das Retardierende Moment einer Tragödie:

In der Tragödie bezeichnet das retardierende Moment ein Ereignis, welches dazu führt, dass man die trügerische Hoffnung auf die (noch denkbare) Rettung des Helden erhält.

https://de.wikipedia.org/wiki/Retardierendes_Moment

Der Case wurde jetzt jedenfalls geschlossen, denn „es gab keine aktive Arbeit mehr“. Inzwischen war der Jahreswechsel. Nachdem nun ein Monat vergangen war, kontaktierte ich meinen Freund bei Sophos, welcher mir mitteilte, dass der Feature Request noch immer im Produktmanagement hängt. Auch seine Anfrage, den Request zu beschleunigen, brachte keinen Fortschritt. So verfasste ich eine E-Mail an all meine neu gewonnen Kontakte bei Sophos und wies nochmal auf die Dringlichkeit des Problems hin. Und wieder erhielt ich zwei neue Kontakte. Diesmal war sogar ein Senior Product Manager dabei. 🙂 Nachdem ich meine Probleme erneut beschreiben und nochmal erklären musste, dass es sich nicht um meine Anforderung handelt, sondern um die der IPsec RFCs, erhielt ich folgende Antwort:

There are two ways of SA formation as below:

1. Pre-populate SA’s for Phase-I and Phase-II as soon as you load VPN configuration by initiating/responding to incoming/outgoing VPN request for matching policy.
2. Form on-demand SA’s based upon receiving interesting traffic for matching connection.

Sophos firewall is following workflow (a).

Ähm…nein. So ist das nicht. Wie war noch der genaue Wortlaut in Abschnitt 5.1. Outbound IP Traffic Processing (protected-to-unprotected) von RFC 4301?

IPsec MUST perform the following steps when processing outbound packets: […] 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.

Und so habe ich erstmals einen kurzen Blick in RFC 2119 – Key words for use in RFCs to Indicate Requirement Levels geworfen. Was dort steht, ist nicht weiter überraschend:

MUST This word, or the terms „REQUIRED“ or „SHALL“, mean that the definition is an absolute requirement of the specification.

Das sollte man dem Senior nochmal sagen:

[…] So you simply began your argumentation with a wrong statement: “There are two ways of SA formation as below: […] Sophos firewall is following workflow (a)” -> No! Workflow (b) is mandatory and not only an optional choice.

[…]

In summary, your IPsec implementation currently is wide away from standard compliance. Not only in a particular detail but in fundamental assumptions. That’s why we have that long lasting discussion. I can prove, that your systems are doing things wrong. And it remains wrong, even if it works in some situations and for some customers. If you close your eyes, problems won’t disappear. Correctness is a property which make things work for all, not only for some situations!

Die Antwort des Seniors fiel eher kurz und wenig fachlich aus:

Again, what I said on SA formation is how different vendor provides option. End goal is to keep interested traffic flowing over VPN without any manual intervention.

It seems your case was investigated in different direction instead getting debugged, why these tunnels are not up despite connections are up (green).  

Klingt so, als bezieht er sich auf die Definition des Wörtchens SHOULD aus RFC 2119. Ich verzichte darauf, diese hier einzufügen. Der Beitrag ist ohnehin schon wieder sehr lang und ich bin über jeden Leser dankbar, der bis hier dabei geblieben ist. Ein Kommentar wäre nett. 🙂

Recht hat er ja: Das Ziel ist es, dass der Traffic ohne manuelles Eingreifen fließen kann. Wenn Sophos das mit schwarzer Magie lösen will, dann soll es eben so sein. Interoperabilität wäre aber schon wünschenswert.

Und so öffnete man wieder einen Case und ich war erneut im Level 1 des Sophos Technical Support. Diesmal aber mit einer anderen Fragestellung: Anstatt zu untersuchen, weshalb die XGS trotz Interesting Traffic keine SA aufbaut, sollte nun geklärt werden, wieso der oben beschriebene Workflow (a) „Pre-populate SA’s for Phase-I and Phase-II as soon as you load VPN configuration“ nicht funktioniert. Wie das ablief, erkläre ich im nächsten Teil dieser Beitragsreihe.

Foto von Martin Brechtl auf Unsplash