13
IPsec mit NAT auf pfSense
Hallo zusammen,
ich stehe vor einem Problem und komme leider nicht mehr weiter. Wir haben eine IPsec Verbindung zu einem externen Dienstleister. Diese mussten wir auf deren Anforderung neu gestalten, da sich bei denen irgendwas geändert hatte (ich glaube die haben Firewall/Produkt gewechselt). Der IPsec Tunnel musste deshalb auf beiden Seiten neu konfiguriert werden, die Parameter haben wir vorgeschrieben bekommen vom externen Dienstleister. Neu hinzu kommt nun, dass die NAT betreiben wollen/müssen und demnach mussten wir das auf unserer Seite auch so einrichten. Der externe Dienstleister kann zwar zu uns problemlos gelangen, wir jedoch nicht auf deren Hosts wie es gewünscht wird.
Wir verwenden pfSense, hier eine kurze Erklärung der Netze:
Subnet: 172.18.100.96/28 (also Hosts .97 bis .110)
Subnet1: 194.38.218.0/26 (also Hosts .1 bis .62)
Subnet2: 195.195.195.0/29
Subnet3: 196.196.196.0/26
Als NAT Subnet wurde von denen das Netz 172.16.0.0/29 (Hosts .1 bis .6) festgelegt.
Ziele:
(1) Die Gegenseite soll drei Hosts aus unserem Subnet 172.18.100.96/28 erreichen können, und zwar nach folgender Übersetzungstabelle:
-> sie sprechen die NAT IP-Adresse 172.16.0.1 an und sollen auf unseren Host 172.18.100.97 landen
-> sie sprechen die NAT IP-Adresse 172.16.0.2 an und sollen auf unseren Host 172.18.100.98 landen
-> sie sprechen die NAT IP-Adresse 172.16.0.3 an und sollen auf unseren Host 172.18.100.99 landen
(2) Außerdem müssen von unserem Subnet aus die Hosts aus dem entfernten Subnet1 (194.38.218.1-62) erreicht werden können.
Die Phase1 ist vermutlich uninteressant für das Problem, deshalb habe ich in dieser Beschreibung auch die öffentlichen Endpunkte IP-Adressen nicht angegeben. Phase1 steht soweit und ist i.O. Die Konfiguration auf unsrer pfSense habe ich entsprechend pfSense Anleitung wie folgt eingerichtet..
Von subnet2 und subnet3 habe ich nicht extra screenshots beigefügt, da erstmal nicht von Belangen. Es wurde jedoch äquivalent genauso eingerichtet wie in diesem screenshot von subnet1 gezeigt.
In der pfSense Konfiguration unter [Firewall] --> [NAT] --> [1:1] habe ich konfiguriert:
Interface = IPsec
External subnet IP = 172.16.0.1
Internal IP
Type=Single host
Address=172.18.100.97
Destination und alles weitere ist leer gelassen. Genau nach diesem Prinzip habe ich noch zwei weitere Einträge erstellt, eben für die genannten Zuordnungen. Dadurch kann der externe Dienstleister die IP-Adressen 172.16.0.1-3 aufrufen und landet auf unseren drei Servern. Funktioniert!
Wir können von unseren Hosts (172.18.100.97-99) aus nicht auf das entfernte Subnet1 194.38.218.0/26 zugreifen. Aus unserer lokalen Firewallseite wird nichts geblockt, das habe ich ausgeschlossen, es sind keine Pakete geblockt. Der Admin der entfernten Seite hat ein paar Regeln auf deren Seite angepasst, wir wollten erstmal ICMP/Pings testen. Das schlug jedoch fehl. Durch trial-and-error habe ich folgende Entdeckung auf unsrer Seite gemacht
--> sobald ich in der IPsec Konfiguration, unter Phase2 --> subnet3 deaktiviere und den Tunnel neu aufbaue, funktioniert der Ping von unseren Hosts 172.18.100.97-99 auf deren entfernten Host 194.38.218.5 aber auch wirklich nur dann! wenn alle drei subnets aus Phase2 aktiv sind, klappt das nicht mehr. Auch komisch ist, dass wir lediglich den entfernten Host 194.38.218.5 anpingen können, nicht aber 194.38.218.3 oder beispielsweise 194.38.218.7 und das obwohl laut Aussage des Admins auf entfernter Seite, freigeschaltet ist.
Ich bin kein IPsec Experte aber irgendwie habe ich das Gefühl, dass durch diese Config lediglich eine Einbahnstrasse existieren kann und zwar vom externen Dienstleister in unsere Richtung. Warum aber der Ping in andrer Richtung (also von uns zum entfernten Host) klappt und zwar nur dann wenn ich einen einzigen Tunnel deaktiviere, bleibt mir schleierhaft. Ebenso schleierhaft warum ich nur einen einzigen entfernten Host von denen anpingen kann.
Ich bin auf diesen ähnlichen Beitrag gestoßen.
Idee?
Die default Einstellung bei pfSense unter [FIREWALL] --> [NAT] --> [OUTBOUND] lautet "Automatic". Kann es sein, dass ich auf "HYBRID" Modus umstellen muss und dann extra noch manuelle mappings hinzufügen? Würde das den laufenden Betrieb der pfSense irgendwie merklich beeinflussen? Nicht, dass es mir dadurch sämtliche Schnittstellen verbiegt oder states/routes verändert und aktive Verbindungen kickt? ich bin mir nicht sicher, ob das Problem hier zu suchen wäre oder wo ich weiter ansetzen müsste. Wie gesagt, mit IPsec habe ich bisher nie gearbeitet und bin nicht so erfahren.
Bin für jeden Tip sehr dankbar.
ich stehe vor einem Problem und komme leider nicht mehr weiter. Wir haben eine IPsec Verbindung zu einem externen Dienstleister. Diese mussten wir auf deren Anforderung neu gestalten, da sich bei denen irgendwas geändert hatte (ich glaube die haben Firewall/Produkt gewechselt). Der IPsec Tunnel musste deshalb auf beiden Seiten neu konfiguriert werden, die Parameter haben wir vorgeschrieben bekommen vom externen Dienstleister. Neu hinzu kommt nun, dass die NAT betreiben wollen/müssen und demnach mussten wir das auf unserer Seite auch so einrichten. Der externe Dienstleister kann zwar zu uns problemlos gelangen, wir jedoch nicht auf deren Hosts wie es gewünscht wird.
Wir verwenden pfSense, hier eine kurze Erklärung der Netze:
Unsere Seite:
Subnet: 172.18.100.96/28 (also Hosts .97 bis .110)Gegenseite:
Subnet1: 194.38.218.0/26 (also Hosts .1 bis .62)Subnet2: 195.195.195.0/29
Subnet3: 196.196.196.0/26
Als NAT Subnet wurde von denen das Netz 172.16.0.0/29 (Hosts .1 bis .6) festgelegt.
Ziele:
(1) Die Gegenseite soll drei Hosts aus unserem Subnet 172.18.100.96/28 erreichen können, und zwar nach folgender Übersetzungstabelle:
-> sie sprechen die NAT IP-Adresse 172.16.0.1 an und sollen auf unseren Host 172.18.100.97 landen
-> sie sprechen die NAT IP-Adresse 172.16.0.2 an und sollen auf unseren Host 172.18.100.98 landen
-> sie sprechen die NAT IP-Adresse 172.16.0.3 an und sollen auf unseren Host 172.18.100.99 landen
(2) Außerdem müssen von unserem Subnet aus die Hosts aus dem entfernten Subnet1 (194.38.218.1-62) erreicht werden können.
Die Phase1 ist vermutlich uninteressant für das Problem, deshalb habe ich in dieser Beschreibung auch die öffentlichen Endpunkte IP-Adressen nicht angegeben. Phase1 steht soweit und ist i.O. Die Konfiguration auf unsrer pfSense habe ich entsprechend pfSense Anleitung wie folgt eingerichtet..
Von subnet2 und subnet3 habe ich nicht extra screenshots beigefügt, da erstmal nicht von Belangen. Es wurde jedoch äquivalent genauso eingerichtet wie in diesem screenshot von subnet1 gezeigt.
In der pfSense Konfiguration unter [Firewall] --> [NAT] --> [1:1] habe ich konfiguriert:
Interface = IPsec
External subnet IP = 172.16.0.1
Internal IP
Type=Single host
Address=172.18.100.97
Destination und alles weitere ist leer gelassen. Genau nach diesem Prinzip habe ich noch zwei weitere Einträge erstellt, eben für die genannten Zuordnungen. Dadurch kann der externe Dienstleister die IP-Adressen 172.16.0.1-3 aufrufen und landet auf unseren drei Servern. Funktioniert!
Problem:
Wir können von unseren Hosts (172.18.100.97-99) aus nicht auf das entfernte Subnet1 194.38.218.0/26 zugreifen. Aus unserer lokalen Firewallseite wird nichts geblockt, das habe ich ausgeschlossen, es sind keine Pakete geblockt. Der Admin der entfernten Seite hat ein paar Regeln auf deren Seite angepasst, wir wollten erstmal ICMP/Pings testen. Das schlug jedoch fehl. Durch trial-and-error habe ich folgende Entdeckung auf unsrer Seite gemacht--> sobald ich in der IPsec Konfiguration, unter Phase2 --> subnet3 deaktiviere und den Tunnel neu aufbaue, funktioniert der Ping von unseren Hosts 172.18.100.97-99 auf deren entfernten Host 194.38.218.5 aber auch wirklich nur dann! wenn alle drei subnets aus Phase2 aktiv sind, klappt das nicht mehr. Auch komisch ist, dass wir lediglich den entfernten Host 194.38.218.5 anpingen können, nicht aber 194.38.218.3 oder beispielsweise 194.38.218.7 und das obwohl laut Aussage des Admins auf entfernter Seite, freigeschaltet ist.
Ich bin kein IPsec Experte aber irgendwie habe ich das Gefühl, dass durch diese Config lediglich eine Einbahnstrasse existieren kann und zwar vom externen Dienstleister in unsere Richtung. Warum aber der Ping in andrer Richtung (also von uns zum entfernten Host) klappt und zwar nur dann wenn ich einen einzigen Tunnel deaktiviere, bleibt mir schleierhaft. Ebenso schleierhaft warum ich nur einen einzigen entfernten Host von denen anpingen kann.
Ich bin auf diesen ähnlichen Beitrag gestoßen.
Idee?
Die default Einstellung bei pfSense unter [FIREWALL] --> [NAT] --> [OUTBOUND] lautet "Automatic". Kann es sein, dass ich auf "HYBRID" Modus umstellen muss und dann extra noch manuelle mappings hinzufügen? Würde das den laufenden Betrieb der pfSense irgendwie merklich beeinflussen? Nicht, dass es mir dadurch sämtliche Schnittstellen verbiegt oder states/routes verändert und aktive Verbindungen kickt? ich bin mir nicht sicher, ob das Problem hier zu suchen wäre oder wo ich weiter ansetzen müsste. Wie gesagt, mit IPsec habe ich bisher nie gearbeitet und bin nicht so erfahren.
Bin für jeden Tip sehr dankbar.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 533159
Url: https://administrator.de/contentid/533159
Printed on: April 24, 2024 at 01:04 o'clock
13 Comments
Latest comment
Moin,
gehören dem Dienstleister die öffentlichen Adressen/Subnetze?
Ansonsten hat das wer eingerichtet, der absolut keine Ahnung hat was er dort macht. 194... Usw
Wenn die kein know how haben, würde ich die Finger von denen lassen.
Das ist gerade das erste was mir einfällt. Weiteres kann ich später beisteuern.
Edit: bezüglich NAT muss nur die PfSense Konfig auf manuel gestellt weder. Anschließend für jedes Destination Netz eine Regel mit NAT IP des IPsec Tunnels angelegt werden. Source ist euer internes Netz, von dem aus die entfernten Netze erreicht werden sollen.
Wenn nötig liefere ich ein Beispiel nach.
Das ist allerdings erstmal rudimentär. Was schreibt der Dienstleister vor? Auch wenn ich gerade eine starke Abneigung dem gegenüber denen vertrete.
Gruß
Spirit
gehören dem Dienstleister die öffentlichen Adressen/Subnetze?
Ansonsten hat das wer eingerichtet, der absolut keine Ahnung hat was er dort macht. 194... Usw
Wenn die kein know how haben, würde ich die Finger von denen lassen.
Das ist gerade das erste was mir einfällt. Weiteres kann ich später beisteuern.
Edit: bezüglich NAT muss nur die PfSense Konfig auf manuel gestellt weder. Anschließend für jedes Destination Netz eine Regel mit NAT IP des IPsec Tunnels angelegt werden. Source ist euer internes Netz, von dem aus die entfernten Netze erreicht werden sollen.
Wenn nötig liefere ich ein Beispiel nach.
Das ist allerdings erstmal rudimentär. Was schreibt der Dienstleister vor? Auch wenn ich gerade eine starke Abneigung dem gegenüber denen vertrete.
Gruß
Spirit
Hi Spirit, ich habe lediglich leicht obfuscation betrieben ;) aber die Netze gehören denen. Ist ein ganz großer bekannter Dienstleister in Deutschland, ich würde sagen eines des größten Systemhäuser in Deutschland.
Ich finde das Thema NAT in IPsec eh etwas komisch, ich hätte das nicht wirklich gewollt/gemacht, aber es ist eine Vorgabe von denen. Die verwalten hunderte wenn nicht tausende Kunden in Deutschland und die Umstrukturierung hätte diese Maßnahme mit dem NAT wohl erfordert (laut deren Aussage).
was genau meinst du mit "config auf manuell schalten" ? meintest du dasselbe wie ich, also unter FIREWALL --> NAT --> OUTBOUND und dann auf HYBRID schalten und anschließend manuelle mappings hinzufügen? falls ja, wie müsste so ein einzelnes Outbound NAT mapping dann aussehen? Pflichtfelder sind "Interface", "Protocol", "Source" und "Destination", das Feld "Translation" kann glaub leer bleiben. Müsste ich dann z.B. so was hier eintragen wie:
Interface = IPsec
Protocol = any
Source = Type:Network, Address:172.18.100.96/28, Source port:leerlassen
Destination = Type:Network, Address:194.38.218.0/26, Destination port:leerlassen
Translation = Address:Other Subnet:172.16.0.0/29, Pool Options=Default
?
oder vielleicht unter [System] --> [Advanced] --> [Firewall and NAT] --> "Network Address Translation" den Haken bei "Enable automatic outbound NAT for Reflection" schalten, aber ich denke das lass ich eher unberührt.
Fragen über Fragen, bin gespannt auf deine Antwort ... danke schonmal im Voraus
Ich finde das Thema NAT in IPsec eh etwas komisch, ich hätte das nicht wirklich gewollt/gemacht, aber es ist eine Vorgabe von denen. Die verwalten hunderte wenn nicht tausende Kunden in Deutschland und die Umstrukturierung hätte diese Maßnahme mit dem NAT wohl erfordert (laut deren Aussage).
was genau meinst du mit "config auf manuell schalten" ? meintest du dasselbe wie ich, also unter FIREWALL --> NAT --> OUTBOUND und dann auf HYBRID schalten und anschließend manuelle mappings hinzufügen? falls ja, wie müsste so ein einzelnes Outbound NAT mapping dann aussehen? Pflichtfelder sind "Interface", "Protocol", "Source" und "Destination", das Feld "Translation" kann glaub leer bleiben. Müsste ich dann z.B. so was hier eintragen wie:
Interface = IPsec
Protocol = any
Source = Type:Network, Address:172.18.100.96/28, Source port:leerlassen
Destination = Type:Network, Address:194.38.218.0/26, Destination port:leerlassen
Translation = Address:Other Subnet:172.16.0.0/29, Pool Options=Default
?
oder vielleicht unter [System] --> [Advanced] --> [Firewall and NAT] --> "Network Address Translation" den Haken bei "Enable automatic outbound NAT for Reflection" schalten, aber ich denke das lass ich eher unberührt.
Fragen über Fragen, bin gespannt auf deine Antwort ... danke schonmal im Voraus
Okay, wenn dem so ist, lassen wir das so stehen.
Bezüglich der NAT Konfig kannst du Outbound auf Hybrid stellen. Dann gelten die automatisch angelegten Regeln (durch die Sense selbst), sowie deine händisch erstellten.
Eine Regel würde dann wie folgt aussehen:
Wobei ich gerade für dein Netz eine 24er Maske eingetragen habe. Richtig wäre hier dann ein 28er Netz.
Bis hier dann zum NAT.
Wenn du bei dem Dienstleister drei Subnetze erreichen musst, dann solltest du hier drei Phase2 Konfigurationen anlegen. Für jedes Destination Netz eine. Normal nimmt man lieber ein Träger Netz und routet die anderen Geschichten darüber. Ist hier nur leider nicht vorgegeben.
Für die NAT Konfig auf deiner Seite sind ja ebenfalls drei Einträge erforderlich (jeweils pro entferntem Subnetz).
Bezüglich der NAT Konfig kannst du Outbound auf Hybrid stellen. Dann gelten die automatisch angelegten Regeln (durch die Sense selbst), sowie deine händisch erstellten.
Eine Regel würde dann wie folgt aussehen:
Wobei ich gerade für dein Netz eine 24er Maske eingetragen habe. Richtig wäre hier dann ein 28er Netz.
Bis hier dann zum NAT.
Wenn du bei dem Dienstleister drei Subnetze erreichen musst, dann solltest du hier drei Phase2 Konfigurationen anlegen. Für jedes Destination Netz eine. Normal nimmt man lieber ein Träger Netz und routet die anderen Geschichten darüber. Ist hier nur leider nicht vorgegeben.
Für die NAT Konfig auf deiner Seite sind ja ebenfalls drei Einträge erforderlich (jeweils pro entferntem Subnetz).
Ok, cross-posting während ich meine config oben nochmals editiert hatte. Ich hatte unter "Translation" noch das NAT Netz mit angegeben, aber das hast du leer belassen. Ich bin mir sicher, dass deine Version stimmt :D
Die settings habe ich soweit glaub verstanden, wie auch in der pfSense Anleitung für diesen Abschnitt erklärt. Kannst du mir kurz sagen, ob ich ruhigen Gewissens auf APPLY klicken kann, sobald ich auf Hybrid umgestellt habe? Kappt das Verbindungen, kann das was schief laufen ? Eigentlich würde ich das nicht erwarten, denn beim Hybridmodus greifen ja die automatisch erstellten Zeilen ebenfalls. Aber ich will mir sicher sein, da produktive pfSense
Die settings habe ich soweit glaub verstanden, wie auch in der pfSense Anleitung für diesen Abschnitt erklärt. Kannst du mir kurz sagen, ob ich ruhigen Gewissens auf APPLY klicken kann, sobald ich auf Hybrid umgestellt habe? Kappt das Verbindungen, kann das was schief laufen ? Eigentlich würde ich das nicht erwarten, denn beim Hybridmodus greifen ja die automatisch erstellten Zeilen ebenfalls. Aber ich will mir sicher sein, da produktive pfSense
Ich war auch gerade etwas zu schnell beim schreibe.
Also locales Netz muss natürlich jeweils dein Client Netz eingetragen werden.
Unter "Translation" muss definitiv das IPsec Interface auf deiner Seite stehen! (Interface Adress ist hier korrekt, da automatisch die korrekte Adresse genutzt wird)
Wenn es noch nicht klar sein sollte, kann ich später korrekte Screenshots liefern.
Dafür wäre dann aber dein locales Netz von nöten.
Also locales Netz muss natürlich jeweils dein Client Netz eingetragen werden.
Unter "Translation" muss definitiv das IPsec Interface auf deiner Seite stehen! (Interface Adress ist hier korrekt, da automatisch die korrekte Adresse genutzt wird)
Wenn es noch nicht klar sein sollte, kann ich später korrekte Screenshots liefern.
Dafür wäre dann aber dein locales Netz von nöten.
Also ich habe zwischenzeitlich auf Hybrid geschaltet und auch ein einzelnes manuelles mapping hinzugefügt:
Interface = IPsec
Protocol = any
Source
Type=Network
Address=172.18.100.96/28
Source port=leer
Destination
Type=Network
Address=194.38.218.0/26
Destination port=leer
Translation
Address=Other
Subnet=172.16.0.0/29
Pool Options=Default
Settings gespeichert, übernommen, IPsec service restartet, hat sich aber nix geändert, tut leider nicht wie es soll.
Dann folgendes abgeändert auf:
Translation
Address=Interface address
Port=leer
Static Port = unchecked
leider keine Änderung nach Neustart des IPsec Tunnels. Aber ich habe durch weitere Analyse irgendwas andres "komisches" festgestellt, was ich mir bisher noch nicht erklären kann. Ich habe ja insgesamt 3 Tunnel in Phase2 konfiguriert unter IPsec Konfiguration. Wenn ich das subnet3 deaktiviere, den IPsec Tunnel trenne und wiederaufbaue, klappen die Pings. Ich habe sämtliche Kombinationen der drei subnets ausprobiert und die Ergebnisse sind wie folgt:
alle Subnets sind belassen wie ursprünglich konfiguriert, also subnet1, subnet2 und subnet3 sind konfiguriert in der IPsec Phase 2. Den Tunnel trenne ich manuell via Status-->IPsec, so dass er inaktiv ist (nicht verbunden). Wenn jetzt Pakete fliessen und somit eine IPsec Verbindung benötigt wird, dann baut sich der SA child just in diesem Moment auf und ich sehe das sofort in dem Statusmonitor auf der pfSense. Das kann ich ausnutzen um live zu monitoren, was meine pfSense macht.
Test1 (alle subnets sind konfiguriert und aktiviert):
subnet1
subnet2
subnet3
==> setz ich von unserem lokalen subnet einen Ping ab auf den Host z.B. 194.38.218.4 ab, dann schlägt der Ping fehl. In der IPsec Statusübersicht sehe ich, dass jedoch nicht wie erwartet das Subnet1 child SA aufgebaut wurde, sondern das subnet3 ! WHY??
Test2 (jetzt habe ich dieses problematisch vermutete subnet3 einfach mal deaktiviert, so dass es nicht genutzt wird):
subnet1
subnet2
==> ich mach wieder dasselbe und sende "ping 194.38.218.4" und daraufhin seh ich sofort dass der Ping funktioniert und im Status angezeigt wird, dass der Tunnel des Netzes Subnet1: 194.38.218.0/26 aufgebaut wurde. Also prima!
Test3 (jetzt habe ich nur das gewünschte subnet1 aktiviert belassen, aus purer Neugier:
subnet1
==> Pings funktionieren, richtiges subnet1 wurde aufgebaut
Test4 (jetzt habe ich das benötigte subnet1 deaktiviert belassen, mal sehen was passiert):
subnet2
subnet3
==> Pings schlagen FEHL, wie erwartet. Aber ich sehe wieder sofort, dass das problematisch vermutete subnet3 aufgebaut wurde. Er versucht also wieder via subnet3 diese IP-Adresse zu erreichen.
finaler Test5 (jetzt lasse ich nur subnet2 aktiviert):
subnet2
==> der Tunnel ist getrennt, kein child sa aufgebaut. Setze ich nun den Ping-Befehl ab, passiert gar nix. Pings schlagen natürlich fehl, aber ich sehe in der Übersicht, dass auch kein Tunnel aufgebaut wurde. Daraus folgere ich, dass nicht irgendein verfügbarer Tunnel genommen wird. Denn in diesem Test stand ja nur subnet2 zur Verfügung.
Mein Fazit soweit:
aus irgendeinem mir unerklärlichen Grund, versucht unsere Firewall beim Pingen des Hosts 194.38.218.* durch das Subnet3 zu gehen, obwohl eigentlich das Subnet1 passend wäre. Schalte ich forciert das Subnet3 aus, dann klappt das auch über Subnet1. Woher nimmt sich die pfSense also die Information, über Subnet3 zu gehen, insofern dieses Phase2 subnet aktiviert ist in meiner IPsec Konfig. ?
Verstehe ich nicht. Hat mein Problem also gar nicht erst mit "Outbound NAT" zu tun, sondern das Problem liegt wo ganz anders?
Interface = IPsec
Protocol = any
Source
Type=Network
Address=172.18.100.96/28
Source port=leer
Destination
Type=Network
Address=194.38.218.0/26
Destination port=leer
Translation
Address=Other
Subnet=172.16.0.0/29
Pool Options=Default
Settings gespeichert, übernommen, IPsec service restartet, hat sich aber nix geändert, tut leider nicht wie es soll.
Dann folgendes abgeändert auf:
Translation
Address=Interface address
Port=leer
Static Port = unchecked
leider keine Änderung nach Neustart des IPsec Tunnels. Aber ich habe durch weitere Analyse irgendwas andres "komisches" festgestellt, was ich mir bisher noch nicht erklären kann. Ich habe ja insgesamt 3 Tunnel in Phase2 konfiguriert unter IPsec Konfiguration. Wenn ich das subnet3 deaktiviere, den IPsec Tunnel trenne und wiederaufbaue, klappen die Pings. Ich habe sämtliche Kombinationen der drei subnets ausprobiert und die Ergebnisse sind wie folgt:
alle Subnets sind belassen wie ursprünglich konfiguriert, also subnet1, subnet2 und subnet3 sind konfiguriert in der IPsec Phase 2. Den Tunnel trenne ich manuell via Status-->IPsec, so dass er inaktiv ist (nicht verbunden). Wenn jetzt Pakete fliessen und somit eine IPsec Verbindung benötigt wird, dann baut sich der SA child just in diesem Moment auf und ich sehe das sofort in dem Statusmonitor auf der pfSense. Das kann ich ausnutzen um live zu monitoren, was meine pfSense macht.
Test1 (alle subnets sind konfiguriert und aktiviert):
subnet1
subnet2
subnet3
==> setz ich von unserem lokalen subnet einen Ping ab auf den Host z.B. 194.38.218.4 ab, dann schlägt der Ping fehl. In der IPsec Statusübersicht sehe ich, dass jedoch nicht wie erwartet das Subnet1 child SA aufgebaut wurde, sondern das subnet3 ! WHY??
Test2 (jetzt habe ich dieses problematisch vermutete subnet3 einfach mal deaktiviert, so dass es nicht genutzt wird):
subnet1
subnet2
==> ich mach wieder dasselbe und sende "ping 194.38.218.4" und daraufhin seh ich sofort dass der Ping funktioniert und im Status angezeigt wird, dass der Tunnel des Netzes Subnet1: 194.38.218.0/26 aufgebaut wurde. Also prima!
Test3 (jetzt habe ich nur das gewünschte subnet1 aktiviert belassen, aus purer Neugier:
subnet1
==> Pings funktionieren, richtiges subnet1 wurde aufgebaut
Test4 (jetzt habe ich das benötigte subnet1 deaktiviert belassen, mal sehen was passiert):
subnet2
subnet3
==> Pings schlagen FEHL, wie erwartet. Aber ich sehe wieder sofort, dass das problematisch vermutete subnet3 aufgebaut wurde. Er versucht also wieder via subnet3 diese IP-Adresse zu erreichen.
finaler Test5 (jetzt lasse ich nur subnet2 aktiviert):
subnet2
==> der Tunnel ist getrennt, kein child sa aufgebaut. Setze ich nun den Ping-Befehl ab, passiert gar nix. Pings schlagen natürlich fehl, aber ich sehe in der Übersicht, dass auch kein Tunnel aufgebaut wurde. Daraus folgere ich, dass nicht irgendein verfügbarer Tunnel genommen wird. Denn in diesem Test stand ja nur subnet2 zur Verfügung.
Mein Fazit soweit:
aus irgendeinem mir unerklärlichen Grund, versucht unsere Firewall beim Pingen des Hosts 194.38.218.* durch das Subnet3 zu gehen, obwohl eigentlich das Subnet1 passend wäre. Schalte ich forciert das Subnet3 aus, dann klappt das auch über Subnet1. Woher nimmt sich die pfSense also die Information, über Subnet3 zu gehen, insofern dieses Phase2 subnet aktiviert ist in meiner IPsec Konfig. ?
Verstehe ich nicht. Hat mein Problem also gar nicht erst mit "Outbound NAT" zu tun, sondern das Problem liegt wo ganz anders?
Hi,
sieht nach einem VPN mit T-*** aus.
Ist meines Wissens nach nicht mit einer (1) pfSense lösbar.
Du benötigst zwei (2) pfSensen, oder 1pfSense und 1 whatever Router.
Der richtigere Ausdruck für <NAT Subnet> ist <Transfer Net>.
VPN Endpunkt des Dienstleisters <----->eure pfSense 1(VPN Endpunkt<->Transfernetz<->pfSense 2 (3 oder4xNAT Regeln)<-> euer Subnet.
Eine fertige Konfig habe ich leider nicht mehr zur Hand.
BTW: welche pfSense Version verwendet Ihr ?
CH
sieht nach einem VPN mit T-*** aus.
Ist meines Wissens nach nicht mit einer (1) pfSense lösbar.
Du benötigst zwei (2) pfSensen, oder 1pfSense und 1 whatever Router.
Der richtigere Ausdruck für <NAT Subnet> ist <Transfer Net>.
VPN Endpunkt des Dienstleisters <----->eure pfSense 1(VPN Endpunkt<->Transfernetz<->pfSense 2 (3 oder4xNAT Regeln)<-> euer Subnet.
Eine fertige Konfig habe ich leider nicht mehr zur Hand.
BTW: welche pfSense Version verwendet Ihr ?
CH
2.2-RELEASE
Dann solltest du schleunigst updaten. Aktuell ist Release 2.4.4p3
es gab Gründe, warum wir nicht hochgezogen hatten. Ist nun der Versionsstand von 2.2-RELEASE also der Grund, warum es nicht klappt? Das würde keinen Sinn ergeben nach oben beschriebener Symptomatik.
Ich weiß das am IPsec Konstrukt in den nachfolgenden Releases etwas gedreht wurde. Gut möglich das es danach geht.
Außerdem macht es aus Sicherheitsgründen keinen Sinn auf einem veralten release zu fahren.
Ich muss dazu allerdings auch sagen, dass ich mit dem 2.2er Release noch kein IPsec Tunnel über mehrere Phase2 Einträge gefahren habe.
Außerdem macht es aus Sicherheitsgründen keinen Sinn auf einem veralten release zu fahren.
Ich muss dazu allerdings auch sagen, dass ich mit dem 2.2er Release noch kein IPsec Tunnel über mehrere Phase2 Einträge gefahren habe.
im Prinzip schon, ich kann mich erinnern dass damals das nächstkommende einen ganz üblen Bug hatte. Ich hatte das "live" im IRC mitverfolgt und wir haben "nicht" aktualisiert sondern abgewartet. Das ist schon länger her, klar ist eine Aktualisierung immer gut. Ich kann aber nicht glauben, dass DAS der Grund sein sollte weil eben die Symptome,Tests,Auswirkungen nicht dafür sprechen. Vor 2.2 wurde racoon für IPsec eingesetzt, ab 2.2 dann auf strongSwan umgerüstet. Das ist die grundlegenste Änderung, die mir bekannt ist.
PS: Heute sehe ich nun, ohne dass ich irgendwas geändert habe, dass die Pings funktionieren obwohl ich alle drei Netze aktiviert hatte. Habe nun mehrfach getestet, und nun scheint's richtig zu funktionieren. Ich schätze mal, dass meine Mail an die Gegenseite/IT-Technik mit dieser Info zu irgendwas bewegt hat und sich Änderungen ergeben haben. Ich warte noch mal auf deren Antwort mit weiteren Infos ab, ob und was da jetzt geändert wurde. Vielleicht liegt's doch an der Gegenseite?
PS: Heute sehe ich nun, ohne dass ich irgendwas geändert habe, dass die Pings funktionieren obwohl ich alle drei Netze aktiviert hatte. Habe nun mehrfach getestet, und nun scheint's richtig zu funktionieren. Ich schätze mal, dass meine Mail an die Gegenseite/IT-Technik mit dieser Info zu irgendwas bewegt hat und sich Änderungen ergeben haben. Ich warte noch mal auf deren Antwort mit weiteren Infos ab, ob und was da jetzt geändert wurde. Vielleicht liegt's doch an der Gegenseite?
==> Problem GELÖST
es hat an der Gegenseite gelegen und zwar an 2 Punkten:
- es wurde falsch (bzw. auf weiterem Weg)genattet, daher auch das von mir beschriebene Symptom mit der SA
- Regelwerk musste angepasst werden, da hat noch was gefehlt
Wenn das nicht so wäre, hätte ich mich schwer gewundert. Trotzdem danke euch allen!
es hat an der Gegenseite gelegen und zwar an 2 Punkten:
- es wurde falsch (bzw. auf weiterem Weg)genattet, daher auch das von mir beschriebene Symptom mit der SA
- Regelwerk musste angepasst werden, da hat noch was gefehlt
Wenn das nicht so wäre, hätte ich mich schwer gewundert. Trotzdem danke euch allen!
