ricopausb
Goto Top

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

Content-Key: 539060

Url: https://administrator.de/contentid/539060

Printed on: December 8, 2022 at 16:12 o'clock

Member: aqui
aqui Jan 24, 2020 updated at 11:14:27 (UTC)
Goto Top
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:
https://administrator.de/content/detail.php?id=534696&token=622#comm ...
Denk dir das dortige OVPN als 2ten IPsec Link.
Member: RicoPausB
RicoPausB Jan 24, 2020 at 11:45:44 (UTC)
Goto Top
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.
Member: ChriBo
ChriBo Jan 24, 2020 at 15:41:50 (UTC)
Goto Top
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
Member: RicoPausB
RicoPausB Jan 24, 2020 at 17:24:29 (UTC)
Goto Top
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.
Member: aqui
aqui Jan 24, 2020 updated at 19:01:14 (UTC)
Goto Top
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 ! face-wink 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 ?
Member: RicoPausB
RicoPausB Jan 25, 2020 at 14:33:55 (UTC)
Goto Top
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.
Member: aqui
aqui Jan 25, 2020 updated at 18:30:44 (UTC)
Goto Top
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 face-sad
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.
Member: aqui
Solution aqui Jan 25, 2020, updated at Apr 17, 2020 at 14:12:48 (UTC)
Goto Top
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. face-wink
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:

p2test

Fakt ist das es sauber funktioniert !!

Die Schritte im Einzelnen:

1.) Hauptstelle VPN Tunnel einrichten:
p2testhst1

2.) Erste Nebenstelle (pfSense) VPN Tunnel einrichten:
p2testnst2

3.) Zweite Nebenstelle (Mikrotik) VPN Tunnel einrichten:
p2testmt2

Peer auf die Hauptstelle:
p2testmt1
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:
p2testmt3

3.) Check des VPN Tunnels und der zwei SAs in der Nebenstelle:
p2testnst3
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:
p2testnst1db

4.) Check der beiden VPN Tunnel und der vier SAs in der Hauptstelle:
Tunnel zur pfSense Nebenstelle:
p2testhst2
Auch hier Tunnel established und beide P2 SAs sind aktiv (Paket Counter) !

Tunnel zur Mikrotik Nebenstelle:
p2testhst3
Ebenso hier Tunnel established und beide P2 SAs sind aktiv (Paket Counter) !

Dashboard zeigt auch hier beide P2 Verbindungen aktiv:
p2testhstdb

5.) Finaler Ping Check zwischen den zwei Nebenstellen:
pfSense Nebenstelle LAN auf Mikrotik LAN:
p2testnstping

Mikrotik Nebenstelle LAN auf pfSense Nebenstelle LAN:
p2testmtping

Und um wirklich ganz sicher zu gehen auch nochmal ein Client Ping aus dem pfSense Nebenstellen Netz auf den MT:
Fazit:
Works as designed !!! face-wink

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.
Member: aqui
Solution aqui Jan 26, 2020 updated at 14:49:11 (UTC)
Goto Top
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:
nstp1-1
nstp1-2

2.) Nebenstelle Phase 2 (auf Hauptstelle) Konfig für IKEv2:
nstp2-1
nstp2-2

3.) Nebenstelle Phase 2 (auf Mikrotik) Konfig für IKEv2:
nst2tep2-1
nst2tep2-2

4.) Nebenstelle IKEv2 Session Info:
nst-stat

5.) Hauptstelle IPsec P1/P2 Konfig für IKEv2:
hstipsec
Wenn du es nicht schon hast solltest du IKEv2 immer vorziehen in der IPsec Konfig !

Auch hier: Works as designed ! face-wink
Member: RicoPausB
RicoPausB Jan 27, 2020 at 08:25:10 (UTC)
Goto Top
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?
Member: aqui
Solution aqui Jan 27, 2020 updated at 09:01:44 (UTC)
Goto Top
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.