IPSEC - Tunnel steht, aber Kommunikation will nur aus einer Richtung

[KillerCow]

[Gelöst] Siehe https://www.computerbase.de/forum/t...-nur-aus-einer-richtung.1952034/post-24274848

Moin

Ich "darf" mir gerade ein IPSEC Problem anschauen, weil unser VPN-Tunnel-Mensch im Urlaub ist und die Sache nicht wichtig genug ist, ihn zu stören... kennt man ja Ich bin allerdings selber kein VPN/IPSEC Guru, darum hoffe ich, jemand hier kennt das Phänomen und hat vielleicht ne Idee, woran as scheitern könnte. Ich bin etwas ratlos. Ein anderer Kollege sagte schon, er kennt das von früher von einem anderen Tunnel, weiß aber nicht mehr, was damals die Urache war narf

Folgende Situation:
OPNsense (ich, aktuelle Version) <-> Cisco ASA (remote)
Es kommt IKEv2 zum Einsatz und Phase 1 und 2 werden erfolgreich aufgebaut. Ich kann von meiner Seite einen Client auf der anderen Seite anpingen und bekomme Antworten. Die andere Seite kann mich nicht anpingen (oder per https erreichen, was der eigentlich Zweck des Tunnels sein soll), suggeriert mir aber mit Screenshots eines Logs, dass die Pakete bei denen in den Tunnel gehen und auf die Leitung in meine Richtung geschickt werden.

Auf meiner Seite hänge ich nun mit tcpdump auf dem WAN Interface und sehe (abgesehen von 10-sekündlichen isakmp Paketen, vermutlich ein keep-alive) absolut keine Pakete von der remote-Seite bei mir eintreffen. Ich habe doppelt geprüft, dass ich die eingehenden Pakete auf WAN vor der Firewall sehe, wobei ich sicherheitshalber natürlich auch im FW-Log geschaut habe, wo nichts in dem Kontext geblockt wird.

Bei einer Gelegenheit kamen dann allerdings deren Pings bei mir an, nachdem ich die Gegenstelle angepingt hatte. Das klappt jetzt aber auch nicht mehr.

Meine Schlußfolgerung:
Ich sehe aus deren Richtung keine Pakete bei mir ankommen, die von Verbindungen stammen, die auf deren Seite initiiert wurden. Ich kann aber mit der Remote-Seite reden und bekomme darauf Antworten. Also wird das Problem bei denen Liegen.

Kennt das jemand? Hat wer eine Idee, wonach man schauen könnte? Tatsächlich betrifft das Problem derzeit sogar zwei Tunnel zu unterschiedlichen Remotepeers, wobei in beiden Fällen wohl ASAs zum Einsatz kommen...

Allen Lesenden eine schöne Woche. Für zweckdienliche Hinweise bedanke ich mich schonmal

PS: Falls ich noch was herausfinde oder sogar die Lösung finde, wird das hier natürlich ergänzt.

 

[Lawnmower]

Wenn deine Pakete bei denen ankommen (die Du selber initalisierst hast) und Du da auch eine Antwort bekommst aber deren Pakete (die Du nicht selber initalisierst) nicht bei Dir ankommen, wird wohl eine (oder fehlende) Firewall Regel das auf deiner Seite blocken. Insbesondere da das auch noch bei 2 unterschiedlichen Remote Peers so ist, wird das Problem wohl eher bei Dir liegen. Allenfalls hat dein VPN Mensch das auch absichtlich so eingerichtet und er lässt nur bestimmte Ports durch und Ping gehört da wohl nicht dazu.
Schon mal probiert eine Regel zu erstellen dass aller eingehender Traffic von der IP Gegenstelle alles reinlässt? Manchmal muss man die Firewall auch neustarten damit die Regeln greifen.
Wichtig wäre sicher auch noch dass der Ping auf IP erfolgt und nicht auf DNS Hostnamen da dies eine zusätzliche Hürde (DNS Port offen, DNS Server Konfiguration entsprechend auf Remote Gegenstelle eingerichtet, etc.) nötig ist.

 

[KillerCow]

das auf deiner Seite blocken

Eben nicht. Das müsste ich zum einen im Log sehen und zum anderen müssten erstmal die ESP Pakete auf meinem WAN ankommen, damit überhaupt etwas geblockt werden könnte. Das ist ja das merkwürdige.

Wichtig wäre sicher auch noch dass der Ping auf IP erfolgt

Das passiert per IP, aber guter Hinweis.

 

[Rubbiator]

Fehlt auf dem gegnerischen PC/Switch vielleicht eine Route? Wie weit kommst du denn per tracert auf der gegnerischen Seite?

 

[till69]

Haben beide Seiten eine öffentliche IPv4 oder ist DS-Lite im Spiel? Oder gar IPv6?
Evtl. mit NAT-T versuchen, dann gibts keine ESP Pakete und alles geht über UDP (500/4500)

 

[KillerCow]

Fehlt auf dem gegnerischen PC/Switch vielleicht eine Route?

Kann ich leider nicht einsehen, aber laut deren Log gehen die Pakete in den Tunnel und dann auf die Leitung zu mir. Muss ich denen glauben, aber ich sehe bei mir nichts ankommen und vor meiner OPNsense steht kein anderes System mehr, das irgendwas filtert :/

Haben beide Seiten eine öffentliche IPv4 oder ist DS-Lite im Spiel?

Beide Seiten haben eine statische IPv4. IPv6 ist nicht im Spiel.

Evtl. mit NAT-T versuchen, dann gibts keine ESP Pakete und alles geht über UDP (500/4500)

Das hatte die Gegenseite mittlerweile vorgeschlagen, bzw. andersherum. Ist jetzt auf beiden Seiten deaktiviert. Allerdings kommt weiterhin nichts auf meinem WAN an. Ich filtere nach Quell-IP und nicht nach Protokoll, müsste also in jedem Fall was sehen. TCPDUMP zeigt bei NAT-T dann trotzem ESP an, mit dem Zusatz "encapsulated" glaube ich. Aber so oder, irgendwas müsste ich sehen, es kommt aber nichts an.

 

[Lawnmower]

Aber die VPN Verbindung ist doch aufgebaut wenn Du die Gegenstelle pingen kannst (also müsste da insofern alles OK sein), da müsstest Du eher nach geblockten Ping Anfragen suchen oder nicht?
Wenn die Gegenstelle sagt dass der Ping in den Tunnel geht, müsste die Route ja grundsätzlich mal stimmen - zumindestens bis zu deinem VPN Server (drüber hinaus kann ja dann wieder fehleranfälliger werden).
Ganz doof: Beide Seiten booten über Mittag mal ihre VPN Endpoints? Nur um sicher zu gehen dass sich da nicht irgendwas vermurkst hat und eigentlich alles richtig eingestellt wäre.

 

[KillerCow]

da müsstest Du eher nach geblockten Ping Anfragen suchen oder nicht?

Ja, der Tunnel ist aktiv und ich kann die Gegenseite erfolgreich pingen. Das sehe ich auch wunderbar im tcpdump am WAN der OPNsense. Den Dauerping von denen zu mir sehe ich aber nicht am WAN Interface der OPNsense.

Da müsste ja irgendwas von deren externer IP bei mir ankommen, ob nun direkt ESP oder NAT-T oder was auch immer, aber irgenndwelche Pakete müssten ankommen. Da ist nur nichts zu sehen (abgesehen von den isakmp Paketen alle 10 Sekunden). Der TCPDUMP läuft auf dem WAN-Interface und nur mit dem Filter auf die externe IP der Gegenstelle, keine weiteren Einschränkungen.

 

[trickster234]

Ist die Route für den eingehenden Traffic auf der OPNsense den gesetzt?

Wäre vielleicht einfacher wenn du mal ein paar Bilder von deiner Config postest.

 

[KillerCow]

Ist die Route für den eingehenden Traffic auf der OPNsense den gesetzt?

Meine Pings werden von denen korrket und erfolgreich beantwortet, heißt, Hin- und Rückweg funktioniert offenbar grundsätzlich. Deren Pings kommen nicht an meinem WAN an, gehen bei denen aber angeblich in den Tunnel und zu mir raus. Ich kann allerdings nicht sagen, ob diese Erkenntniss stimmt und die Pakete wirklich zu mir rausgehen oder doch noch bei denen auf dem letzten Stück im Nirvana landen.

ein paar Bilder von deiner Config postest

Mache ich gerne, was genau willst du sehen?

Meine Hoffnung war, dass jemand so ein Problem mit einer ASA als Gegenstelle (oder auch allgemein) kennt. Scheint aber wohl nichts gängiges bei den hier anwesenden zu sein. Aber ich hoffe noch Danke an alle auf jeden Fall, die bis jetzt schon Anregungen gegeben haben.

 

[Rubbiator]

Meine Pings werden von denen korrket und erfolgreich beantwortet, heißt, Hin- und Rückweg funktioniert offenbar grundsätzlich.

Das stimmt so nicht ganz, deine Pakete kennen ihren Weg, wenn Sie ihn einmal genommen haben, bzw. deine Firewall anhand von Session IDs und co.
Dies muss nicht zwangsläufig stimmen, wenn ein Paket ankommt, was deine Firewall noch nicht kennt, bzw. die Session nicht kennt.
Aber laut deiner Problembeschreibung kommt ja das Paket erst gar nicht richtig an, obwohl der Tunnel ja stehen muss.

 

[KillerCow]

@Rubbiator
Stimmt natürlich, die Antworten müssen auf deren Seite allerdings überhaupt in den Tunnel fließen und das tun sie. Darauf wollte ich hinaus.

 

[KillerCow]

Nachtrag
Nach vielen Tests und und einiger geraufter Haare sieht es so aus, als hätte der Cloudanbieter, bei dem die OPNsense läuft, ein Netzwerkproblem gehabt, das zwar schon als gelöst galt, aber offenbar hier und da noch zu unschönen Nebeneffekten geführt hat.

In einigen Foren bin ich über ähnliche Probleme gestolpert, bei denen die Ursache etwas anders aussah. Eigentlich logisch, aber auch ich hatte das nicht so wirklich auf dem Schirm. Neben UDP muss natürlich auch ESP eingehend erlaubt sein, sofern man das nicht durch UDP tunnelt. In diesem Szenario sieht man dann aber natürlich die geblockten Pakete...