11
PfSense IPsec hub and spoke
Moin zusammen ...
... Ich glaube einfach, ich benötige statt der "Suchfunktion" eine "Finde-Funktion" ;)
Jedenfalls bin ich auch in der Sammlung diverser Tutorials nicht fündig geworden.
Es geht um die Thematik Hub and Spoke.
An allen Standorten ist eine pfSense im Einsatz.
Exemplarisch habe ich mal folgende IP Bereiche festgelegt.
1. Es exisitert ein IPsec-Tunnel von Standort A (192.168.1.x) zur Hauptstelle X (192.168.0.x).
2. Es exisitert ein IPsec-Tunnel von Standort B (192.168.2.x) zur Hauptstelle X (192.168.0.x).
Primäre Nutzung des Tunnels liegt eigentlich darin, dass die DC in A und B mit der Haupstelle X kommunizieren können.
Das läuft auch ziemlich rund.
Jetzt benötigen aber einige Mitarbeiter in Standort A Zugang zu einem Terminalserver in Standort B, weil dort eine spezielle Software verwendet wird.
Es geht mir nicht darum, einfach einen weiteren Tunnel zw. A und B einzurichten sondern die bestehende Verbindung anzupassen.
Die Ansätze, die ich hierzu im WWW finden konnte, führten bislang nicht zur Lösung.
Die Grundidee war das erweitern der Tunnel um einen weiteren Phase-2 Eintrag mit dem jeweiligen SubNet.
Das alleine scheint aber nicht zu reichen. Irgendwo muss bestimmt noch was zum Routing hinterlegt werden.
Hoffe, jmd. hat eine praktikable Idee, wie das realisierbar ist.
Grüße
Der Rico
... Ich glaube einfach, ich benötige statt der "Suchfunktion" eine "Finde-Funktion" ;)
Jedenfalls bin ich auch in der Sammlung diverser Tutorials nicht fündig geworden.
Es geht um die Thematik Hub and Spoke.
An allen Standorten ist eine pfSense im Einsatz.
Exemplarisch habe ich mal folgende IP Bereiche festgelegt.
1. Es exisitert ein IPsec-Tunnel von Standort A (192.168.1.x) zur Hauptstelle X (192.168.0.x).
2. Es exisitert ein IPsec-Tunnel von Standort B (192.168.2.x) zur Hauptstelle X (192.168.0.x).
Primäre Nutzung des Tunnels liegt eigentlich darin, dass die DC in A und B mit der Haupstelle X kommunizieren können.
Das läuft auch ziemlich rund.
Jetzt benötigen aber einige Mitarbeiter in Standort A Zugang zu einem Terminalserver in Standort B, weil dort eine spezielle Software verwendet wird.
Es geht mir nicht darum, einfach einen weiteren Tunnel zw. A und B einzurichten sondern die bestehende Verbindung anzupassen.
Die Ansätze, die ich hierzu im WWW finden konnte, führten bislang nicht zur Lösung.
Die Grundidee war das erweitern der Tunnel um einen weiteren Phase-2 Eintrag mit dem jeweiligen SubNet.
Das alleine scheint aber nicht zu reichen. Irgendwo muss bestimmt noch was zum Routing hinterlegt werden.
Hoffe, jmd. hat eine praktikable Idee, wie das realisierbar ist.
Grüße
Der Rico
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: 539060
Url: https://administrator.de/contentid/539060
Printed on: April 19, 2024 at 05:04 o'clock
11 Comments
Latest comment
Das ist einfach und schnell gemacht indem du in den Phase 2 SA Definitionen der Standort Tunnel einfach auch den Netzwerk Traffic A nach B erlaubst ! Bedenke das es auch für den Rückweg B nach A erlaubt sein muss. Damit wird dann A-B Traffic auch in den jeweiligen Tunnel geroutet.
Das ist in 10 Minuten konfiguriert und rennt fehlerlos.
Dieser Thread erklärt wie es geht:
2 PfSensen mit OpenVPN verbinden 1x Server 1x Client
Denk dir das dortige OVPN als 2ten IPsec Link.
Das ist in 10 Minuten konfiguriert und rennt fehlerlos.
Dieser Thread erklärt wie es geht:
2 PfSensen mit OpenVPN verbinden 1x Server 1x Client
Denk dir das dortige OVPN als 2ten IPsec Link.
Danke, @aqui, für die schnelle Rückmeldung.
Vielleicht schaffe ich es, das gleich noch zu testen.
Falls nicht, dann spät. Montag ... Rückmeldung folgt !
Schönes WE an dieser Stelle schon einmal.
Vielleicht schaffe ich es, das gleich noch zu testen.
Falls nicht, dann spät. Montag ... Rückmeldung folgt !
Schönes WE an dieser Stelle schon einmal.
Hi,
IPsec Hub und Spoke funktioniert meines Wissens nach nicht mit pfSense (und OPNsense).
Ist (war ?) ein Mangel von pfSense.
kann sein, daß es inzwischen mit route based IPsec (siehe hier) funktioniert.
CH
IPsec Hub und Spoke funktioniert meines Wissens nach nicht mit pfSense (und OPNsense).
Ist (war ?) ein Mangel von pfSense.
kann sein, daß es inzwischen mit route based IPsec (siehe hier) funktioniert.
CH
Entweder funktioniert es tatsächlich nicht auf diesem einfachen Weg oder ich habe hier was falsch gemacht.
Jedenfalls werden bei mir in den pfSense keine zweiten Phase-2 Einträge im VPN-Status angezeigt.
Auch nicht nach restart der Services oder einem re-connect der Tunnel.
zweite Phase-2 in den IPsec Tunneln angelegt:
Standort A <-> Hauptstelle
LocalNetwork 192.168.2.0/24
RemoteNetwork 192.168.0.0/24
Standort B <-> Hauptstelle
LocalNetwork 192.168.1.0/24
RemoteNetwork 192.168.0.24
Hauptstelle <-> Standort A
LocalNetwork 192.168.2.0/24
RemoteNetwork 192.168.0.0/24
Hauptstelle <-> Standort B
LocalNetwork 192.168.1.0/24
RemoteNetwork 192.168.0.0/24
Das alleine scheint nicht zu reichen.
Jedenfalls werden bei mir in den pfSense keine zweiten Phase-2 Einträge im VPN-Status angezeigt.
Auch nicht nach restart der Services oder einem re-connect der Tunnel.
zweite Phase-2 in den IPsec Tunneln angelegt:
Standort A <-> Hauptstelle
LocalNetwork 192.168.2.0/24
RemoteNetwork 192.168.0.0/24
Standort B <-> Hauptstelle
LocalNetwork 192.168.1.0/24
RemoteNetwork 192.168.0.24
Hauptstelle <-> Standort A
LocalNetwork 192.168.2.0/24
RemoteNetwork 192.168.0.0/24
Hauptstelle <-> Standort B
LocalNetwork 192.168.1.0/24
RemoteNetwork 192.168.0.0/24
Das alleine scheint nicht zu reichen.
Jedenfalls werden bei mir in den pfSense keine zweiten Phase-2 Einträge im VPN-Status angezeigt.
Dann hast du da was falsch gemacht und falsche Credentials eingetragen denn damit kommen die Tunnel dann nicht hoch. Kannst du auch in den System Logs unter IPsec immer sehen !Das sieht man auch schon oben...
In den Paketen ist doch immer ein Flow mit Absender IPs aus A (192.168.1.0) und Ziel IPs aus B (192.168.2.0) und vice versa.
DIESE muss du in der zweiten P2 klassifizieren. Steht doch auch in dem oben als Referenz geposteten Thread. Hier hast du vermutlich einen Denkfehler bei den Sende und Empfangs IPs gemacht ?! Nachdenken über den IP Flow hilft also, denn mit der Phase 2 klassifizierst du den Traffic der in den Tunnel geht !
Die 0er IP der Hauptstelle ist da natürlich Unsinn, denn die ist ja schon längst definiert und hat mit dem IP Paket Flow A <-> B ja nix zu tun weil diese IPs da ja gar nicht vorkommen !Richtig ist: //
2te Phase 2 Standort A <-> Hauptstelle
LocalNetwork 192.168.1.0/24
RemoteNetwork 192.168.2.0/24
2te Phase 2 Standort B <-> Hauptstelle
LocalNetwork 192.168.2.0/24
RemoteNetwork 192.168.1.0/24
2te Phase Hauptstelle <-> Standort A
LocalNetwork 192.168.2.0/24
RemoteNetwork 192.168.1.0/24
2te Phase Hauptstelle <-> Standort B
LocalNetwork 192.168.1.0/24
RemoteNetwork 192.168.2.0/24
So wird ein Schuh draus !
Es gibt noch eine zweite, einfachere Option, die aber nur funktioniert wenn einer der 2 Standorte A oder B eine feste statische IP hat. Haben beide dynamische IPs geht es nicht.
Dann kannst du ganz einfach von A und B direkt eine zweite VPN Verbindung aufbauen ohne die zweiten Phase 2 Einträge. Dazu ist aber an einem Standort eine feste IP zwingend. Ist die vorhanden ?
Da bin ich nochmal ...
... muss mich für den Tippfehler entschuldigen.
Es ist aktuell genauso eingerichtet, wie in Deinem letzten Beitrag, Aqui ...
Dennoch sehe ich keinen zweiten Aufbau eines Tunnels.
Auch in den Logs sehe ich dazu nix.
Wenigstens das weitere SubNet sollte da doch irgendwo zu finden sein.
Und ja, alle Standorte haben feste IP.
Aber es geht mir ja nicht um den zweiten Tunnel. Das geht ja.
Aber es dreht sich ja im Endeffekt dann nicht nur um eine Aussenstelle.
Und wenn Hub & Spoke mit pfSense und IPsec nicht geht, dann brauche ich was anderes, wenn ich kein Full Mesh IPsec aufbauen will.
Ein Tunnel pro Standort zur Hauptstelle mit der Option, ggf. einen weiteren Standort über die Zentrale zu erreichen.
... muss mich für den Tippfehler entschuldigen.
Es ist aktuell genauso eingerichtet, wie in Deinem letzten Beitrag, Aqui ...
Dennoch sehe ich keinen zweiten Aufbau eines Tunnels.
Auch in den Logs sehe ich dazu nix.
Wenigstens das weitere SubNet sollte da doch irgendwo zu finden sein.
Und ja, alle Standorte haben feste IP.
Aber es geht mir ja nicht um den zweiten Tunnel. Das geht ja.
Aber es dreht sich ja im Endeffekt dann nicht nur um eine Aussenstelle.
Und wenn Hub & Spoke mit pfSense und IPsec nicht geht, dann brauche ich was anderes, wenn ich kein Full Mesh IPsec aufbauen will.
Ein Tunnel pro Standort zur Hauptstelle mit der Option, ggf. einen weiteren Standort über die Zentrale zu erreichen.
Dennoch sehe ich keinen zweiten Aufbau eines Tunnels.
Es gibt auch keinen 2ten Tunnel in dem Sinne, nur beide SAs müssen aktiv sein und im IPsec Status angezeigt werden das sie (die SAs) richtig negotiated sind. Leider fehlen hier die Screenshots dazu 
Und ja, alle Standorte haben feste IP.
Dann ist es doch viel einfacher das wieder zu entfernen und einen direkten Tunnel zwischen A und B zu etablieren.Ist doch dann viel einfacher !
Aber es geht mir ja nicht um den zweiten Tunnel. Das geht ja.
Der zwischen A und B oder was meinst du ??Aber warum willst du den denn nicht ? Willst du das aller Traffic dann zentral über den Hauptstandort geroutet wird ? Wenn ja dann muss du es so mit der 2ten Phase 2 lösen.
Und wenn Hub & Spoke mit pfSense und IPsec nicht geht,
Hub and Spoke funktioniert fehlerfrei. Das kannst du ja schon an der Tatsache mit dem o.a. geposteten Beispielthread sehen. Nur das das 2te Netz da eben OVPN ist.Ich checke das hier und geb dir ein Feedback.
So, war zu erwarten das es sauber funktioniert aber weil du es bist und wir ja am Wochenende eh nichts anderes zu tun haben als für andere hier simple Standards zu testen und zu posten nun nochmals die erforderlichen Schritte damit auch du es verstehst.
In Ermangelung einer dritten pfSense musste ich einen Mikrotik Router nehmen. Sorry dafür aber das ist ja vollkommen Wumpe letztendlich was da für VPN Hardware ist.
Das Design dürfte mit deinem völlig identisch sein:
Fakt ist das es sauber funktioniert !!
Die Schritte im Einzelnen:
1.) Hauptstelle VPN Tunnel einrichten:
2.) Erste Nebenstelle (pfSense) VPN Tunnel einrichten:
3.) Zweite Nebenstelle (Mikrotik) VPN Tunnel einrichten:
Peer auf die Hauptstelle:
Hier kann man sofort sehen das beide Phase 2 SAs sofort in den established Staus gehen also online sind !
Beim Mikrotik muss man noch dafür sorgen das der VPN Traffic nicht über das NAT (Adress Translation) der Firewall geht. Das ist aber MT spezifisch, die pfSense macht das glücklicherweise per Default richtig:
3.) Check des VPN Tunnels und der zwei SAs in der Nebenstelle:
Auch hier ist der Tunnel zur Hauptstelle established und beide P2 SAs sind aktiv wie man ja auch deutlich an den hochzählenden Paket Countern sehen kann !
Dashboard zeigt somit auch beide P2 Verbindungen aktiv:
4.) Check der beiden VPN Tunnel und der vier SAs in der Hauptstelle:
Tunnel zur pfSense Nebenstelle:
Auch hier Tunnel established und beide P2 SAs sind aktiv (Paket Counter) !
Tunnel zur Mikrotik Nebenstelle:
Ebenso hier Tunnel established und beide P2 SAs sind aktiv (Paket Counter) !
Dashboard zeigt auch hier beide P2 Verbindungen aktiv:
5.) Finaler Ping Check zwischen den zwei Nebenstellen:
pfSense Nebenstelle LAN auf Mikrotik LAN:
Mikrotik Nebenstelle LAN auf pfSense Nebenstelle LAN:
Und um wirklich ganz sicher zu gehen auch nochmal ein Client Ping aus dem pfSense Nebenstellen Netz auf den MT:
Fazit:
Works as designed !!!
Irgendwo liegt bei dir also der Fehler zwischen den Kopfhörern !
Wenn du es unbedingt noch brauchst kannst du natürlich auch nochmals die einzelnen Screenshots der IPsec Tunnel Setups der beiden pfSense extra bekommen. Zum Mikrotik ist oben ja schon alles ersichtlich.
In Ermangelung einer dritten pfSense musste ich einen Mikrotik Router nehmen. Sorry dafür aber das ist ja vollkommen Wumpe letztendlich was da für VPN Hardware ist.
Das Design dürfte mit deinem völlig identisch sein:
Fakt ist das es sauber funktioniert !!
Die Schritte im Einzelnen:
1.) Hauptstelle VPN Tunnel einrichten:
2.) Erste Nebenstelle (pfSense) VPN Tunnel einrichten:
3.) Zweite Nebenstelle (Mikrotik) VPN Tunnel einrichten:
Peer auf die Hauptstelle:
Beim Mikrotik muss man noch dafür sorgen das der VPN Traffic nicht über das NAT (Adress Translation) der Firewall geht. Das ist aber MT spezifisch, die pfSense macht das glücklicherweise per Default richtig:
3.) Check des VPN Tunnels und der zwei SAs in der Nebenstelle:
Dashboard zeigt somit auch beide P2 Verbindungen aktiv:
4.) Check der beiden VPN Tunnel und der vier SAs in der Hauptstelle:
Tunnel zur pfSense Nebenstelle:
Tunnel zur Mikrotik Nebenstelle:
Dashboard zeigt auch hier beide P2 Verbindungen aktiv:
5.) Finaler Ping Check zwischen den zwei Nebenstellen:
pfSense Nebenstelle LAN auf Mikrotik LAN:
Mikrotik Nebenstelle LAN auf pfSense Nebenstelle LAN:
Und um wirklich ganz sicher zu gehen auch nochmal ein Client Ping aus dem pfSense Nebenstellen Netz auf den MT:
C:\Users>ipconfig
Windows-IP-Konfiguration
Ethernet-Adapter LAN-Verbindung:
Verbindungsspezifisches DNS-Suffix: pc.home.arpa
Verbindungslokale IPv6-Adresse . : fe80::f488:debb:3adf:f237%20
IPv4-Adresse . . . . . . . . . . : 172.17.1.140
Subnetzmaske . . . . . . . . . . : 255.255.255.128
Standardgateway . . . . . . . . . : 172.17.1.129
C:\Users>ping 192.168.88.1
Ping wird ausgeführt für 192.168.88.1 mit 32 Bytes Daten:
Antwort von 192.168.88.1: Bytes=32 Zeit=2ms TTL=62
Antwort von 192.168.88.1: Bytes=32 Zeit=2ms TTL=62
Antwort von 192.168.88.1: Bytes=32 Zeit=2ms TTL=62
Ping-Statistik für 192.168.88.1:
Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 2ms, Maximum = 2ms, Mittelwert = 2ms Works as designed !!!
Irgendwo liegt bei dir also der Fehler zwischen den Kopfhörern !
Wenn du es unbedingt noch brauchst kannst du natürlich auch nochmals die einzelnen Screenshots der IPsec Tunnel Setups der beiden pfSense extra bekommen. Zum Mikrotik ist oben ja schon alles ersichtlich.
Nochwas vergessen....sorry !
Der Vollständigkeit halber: Falls deine IPsec Verbindung mit dem moderneren IKEv2 Protokoll realisiert wurde geht das natürlich selbstredend auch.
Hier am Beispiel der Haupt und Nebenstelle:
1.) Nebenstelle Phase 1 Konfig für IKEv2:
2.) Nebenstelle Phase 2 (auf Hauptstelle) Konfig für IKEv2:
3.) Nebenstelle Phase 2 (auf Mikrotik) Konfig für IKEv2:
4.) Nebenstelle IKEv2 Session Info:
5.) Hauptstelle IPsec P1/P2 Konfig für IKEv2:
Wenn du es nicht schon hast solltest du IKEv2 immer vorziehen in der IPsec Konfig !
Auch hier: Works as designed !
Der Vollständigkeit halber: Falls deine IPsec Verbindung mit dem moderneren IKEv2 Protokoll realisiert wurde geht das natürlich selbstredend auch.
Hier am Beispiel der Haupt und Nebenstelle:
1.) Nebenstelle Phase 1 Konfig für IKEv2:
2.) Nebenstelle Phase 2 (auf Hauptstelle) Konfig für IKEv2:
3.) Nebenstelle Phase 2 (auf Mikrotik) Konfig für IKEv2:
4.) Nebenstelle IKEv2 Session Info:
5.) Hauptstelle IPsec P1/P2 Konfig für IKEv2:
Auch hier: Works as designed !
Danke, Danke und nochmals Danke ;)
Und vielen Dank für die Zeit, die Du am WE geopfert hast, Aqui.
Der Fehler lag tatsächlich vor der Tastatur ;)
In den Aussenstellen hatte ich aus unerklärlichen Gründen das LocalSubnet falsch gesetzt.
In A stand als LocalSubnet das Netz von B und als RemoteSubnet die Hauptstelle drin.
In der Haupstelle war alles OK.
Nachdem das korrigiert war und die Dienste auf allen pfSense neu gestartet waren, hatte ich noch immer nur eine Phase 2 im Status.
Erst nach einem manuellen Re-Connect tauchten beide auf.
Ein Ping A nach B oder umgekehrt kam trotzdem nicht zustande.
Da mir während der Fehlersuche nichts auffiel, habe ich es dann mit dem Ping nochmals probiert.
Seltsamerweise funktionierte es diesmal.
Jedenfalls dauert es z.B. bei einem Neustart der Dienste auf der pfSense von Standort B einige Zeit, bis beide Phase2 Einträge im Status stehen.
Einer von beiden ist immer sofort sichtbar, der andere kommt nach ca. 30-60Sek.
Und dann läuft es wieder.
Scheint ein wenig zu dauern, bis die Verbindung wieder voll funktionell ist !? Liegt das am Re-Keying der Phasen?
Und vielen Dank für die Zeit, die Du am WE geopfert hast, Aqui.
Der Fehler lag tatsächlich vor der Tastatur ;)
In den Aussenstellen hatte ich aus unerklärlichen Gründen das LocalSubnet falsch gesetzt.
In A stand als LocalSubnet das Netz von B und als RemoteSubnet die Hauptstelle drin.
In der Haupstelle war alles OK.
Nachdem das korrigiert war und die Dienste auf allen pfSense neu gestartet waren, hatte ich noch immer nur eine Phase 2 im Status.
Erst nach einem manuellen Re-Connect tauchten beide auf.
Ein Ping A nach B oder umgekehrt kam trotzdem nicht zustande.
Da mir während der Fehlersuche nichts auffiel, habe ich es dann mit dem Ping nochmals probiert.
Seltsamerweise funktionierte es diesmal.
Jedenfalls dauert es z.B. bei einem Neustart der Dienste auf der pfSense von Standort B einige Zeit, bis beide Phase2 Einträge im Status stehen.
Einer von beiden ist immer sofort sichtbar, der andere kommt nach ca. 30-60Sek.
Und dann läuft es wieder.
Scheint ein wenig zu dauern, bis die Verbindung wieder voll funktionell ist !? Liegt das am Re-Keying der Phasen?
Scheint ein wenig zu dauern, bis die Verbindung wieder voll funktionell ist !?
Das liegt daran das der Tunnel nur dann aufgebaut wird wenn auch Traffic da ist der die Phase 2 Lokal und Remote IP Netze matcht. Ist kein Traffic da passiert auch mit dem Tunnel nichts. Das ist also normal.Leider schreibst du nicht ob du mit IKEv1 oder IKEv2 arbeitest. Das Verhalten ist da leicht unterschiedlich aber auch hier kommt die Phase 2 SAs erst dann hoch wenn relevanter Traffic da ist.
Das modernere IKEv 2 ist wie oben schon gesagt zu empfehlen und sollte man immer einsetzen wenn möglich.
Aber gut wenn nun alles rennt wie es soll !
Case closed.
