IPSec Ping von Gegenströme kommt scheinbar nicht an

[LHBL2003]

Hi,

Ich habe bei uns eine IPSec Verbindung eingerichtet zu einem Partner, der wahrscheinlich kein opnSense besitzt. Phase 1 und Phase 2 wird aufgebaut. Ist auch auf „sofort starten“ eingerichtet. Ein Ping von uns aus in deren Richtung ist ohne Probleme möglich. Allerdings von denen in unserer Richtung nicht. Ich habe daher an einem anderen Standort von uns die opnsense genommen und einen Gegenpart mit deren IP Einstellungen eingerichtet und konnte ohne Probleme in beide Richtungen pingen.

Nun bin ich etwas ratlos. Folgende Informationen hat er mir zukommen lassen. Hat jemand eine Idee was ich in der opnsense noch einstellen müsste? PS: es wird IPSec V1 verwendet. Auf unserer Seite ein /24 Netz und auf deren Seite ein /28er Netz.

ihren eingehenden Traffic sehe ich, d.h. Phase 2 und Routing sind okay.

Bleiben aber 2 Probleme:
1. Wir können durch den Tunnel nach wie vor nicht pingen
2. wir können den Tunnel nicht aufbauen, da ihr VPN-Gateway eingehende Verbindungsanfragen von uns nicht zulässt, d.h. wir können erst durch den Tunnel kommunizieren, nachdem eine Gegenstelle bei ihnen zuerst mit uns kommuniziert hat.

Beides Sieht danach aus, dass noch etwas auf ihrer Firewall unseren Datenverkehr nicht zulässt. Bei uns gehet der Datenverkehr nach wie vor raus, wird nicht geblockt und wird in den richtigen Tunnel geroutet.

Vielen Dank für eure Ideen

[micneu]

- bitte einen grafischen netzwerkplan
- was ist die Gegenstücke denn für eine Firewall?
solche Informationen können ungemein helfen


Gesendet von iPad mit Tapatalk Pro

[LHBL2003]

Hallo @micneu,

Nachtrag: Post "Reply #5" wird interessanter sein...

die Gegenstelle verwendet Palo Alto zum aufbau des IPsec tunnels. (Info hatte ich gestern Abend noch nicht erhalten
Wir liegen mit unserer opnSense hinter unserer Office Firewall.
In den Screenshots im Anhang sieht man Rechts unser Entwicklungssystem und links die Gegenstelle.
In den Konfigurationsbildern 001 bis 003 findest du auf der Linken seite die Testhalber Projektierte Dummy gegenstelle welche ich in einem anderen Standort von uns eingerichtet habe, um zu testen ob es wirklich nicht geht. Rechts im Bild befindet sich immer meine aktuelle konfiguration.

Ich werde noch einen zweiten Post mit den restlichen Screens anhängen.

Vielen Dank.

[LHBL2003]

Weitere Screens...

[LHBL2003]

Und die restlichen Screens.

[LHBL2003]

Tja ich sage es ja nur ungerne, aber gestern ging es nicht.
Daher habe ich die Gegenstelle darum gebeten heute einen Dauerhaften Ping auszulösen. Damit ich irgend etwas prüfen kann und siehe da alle Pings werden durchgeleitet.

In seinem Log konnte er auch sehen, dass gestern eine Stunde nach seinen Test sein System einen Tunnel aufbauen konnte und keinen Timeout erhalten hatte. Seit dem wird beim einleiten eines Datenverkehrs immer automatisch der Tunnel aufgebaut.

Keine Ahnung warum das auf einmal so ist, ich habe rein garnichts danach an der Firewall gemacht.
Habt Ihr eine Idee warum das auf einmal so spontan funktioniert?

[LHBL2003]

Hallo,

es geht sogar mal wieder um dieses Thema wo die Konfiguration und der netzwerkaufbau oben bereits dargestellt wurde.

ich habe gerade Probleme mit dem Partner und dem zwischen uns eingerichteten IPsec Tunnel Typ V1.
Im vergangenen Jahr hatten wir den Tunnel eingereichtet. Daraufhin konnte ich Pingen er aber nicht.
Nach vielen hin und her wurde es nicht besser. Am nächsten Tag kahm die Info das er auf einmal pingen kann.
Nur hat keiner etwas geändert.

Vor ein paar wochen wollten wir das eigentliche Pojekt angehen. Dann war noch alles ok.
Gegen mittag konnte ich nicht mehr Pingen, der Partner auch nicht.
Nach einem dauerping von ca. 10 Stück geing es auf einmal.
Am nächsten Tag ging dann irgendwann garnichts mehr bis jetzt.

Wenn ich Pings sende, dann sehe ich im Status der Phase 2 das der Wert "Byteausgehend" steigt. "Byteeingehend" bleibt bei 0.
Die gegenseite kann auch pings in den Tunnel senden, die kommen bei mir aber scheinbar nicht an und er bekommt auch nichts zurück.

Jetzt ist mir aufgefallen, dass ich in der Statusübersicht beim aufklappen des Info bereichs der Phase 1 manchmal 2 einträge für Phase 2 sehe. Einen INSTALLED Geroutet und einen wo im Status REKEYED steht.
Starte ich die verbindung neu, so verschwindet dies wieder und es gibt nur INSTALLED.
Vom Partner habe ich gerade folgende infor erhalten: "wir graben gerade zwei Tunnel gleichzeitig"

Warscheinlich hat er das selbe bei sich.
Wie kann man dies verhindern? Denn jetzt habe ich zwar auf meiner seite nur ein Eintrag aber es geht immernoch nicht.

Vielen Dank für eure hilfe.
Bei IPsec wird man mit dem auslernen glaube ich nie fertig.

Im Anhang befindet sich das Logfile, von Verbindung gestartet bis einige dauerpings ausgelöst...

[Patrick M. Hausen]

Ist die Phase 2 SA wirklich auf beiden Seiten identisch (jeweils gespiegelt natürlich) definiert? Also alle Adressen und Prefix-Längen gleich?

[LHBL2003]

Hallo pmhausen,

viele Parameter sind es ja nicht.
Im Anhang die Vorgabe und meine Umsetzung in OpnSense.

Das komische ist ja das es eigentlich schon mal funktionierte.

[Patrick M. Hausen]

Ich fragte nach den Netzen und den Prefixlängen, nicht nach den Krypto-Parametern 

[LHBL2003]

Sorry, ja ich habe z.B. einen Rechner mit 172.24.1.101 und die gegenseite 10.20.4.238

bei mir ist eingestellt
Lokales Netz: 172.24.1.0/24
Entferntes Netz: 10.20.4.224/28

auf der gegenseite dementsprechen umgekehrt.
Normalerweise sollte das dann ja schon auf anhieb gehen würde ich behaupten.
Wenn ich einen Ping sende sehe ich ja das die ausgehende Byte Zahl sich erhöht also ist das automatisch eingestellte Routing auch vorhanden.
Und wenn ich ne falsch Netz Adresse nutzen würde, dann wird mir ja im Status die Phase 2 nicht angezeigt.
Soviel in meinem Jugendlichen leichtsinn.

[chemlud]

sowas hier vielleicht?

https://forum.opnsense.org/index.php?topic=20868.msg105003#msg105003

[Patrick M. Hausen]

Genau. Und mein Hinweis war, dieses lokale und entfernte Netz auf beiden Seiten noch einmal zu überprüfen. Fehler durch Abweichungen an dieser Stelle sind eine der häufigsten Ursachen.

[LHBL2003]

Das Problem wurde gelöst, wobei mir das Verhalten nicht klar ist.

Ich habe schlussendlich in der FW Regel den Port 500 und 4500 von TCP/UDP nach UDP umgestellt und urplötzlich kam auf beiden Seiten Pakete rein.

Dies ist nur aufgefallen, weil ich mit meinem Kollegen in unserer Front FW (Watchguard) nachgeschaut haben ob es einen Unterschied zur Partner Adresse gibt, denn zu einer anderen OpnSense FW im Internet funktionierte es Problemlos (Habe dort alles so eingerichtet, dass ich nur bei mir die Partner Adresse austauschen musste. In unserer anderen OpnSense FW hatte ich allerdings auch TCP/UDP eingerichtet. In der Front FW (Watchguard) ist automatisch als IPSec Standard Regel UDP angegeben.

Das auslösende Problem entstand allerdings aus der Opnsense Dokumentation:

https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
Kapitel: „Firewall Rules Site A & Site B (part 1)“

Dort wird zwar UDP im Text erwähnt. Allerdings wird im Bild TCP/UDP angegeben.
Wer kann die Dokumentation überarbeiten und „TCP/„ unleserlich machen?

[LHBL2003]

Wundersamerweise war es nicht das Problem, (Auch wenn das Bild in der Anleitung von OpnSense dennoch nicht passt).

Aber wir haben jetzt einige Stunden nochmal hin und herr getestet. Bis auf einmal die Verbindung stand.
Aktuell spitzt sich der verdacht auf das Thema "NAT Traversal". Ich hatte es aktiv, weil ich mit meiner FW hinter einer FW liege.
Der Partner hatte NAT Traversal deaktiviert. In der Dokumentation von dem FW Hersteller Paloalto (Partner FW). Wird im beispiel gezeigt, dass dies auf beiden Seiten aktiviert ist.
Jetzt muss ich noch warscheinlich eine NAT Regel in der Front FW einrichten, damit das NAT-T immer bedacht wird.

Falls es das Thema jetzt war, dann könnte anderen diese Anleitung weiterhelen. Denn hier wird das Thema "NAT Traversal" eigentlich gut dargestellt.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClopCAC

If tunnels are up but traffic is not passing through the tunnel:

Dies waren u.a. auch Troubleshooting Themen

Check security policy and routing.
Check for any devices upstream that perform port-and-address-translations. Because ESP is a layer 3 protocol, ESP packets do not have port numbers. When such devices receive ESP packets, there is a high possibility they may silently drop them, because they do not see the port numbers to translate.
Apply debug packet filters, captures or logs, if necessary, to isolate the issue where the traffic is getting dropped.