Bereits 10853 Beiträge!


Sicherheit geht vor...

Beitrag von moregothic, am 24.07.2012
Durchschnittliches Voting: 4.14


Kunde ruft an, hat eine UTM-Firewall im Einsatz. Hat einen Tunnel zu einem seiner Kunden, der eine UTM-Firewall eines anderen Herstellers im Einsatz hat, einen ipsec-Tunnel gebaut. An sich eine einfache Sache, beide GWs haben feste, öffentliche IPs und basieren auf Linux, d.h. beide setzen den Strongswan-ipsec-Daemon ein.

Nun baut sich zwar der Tunnel auf, es geht aber kein Traffic durch. Ich konnte auf unserer Seite keinen Konfig-Fehler entdecken und hab dann geprüft ob die Pakete die Firewall verlassen, und zwar so:

tcpdump -i any proto 1 or proto 50

Das zeigt mir sowohl den eingehenden echo request, als auch das ausgehende verschlüsselte ESP-Paket. Und so kam es auch:

Ping rein -> ESP-Paket raus. Mit aufeinanderfolgenden Sequenznummern. Aus meiner Sicht konnte ich mich zurücklehnen und der Dinge harren die da kommen, denn bei uns war alles tutti.

Das behauptete die andere Seite allerdings auch, und so kam es nach einigen Monaten und wiederholten Beteuerungen dass die Daten bei uns einwandfrei in den Tunnel gehen. Die Gegenseite behauptete aber exakt das gleiche...

So kam es dann irgendwann zum Showdown in Form einer Telefonkonferenz, bestehend aus mir (M), unserem Kunden (K), dem Admin des Kunden unseres Kunden (A) und dem Dienstleister der das andere Gateway betreut (D)

M: So ich schicke jetzt einen Ping, und es müssten jetzt ESP-Pakete mit folgenden Sequenznummern ankommen: ...

D: Hier kommt nix an...

M: Pingen Sie mal von Ihrer Seite, und führen Sie vorher auf dem GW folgenden tcpdump-Befehl aus: ...

D: OK ich seh die Pakete mit folgenden Sequenznummern...

M: (leicht konsterniert) Verdammt wo bleiben die Pakete hängen?

Wie gesagt, beide GWs hatten feste, öffentliche IP-Nummern, eigentlich Idealbedingungen, und der Tunnelaufbau kam auch einwandfrei zustande, nur ging nix durch...

M: Darf ich mal per ssh auf das andere Gateway schauen?

A: hmm nee das wird schwierig...

Nach einigem Hin und Her dann A: Kann es sein dass die von der Cisco-Firewall geblockt werden die ich noch vor der UTM-Firewall habe?

M: *tilt*
K: *tilt*
D: *tilt*

Und genau so war es, auf der sich davor befindlichen Cisco Pix war nur 500/udp freigegeben, von einem Protokoll namens ESP (M: Nein, Protokollnummer 50, nicht Port 50....x() hatte der Admin des Kunden noch nie was gehört...


ACHTUNG Archivsystem!

Es sind keine neuen Einträge, Bewertungen oder Kommentare mehr möglich.