12
Wireguard PFSense 2.5.2 zweiter "Tunnel"
Hallo
Ich stehe scheinbar auf dem Schlauch.
Ich versuche mehrere Standorte via Wireguard miteinander zu verbinden.
Mit zwei Standorten (Standort A nach Standort B), funktioniert dies nach dieser Anleitung wunderbar. :
https://www.youtube.com/watch?v=lQhciz0-rj0
Wenn ich jedoch zusätzlich Standort A mit Standort C verbinden möchte scheitere ich.
Muss für jeden weiteren Standort jedes mal ein neuer Tunnel (das ist ja bei ipsec auch so), mit eigenem Tunnelnetz, Eigener Schnittstelle und Routen erstellt werden ?
Zunächst habe ich in meinem unjugendlichem Leichtsinn versucht den neuen Standort C mittels weiterem Peer am vorhandenem Tunnel der Verbindung A nach B zu verbinden. Natürlich auch die statische Route eingetragen.
Die Verbindung kam zustande, und ich kann auch von Standort C das Netz von Standort A pingen.
Da hört es allerdings auch schon auf. Ich kann keinen Host auf der Gegenseite aufrufen, nur pingen. Lediglich die Firewall an Standort A ist mit ihrer Tunneladresse (die Schnittstellen- Gatewayadresse erreichbar.
Ok das war vermutlich sowiso Wunschdenken das es so einfach sein könnte.
Ich habe nun einen weiteren Tunnel An Standort A erstellt, mit eigenem Tunnelnetz, Schnittstelle und Routen. Und dann hat dort den Peer eingerichtet.
Die Verbindung kommt auchzu stande. Aber dakann ich nicht mal das entfernte Netz pingen.
Ich muss völlig falsch abgebogen sein. Welcher weg ist für einen weiteren Standort der Richtige ?
lg
Bernd
Ich stehe scheinbar auf dem Schlauch.
Ich versuche mehrere Standorte via Wireguard miteinander zu verbinden.
Mit zwei Standorten (Standort A nach Standort B), funktioniert dies nach dieser Anleitung wunderbar. :
https://www.youtube.com/watch?v=lQhciz0-rj0
Wenn ich jedoch zusätzlich Standort A mit Standort C verbinden möchte scheitere ich.
Muss für jeden weiteren Standort jedes mal ein neuer Tunnel (das ist ja bei ipsec auch so), mit eigenem Tunnelnetz, Eigener Schnittstelle und Routen erstellt werden ?
Zunächst habe ich in meinem unjugendlichem Leichtsinn versucht den neuen Standort C mittels weiterem Peer am vorhandenem Tunnel der Verbindung A nach B zu verbinden. Natürlich auch die statische Route eingetragen.
Die Verbindung kam zustande, und ich kann auch von Standort C das Netz von Standort A pingen.
Da hört es allerdings auch schon auf. Ich kann keinen Host auf der Gegenseite aufrufen, nur pingen. Lediglich die Firewall an Standort A ist mit ihrer Tunneladresse (die Schnittstellen- Gatewayadresse erreichbar.
Ok das war vermutlich sowiso Wunschdenken das es so einfach sein könnte.
Ich habe nun einen weiteren Tunnel An Standort A erstellt, mit eigenem Tunnelnetz, Schnittstelle und Routen. Und dann hat dort den Peer eingerichtet.
Die Verbindung kommt auchzu stande. Aber dakann ich nicht mal das entfernte Netz pingen.
Ich muss völlig falsch abgebogen sein. Welcher weg ist für einen weiteren Standort der Richtige ?
lg
Bernd
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1392291055
Url: https://administrator.de/contentid/1392291055
Ausgedruckt am: 17.11.2024 um 03:11 Uhr
12 Kommentare
Neuester Kommentar
jedes mal ein neuer Tunnel
Ja, das ist nicht nur bei IPsec so sondern auch bei OpenVPN und allen anderen VPN Protokollen auch.Guckst du auch hier:
Merkzettel: VPN Installation mit Wireguard
den neuen Standort C mittels weiterem Peer am vorhandenem Tunnel der Verbindung A nach B zu verbinden.
Das ist auch richtig ! A ist der Server (Responder) und B und C die Clients (Initiators). Es wird im Server bzw. der Server Konfig als weiterer [Peer] eingetragen.Natürlich auch die statische Route eingetragen.
Das ist völliger Quatsch und auch ziemlich kontraproduktiv weil du damit das automatische Routing von Wireguard "kaputt" machst. Das Routing erledigt Wireguard von selber ! Thema Crypto Key Routing !https://www.wireguard.com/#cryptokey-routing
Besser also nochmal das Tutorial lesen und vor allem verstehen !
Aber dakann ich nicht mal das entfernte Netz pingen.
Ein IP "Netz" kann man auch nicht pingen. Das geht nur mit Host IP Adressen wie du als Netzwerk Profi sicher auch selber weisst.Um hier zielführend antworten zu können müsste man wissen WIE deine VPN Server Client Infrastruktur aussieht. Leider machst du dazu keinerlei Angaben und zwingst zur Kristallkugel.
- Direkt auf dem Router o. Firewall ?
- In einer Kaskade mit einem NAT Router ?
- Als internen Server ?
Auch am Freitag: Etwas mehr und hilfreiche Infos, dann kann man sowas auch problemlos lösen !
Ich fürchte deine Anleitung ist für PfSense nicht geeignet.
Das Routing wird ab Version 2.5.2 nicht mehr automatisch erstellt, und in der Anleitung wird auch keine Netzwerkschnittstelle erstellt. Das ist in Version 2.5.2 zwingend erforderlich. Den *KSS überlese ich mal.
Ich fürchte diese Merkliste ist für die Konfiguration nicht passend.
Antwort 1 und zwei wiederspricht sich ? Weil entweder ein Tunnel und multiple Peers oder eben mehrere Tunnel mit jeweils einem Peer ?
Direkt auf dem Router o. Firewall ?
Naja auf einer PfSense 2.5.2 also auf einer Firewall
In einer Kaskade mit einem NAT Router ?
Kein Nat
Wireguard als Plugin 0.1.5 auf der PfSense 2.5.2
Alle Bilder kommen von Standort A
Also zunächst habe ich das Wireguard Plugin installiert.
Danach den ersten Tunnel erstellt
Danach die Netzwerkschnittstelle :
Dann die Route:
Dann die Peers:
7
Dann die Firewallrel Wan :
Und Wireguard:
Test :
Angeblich alles ok.
Der erste peer läuft auch.
Aber der Zweite nur halb.
Wenn ich versuche von der Gegenseite Standort C aus zu pingen geht das.
Allerdings kann ich keinen Host via http oder sonst wie erreichen.
Ich hoffe das war etwas genauer.
Lg
Bernd
Das Routing wird ab Version 2.5.2 nicht mehr automatisch erstellt, und in der Anleitung wird auch keine Netzwerkschnittstelle erstellt. Das ist in Version 2.5.2 zwingend erforderlich. Den *KSS überlese ich mal.
Ich fürchte diese Merkliste ist für die Konfiguration nicht passend.
Antwort 1 und zwei wiederspricht sich ? Weil entweder ein Tunnel und multiple Peers oder eben mehrere Tunnel mit jeweils einem Peer ?
Direkt auf dem Router o. Firewall ?
Naja auf einer PfSense 2.5.2 also auf einer Firewall
In einer Kaskade mit einem NAT Router ?
Kein Nat
Wireguard als Plugin 0.1.5 auf der PfSense 2.5.2
Alle Bilder kommen von Standort A
Also zunächst habe ich das Wireguard Plugin installiert.
Danach den ersten Tunnel erstellt
Danach die Netzwerkschnittstelle :
Dann die Route:
Dann die Peers:
Dann die Firewallrel Wan :
Und Wireguard:
Test :
Angeblich alles ok.
Der erste peer läuft auch.
Aber der Zweite nur halb.
Wenn ich versuche von der Gegenseite Standort C aus zu pingen geht das.
Allerdings kann ich keinen Host via http oder sonst wie erreichen.
Ich hoffe das war etwas genauer.
Lg
Bernd
Hallo,
der Ping ist von welchem Standort zu welchem Standort durchgeführt worden ?
Ich nehme an du willst LAN zu LAN per Wireguard verbinden ?
Wenn ja, hast du auch die entsprechenden Regeln auf den LAN interfaces erstellt ?
Aktiviere mal auf allen pfSensen logging auf der Wireguard Regel (= eingehender Traffic) und auf den entsprechenden LAN Regeln (= ausgehender Traffic).
Damit solltest du schnell feststellen wo der Fehler zu suchen ist.
Gruß
CH
der Ping ist von welchem Standort zu welchem Standort durchgeführt worden ?
Ich nehme an du willst LAN zu LAN per Wireguard verbinden ?
Wenn ja, hast du auch die entsprechenden Regeln auf den LAN interfaces erstellt ?
Aktiviere mal auf allen pfSensen logging auf der Wireguard Regel (= eingehender Traffic) und auf den entsprechenden LAN Regeln (= ausgehender Traffic).
Damit solltest du schnell feststellen wo der Fehler zu suchen ist.
Gruß
CH
Das Routing wird ab Version 2.5.2 nicht mehr automatisch erstellt
Deshalb verweist das Tutorial an erster Stelle der weiterführenden Links und auch innerhalb auf den Eintrag vom Kollegen @colinardo zu dieser Bug Thematik !Wirklich lesen hilft also..
Mal abgesehen davon das dein initialer Thread keinereli Informationen zu deiner verwendeten Hardware enthält !
Hätte also auch ein Raspberry Pi sein können der den Fehler nicht hat.
Sinnvoll wechselt man dann besser auf die bordeigenen VPN Clients aller Betriebssysteme und Endgeräte die diese Problematiken gar nicht erst haben und einem die Frickelei mit externen VPN Clients ersparen: 😉
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Zitat von @aqui:
Wirklich lesen hilft also..
Mal abgesehen davon das dein initialer Thread keinereli Informationen zu deiner verwendeten Hardware enthält !
Hätte also auch ein Raspberry Pi sein können der den Fehler nicht hat.
Sinnvoll wechselt man dann besser auf die bordeigenen VPN Clients aller Betriebssysteme und Endgeräte die diese Problematiken gar nicht erst haben und einem die Frickelei mit externen VPN Clients ersparen: 😉
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Das Routing wird ab Version 2.5.2 nicht mehr automatisch erstellt
Deshalb verweist das Tutorial an erster Stelle der weiterführenden Links und auch innerhalb auf den Eintrag vom Kollegen @colinardo zu dieser Bug Thematik !Wirklich lesen hilft also..
Mal abgesehen davon das dein initialer Thread keinereli Informationen zu deiner verwendeten Hardware enthält !
Hätte also auch ein Raspberry Pi sein können der den Fehler nicht hat.
Sinnvoll wechselt man dann besser auf die bordeigenen VPN Clients aller Betriebssysteme und Endgeräte die diese Problematiken gar nicht erst haben und einem die Frickelei mit externen VPN Clients ersparen: 😉
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Wir reden aneinander vorbei. Es geht nicht um einen Client, Sondern den Wireguard Server der pfsense als Ad on, Netz zu Netz. Aber das weist du als Netzwerkprofi sicher.
ipsec versuche ich hier gerad ab zu lösen. Zu viele Probleme mit RW Verbindungen. Nach jedem größerem Windows Update funktioniert irgent was nicht. (Nativer Windows Client nach deiner Anleitung eingerichtet)
Die Wireguards laufen bei RW Verbindungen bisher super. Sogar via Funk aus Malle was mit ipsec unmöglich war.
So weit ich weis ist das Routing in V2.5.2 mit Wireguard 0.1.5 kein Bug sondern feature.
Wegen des Raspberry ich habe von Anfang an im Betreff von der PfSense gesprochen.
Wirklich lesen hilft also..
Auf dem Merkzettel ist dauern die Rede von einem externen Wireguard Server. Fritzboxen, Routern... Das ist hier ja alles nicht der Fall. Lustigerweise werdenn aber auch dort statische Routen verwendet.
Chribo scheint mich ja verstanden zu haben, sooo missverständlich kann die Frage ja nicht gewesen sein. Ich habe aber auch schon bemerkt das die meisten Freds hier sich um die Fragegestalltung drehen, nicht so sehr um die Problemlösung.
Zitat von @ChriBo:
Hallo,
der Ping ist von welchem Standort zu welchem Standort durchgeführt worden ?
Ich nehme an du willst LAN zu LAN per Wireguard verbinden ?
Wenn ja, hast du auch die entsprechenden Regeln auf den LAN interfaces erstellt ?
Aktiviere mal auf allen pfSensen logging auf der Wireguard Regel (= eingehender Traffic) und auf den entsprechenden LAN Regeln (= ausgehender Traffic).
Damit solltest du schnell feststellen wo der Fehler zu suchen ist.
Gruß
CH
Hallo,
der Ping ist von welchem Standort zu welchem Standort durchgeführt worden ?
Ich nehme an du willst LAN zu LAN per Wireguard verbinden ?
Wenn ja, hast du auch die entsprechenden Regeln auf den LAN interfaces erstellt ?
Aktiviere mal auf allen pfSensen logging auf der Wireguard Regel (= eingehender Traffic) und auf den entsprechenden LAN Regeln (= ausgehender Traffic).
Damit solltest du schnell feststellen wo der Fehler zu suchen ist.
Gruß
CH
Danke für die Antwort. Damit kann ich was anfangen, bzw. weis wo ich ansetzen muss. Ich schaue heute Nachmittag in die Logs) Mir stellte sich grundsätzlich die Frage ob das bei Wireguard mit zusätzlichen Peers gemacht wird.
Lan Regeln bezüglich Wireguard gibt es tatsächlich nicht, wurde im tutorial auch nicht behandelt. Aber Standort A und B geht trotzdem ?
Beim Ping verhält es sich so. Von Server C aus. Via Tunnelnetz geht der Ping durch. Via Lan nicht. Sorry hatte den Reiter Automatisch Quelle wählen an. Ich finde in den Rules aber absolut keinen Unterschied zu den firewalls die funktionieren. Es muss ja etwas anders sein wie bei A und B
Ping wurde ausgeführt von Server C. (192.168.101.253) Die Verbindung zwischen A(192.168.4.253) und B (192.168.2.253) laufen problemlos. Die Screenshots stammen von Server A.
OK, das war dann ein Missverständnis, sorry !
Was das WG Routing anbetrifft ist das leider ein Bug, denn statische Routen sind bei Wireguard durch das Prinzip bedingte CryptoKey Routing ja Blödsinn. Sieht man auch wenn man eine klassische WG Infrastruktur aufsetzt. Das ist also ein Problem der Packages bei den Firewall. Kollege @colinardo hat das ja hier schon recht anschaulich beschrieben.
Es ist übrigens vom Setup und den Konfig Files vollkommen Wumpe ob man einen WG Server im lokalen LAN betreibt oder in der Peripherie auf dem Router oder FW. Letzteres ist natürlich aus Sicherheitssicht die bessere Alternative.
Viele können das aber wegen Provider Gängelei oder Zwangsroutern nicht umsetzen, deshalb beleuchtet das Tutorial primär die interne Variante und beschreibt diese etwas ausführlicher um auch Laien die Chance eines erfolgreichen Setups zu liefern.
Aber wie bereits gesagt, vom WG Setup an sich her gesehen ist das völlig egal.
Fazit:
Wenn man die aktuellen Fallstricke des Routings beachtet (Wissensthread @colinardo) und ein stinknormales Setup verwendet kommt das sofort zum Fliegen. Getestet hier an einer pfSense und einer OPNsense mit latest Version.
Was das WG Routing anbetrifft ist das leider ein Bug, denn statische Routen sind bei Wireguard durch das Prinzip bedingte CryptoKey Routing ja Blödsinn. Sieht man auch wenn man eine klassische WG Infrastruktur aufsetzt. Das ist also ein Problem der Packages bei den Firewall. Kollege @colinardo hat das ja hier schon recht anschaulich beschrieben.
Es ist übrigens vom Setup und den Konfig Files vollkommen Wumpe ob man einen WG Server im lokalen LAN betreibt oder in der Peripherie auf dem Router oder FW. Letzteres ist natürlich aus Sicherheitssicht die bessere Alternative.
Viele können das aber wegen Provider Gängelei oder Zwangsroutern nicht umsetzen, deshalb beleuchtet das Tutorial primär die interne Variante und beschreibt diese etwas ausführlicher um auch Laien die Chance eines erfolgreichen Setups zu liefern.
Aber wie bereits gesagt, vom WG Setup an sich her gesehen ist das völlig egal.
Fazit:
Wenn man die aktuellen Fallstricke des Routings beachtet (Wissensthread @colinardo) und ein stinknormales Setup verwendet kommt das sofort zum Fliegen. Getestet hier an einer pfSense und einer OPNsense mit latest Version.
So war das auch beim ersten Tunnel. Es gab keinen Fehlversuch.
Aber der Zweite will einfach nicht.
Colinardo schreibt "Ergo muss man also unter Routing => Gateways ein neues GW für das Wireguard-Interface erstellen und die IP des Peers des Gegenübers angeben"
Das funktioniert so nicht, da das Gateway ja die lokale "Netzwerkschnittstelle" ist. bzw. er verlangt die lokale Interfaceadresse. Erst danach kann in den static Routes das entfernte Netz angegeben werden.
dennoch, ein Tunnel geht, der Andere nicht.
Ich versuche nun einen dritten zu konfigurieren, ob es an irgentwelchen Eigenheiten von Standort C liegt.
Aber der Zweite will einfach nicht.
Colinardo schreibt "Ergo muss man also unter Routing => Gateways ein neues GW für das Wireguard-Interface erstellen und die IP des Peers des Gegenübers angeben"
Das funktioniert so nicht, da das Gateway ja die lokale "Netzwerkschnittstelle" ist. bzw. er verlangt die lokale Interfaceadresse. Erst danach kann in den static Routes das entfernte Netz angegeben werden.
dennoch, ein Tunnel geht, der Andere nicht.
Ich versuche nun einen dritten zu konfigurieren, ob es an irgentwelchen Eigenheiten von Standort C liegt.
Das funktioniert so nicht, da das Gateway ja die lokale "Netzwerkschnittstelle" ist.
Nein, sorry das ist routingtechnischer Unsinn. Das Gateway ist immer die IP Adresse des remoten Wireguard Tunnel wo diese IP Netz liegt.Da die Wireguard Tunneladresse ja statisch ist kannst du diese WG Gateway vorher anlegen und weist in der statischen Route dieser dann dieses Gateway zu.
Niemals ist ein lokales Interface ein Gateway zu einem remoten IP Netz. Vermutlich ist hier dein Denkfehler ?!
Wenn's das denn nun war bitte den Thread hier dann auch als erledigt schliessen !!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Hallo.
Gateway lässt sich wirklich nur die IP Adresse des lokalen Gateways eintragen. Eventuell reden wir da aneinander vorbei. Lediglich danach in den Routen ist das natürlich anders.
Die lösung war das neu Aufsetzen der betreffenden Gegenstelle. Scheinbar gab es Einstellungen die über das GUI nicht sichtbar waren. Ob Altlasten oder Fehlkonfiguration keine Ahnung. Die neue PF Sense lief dann ohne Probleme.
Danke
Gateway lässt sich wirklich nur die IP Adresse des lokalen Gateways eintragen. Eventuell reden wir da aneinander vorbei. Lediglich danach in den Routen ist das natürlich anders.
Die lösung war das neu Aufsetzen der betreffenden Gegenstelle. Scheinbar gab es Einstellungen die über das GUI nicht sichtbar waren. Ob Altlasten oder Fehlkonfiguration keine Ahnung. Die neue PF Sense lief dann ohne Probleme.
Danke
👍
