9
Wireguard over pfSense (IPv6 Endpoint)
Hallo zusammen,
Ich habe dank eurer Unterstützung vor Kurzem ein Problem im Zusammenhang mit Wireguard lösen können.
Mit eurem Know-How bekomme ich sicherlich auch das folgende Problem in den Griff, das mir ehrlich gesagt etwas Kopfzerbrechen bereitet:
Undzwar habe ich einige NetGate Appliances an verschiedenen Standorten im Einsatz.
(Netgate 4100 und einige NetGate 1100)
All diese Standorte werden über denselben ISP mit FTTH versorgt. Wie heute häufig üblich über CGNAT.
Ich kann demnach von außen nur die IPv6 Adressen direkt erreichen, welche ich vom ISP via PD erhalte.
Alle Interfaces auf den Netgates erhalten entsprechend eine IPv6 über Track WAN Interface.
Da Wireguard bei pfSense auf jeder IPv6 und sämtlichen IPv4 Adressen aller Interfaces nach Verbindungen lauscht, werden Zugriffe über Firewall Rules geregelt.
Die Idee ist jetzt von außen via Wireguard auf die Netgate zu connecten und auf das WebInterface zuzugreifen,
eigentlich keine große Sache, oder? 😊
Nun, die Wireguard Verbindung auf der Netgate habe ich konfiguriert.
Ebenso eine Firewall Rule auf WAN erstellt, die ermöglicht das von außen auf eine bestimmte IPv6 der Netgate auf dem vorher ausgewählten WG UDP Port (exemplarisch: 55555/UDP) verbunden werden kann.
Abgesehen davon natürlich nur alles auf dem Wireguard Tunnel Interface erlaubt. (nur für Testzwecke)
So sieht praktisch die conf auf einer der pfSense Boxen aus:
So hingegen schauts auf dem Peer aus, der letzten Endes zur NetGate verbinden soll:
Die Verbindung zur Netgate funktioniert soweit. Ich kann alle Interfaces auf der Netgate pingen und ebenso Geräte in den Subnetzen 192.168.155.0/24 und 192.168.166.0/24 vom wg peer aus anpingen.
Was allerdings nicht funktioniert, ist das Web Interface der Netgate (oder irgendeines anderen Geräts) aufzurufen, obwohl ich wiegesagt alle IP Adressen die dafür in Frage kommen anpingen kann. Jetzt werdet ihr vermutlich denken, das dies mit den Firewall Rules auf der NetGate zusammenhängt, die den Zugriff auf diverse WebInterfaces blockt, allerdings habe ich das mehrfach geprüft und sichergestellt, das Verbindungen durchgehen.
Interessanterweise kann ich aber über den wg peer SSH Verbindungen zu Clients in einem der o.g Subnetze aufbauen, nur eben Verbindungen über den Webbrowser scheinen nicht zu funktionieren.
Habt ihr eventuell einen Lösungsansatz oder eine Idee, diemir weiterhelfen könnte?
Vorab vielen Dank.
Ich habe dank eurer Unterstützung vor Kurzem ein Problem im Zusammenhang mit Wireguard lösen können.
Mit eurem Know-How bekomme ich sicherlich auch das folgende Problem in den Griff, das mir ehrlich gesagt etwas Kopfzerbrechen bereitet:
Undzwar habe ich einige NetGate Appliances an verschiedenen Standorten im Einsatz.
(Netgate 4100 und einige NetGate 1100)
All diese Standorte werden über denselben ISP mit FTTH versorgt. Wie heute häufig üblich über CGNAT.
Ich kann demnach von außen nur die IPv6 Adressen direkt erreichen, welche ich vom ISP via PD erhalte.
Alle Interfaces auf den Netgates erhalten entsprechend eine IPv6 über Track WAN Interface.
Da Wireguard bei pfSense auf jeder IPv6 und sämtlichen IPv4 Adressen aller Interfaces nach Verbindungen lauscht, werden Zugriffe über Firewall Rules geregelt.
Die Idee ist jetzt von außen via Wireguard auf die Netgate zu connecten und auf das WebInterface zuzugreifen,
eigentlich keine große Sache, oder? 😊
Nun, die Wireguard Verbindung auf der Netgate habe ich konfiguriert.
Ebenso eine Firewall Rule auf WAN erstellt, die ermöglicht das von außen auf eine bestimmte IPv6 der Netgate auf dem vorher ausgewählten WG UDP Port (exemplarisch: 55555/UDP) verbunden werden kann.
Abgesehen davon natürlich nur alles auf dem Wireguard Tunnel Interface erlaubt. (nur für Testzwecke)
So sieht praktisch die conf auf einer der pfSense Boxen aus:
[Interface]
PrivateKey = $VeryPrivate
ListenPort = 55555
Address = 10.5.5.1/24
[Peer]
PublicKey = $PeerPublicKey
AllowedIPs = 10.5.5.0/24So hingegen schauts auf dem Peer aus, der letzten Endes zur NetGate verbinden soll:
[Interface]
PrivateKey = $VeryPrivate
ListenPort = 61585
Address = 10.5.5.10/32
[Peer]
PublicKey = $NetGatePublicKey
AllowedIPs = 10.5.5.0/24, 192.168.155.0/24, 192.168.166.0/24
Endpoint [IPv6 NetGate]:55555Was allerdings nicht funktioniert, ist das Web Interface der Netgate (oder irgendeines anderen Geräts) aufzurufen, obwohl ich wiegesagt alle IP Adressen die dafür in Frage kommen anpingen kann. Jetzt werdet ihr vermutlich denken, das dies mit den Firewall Rules auf der NetGate zusammenhängt, die den Zugriff auf diverse WebInterfaces blockt, allerdings habe ich das mehrfach geprüft und sichergestellt, das Verbindungen durchgehen.
Interessanterweise kann ich aber über den wg peer SSH Verbindungen zu Clients in einem der o.g Subnetze aufbauen, nur eben Verbindungen über den Webbrowser scheinen nicht zu funktionieren.
Habt ihr eventuell einen Lösungsansatz oder eine Idee, diemir weiterhelfen könnte?
Vorab vielen Dank.
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: 669174
Url: https://administrator.de/forum/wireguard-over-pfsense-ipv6-endpoint-669174.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
9 Kommentare
Neuester Kommentar
Da Wireguard bei pfSense auf jeder IPv6 und sämtlichen IPv4 Adressen aller Interfaces nach Verbindungen lauscht, werden Zugriffe über Firewall Rules geregelt.
Das ist natürlich Unsinn, denn das kann man bekanntlich über die "AllowedIPs" Defintion granular einstellen. Letztlich ist es aber sinnvoller mit einer Firewall Regel.eine Firewall Rule auf WAN erstellt, die ermöglicht das von außen auf eine bestimmte IPv6 der Netgate auf dem vorher ausgewählten WG UDP Port (exemplarisch: 55555/UDP) verbunden werden kann.
Das ist irgendwie laienhaft ausgedrückt! Es darf natürlich nicht irgendwelche x-beliebige IP Adresse sein sondern die Regel musst immer auf die WAN IPv6 Adresse den Zugriff erlauben! Dazu muss im Regelset der Alias Name des WAN Interfaces verwendet werden denn das stellt sicher das das auch klappt wenn die v6 WAN IP wechselt was durch die dynamische Prefix Delegation fast aller Provider immer der Fall ist. Ein Screenshot deiner Rulesets zur Klärung hätte hier allen beim zielführenden Troubleshooting geholfen. 
- Wie sieht dein Ruleset auf dem Tunnel Interface aus? (Siehe dazu HIER)
- Hast du beachtet kein Regelwerk auf dem Tunnel Group Interface einzurichten?!
- Wie hast du die Wireguard Routing Policy der OPNsense gesetzt? Automatisch über das WG Setup oder manuell statisch?
- Beachte auch das du natürlich nur von VPN Clients die eine IPv6 Internet Connectivity haben extern auf deine OPNsense zugreifen kannst. Bei Clients in reinen IPv4 Netzen scheitert der Zugriff erwartungsgemäß da prinzipbedingt.
Das ist natürlich Unsinn, denn das kann man bekanntlich über die "AllowedIPs" Defintion granular einstellen. Letztlich ist es aber sinnvoller mit einer Firewall Regel.
Der WG Service in pfSense lauscht auf jeder IPv6/IPv4 Adresse aller vorhandenen Interfaces auf Verbindungsanfragen. Das ist nicht etwa von mir so eingerichtet worden, sondern standardmäßig der Fall.
Das ist irgendwie laienhaft ausgedrückt! Es darf natürlich nicht irgendwelche x-beliebige IP Adresse sein sondern die Regel musst immer auf die WAN IPv6 Adresse den Zugriff erlauben!
Mein ISP gibt lediglich ein Prefix raus und WAN selbst erhält keine "globally unique" IPv6. WAN hat lediglich eine link-lokale IPv6. Die anderen Interfaces hingegen haben alle eine global unicast IPv6 über Track Interface (WAN), dementsprechend verwende ich eine dieser Adressen als Endpoint address für WG clients.
Wie sieht dein Ruleset auf dem Tunnel Interface aus? (Siehe dazu HIER)
Wie schon erwähnt, ist auf dem Tunnel Interface vorläufig alles erlaubt, siehe auch:Hast du beachtet kein Regelwerk auf dem Tunnel Group Interface einzurichten?!
Wenn man Interface Addresses direkt im Tunnel unter pfSense angibt, ist immer das Interface Wireguard maßgebend für den Traffic, der über diesen erstellten Tunnel läuft. Ich habe jetzt beispielhaft diesen Weg gewählt.Wenn ich allerdings unter Interface -> Assignments -> das tun_wg0 Interface hinzufüge und es TEST_VPN benenne müsste ich die FW Regeln stattdessen im Interface TEST_VPN setzen. Trotzdem haben die Regeln im "by default" vorhandenen "Wireguard" Interface unter pfSense immer Vorrang.
> Wie hast du die Wireguard Routing Policy der OPNsense gesetzt? Automatisch über das WG Setup oder manuell statisch?
Automatisch. Ich selber habe manuell keine Routen festgelegt.
Beachte auch das du natürlich nur von VPN Clients die eine IPv6 Internet Connectivity haben extern auf deine OPNsense zugreifen kannst. Bei Clients in reinen IPv4 Netzen scheitert der Zugriff erwartungsgemäß da prinzipbedingt.
Klar, das ist natürlich logisch aber der Wireguard Peer um den es sich dreht verfügt über IPv6 Connectivity.
WAN hat lediglich eine link-lokale IPv6.
Wäre sehr sehr ungewöhnlich. Normalerweise MUSS das WAN Interface DHCPv6 machen und bekommt damit dann eine eigene öffentliche WAN IP vom Provider zugeteilt und zusätzlich ein PD für die internen LAN Segmente.Ohne eine öffentliche v6 IP auf deinem WAN Interface wäre deine FW von extern technisch gar nicht per v6 erreichbar, da Link Local Adressen wie der Name schon sagt bekanntlich nicht geroutet werden. Wie sollte das ohne gültige, öffentliche v6 IP Adresse am WAN auch gehen?? Da kann also irgendwas nicht stimmen mit deiner IPv6 WAN Adressierung.
Üblicherweise machen das nur kleine oder Billo Provider die keine IPv4 Kontingente mehr haben bzw. ihre knappen Adressen für deutlich besser bezahlende Business Kunden vorhalten. Große Provider wie die Telekom z.B. fahren allem mit sauberem Dual Stack.
Wäre sehr ungewöhnlich. Normalerweise MUSS das WAN Interface DHCPv6 machen und bekommt damit dann eine eigene öffentliche WAN IP zugeteilt und zusätzlich ein PD für die internen LAN Segmente. Ohne eine öffentliche v6 IP auf deinem WAN Interface wäre deine FW von extern natürlich nicht per v6 erreichbar da Link Local Adressen nicht geroutet werden. Wie sollte das ohne gültige IP Adresse auch gehen?? Da kann also irgendwas nicht stimmen mit deiner IPv6 WAN Adressierung.
WAN selbst muss ja auch nicht direkt per IPv6 erreichbar sein. Alle anderen LAN und OPT Interfaces haben dank "Track Interface" eine globally unique IPv6 aus dem delegierten Prefix des ISPs. Da der WG Service unter pfsense sich
"by default" an alle Adressen bindet, reicht es aus, wenn ich die Verbindung von außen an eine dieser IPv6 Adressen auf dem WG Port erlaube. Dies funktioniert ja wiegesagt auch bereits ohne Probleme.
WAN selbst muss ja auch nicht direkt per IPv6 erreichbar sein.
Wie kommst du darauf? An einem DS-Lite Anschluss mit CGNAT ist das deine einzige Chance. Der WAN Port benötigt zwingend eine öffentliche v6 IP, denn das ist ja immer deine Ziel IP fürs VPN.Du willst ja wohl kaum ein Loch in deine Firewall bohren um ungeschützten Internet Traffic ins lokale LAN zu lassen um quasi von hinten durch die Brust ins Auge irgendein v6 Interface für VPN erreichen zu können. Das führt ja eine Firewall dann völlig ad absurdum.
Der WAN Port ist definitiv v6 technisch falsch konfiguriert und benötigt eine öffentliche v6 IP!
Vielleicht helfen ein paar IPv6 Grundlagen zum Verständnis:
https://danrl.com/ipv6/
Es führt ja nicht direkt die gesamte Firewall ad absurdum wenn ich auf eine bestimmte IPv6 und ausschließlich dem UDP Port, auf dem WG lauscht, Verbindungen von außen ermögliche. Selbst wenn ein Angreifer die IPv6 kennen würde, müsste er auch den Public Key des WG Endpoints kennen um überhaupt erstmal eine Verbindung via WG zu bekommen.
An dem WAN Port ist nichts falsch konfiguriert.
Es ist bei einigen ISPs durchaus möglich, das diese nur ein Prefix an eine ULA delegieren
Das ist damals aber bereits auch mit dem technischen Support meines ISPs diskutiert worden und ich konnte auch klar anhand der Logs meiner pfsense erkennen, das hier keine GUA an WAN vergeben wird.
An dem WAN Port ist nichts falsch konfiguriert.
Es ist bei einigen ISPs durchaus möglich, das diese nur ein Prefix an eine ULA delegieren
Das ist damals aber bereits auch mit dem technischen Support meines ISPs diskutiert worden und ich konnte auch klar anhand der Logs meiner pfsense erkennen, das hier keine GUA an WAN vergeben wird.
Ok, für diejenigen, die vielleicht irgendwann mal ein ganz ähnliches Problem haben, ich konnte mittlerweile eine Lösung finden. Ich musste die MTU von dem wg tun interface deutlich reduzieren. Ich hatte das anfänglich bereits versucht aber dieses mal bin ich auf 1380 Bytes runter, anstatt wie vorher 1420 Bytes.
Danach funktionierte dann auch der Zugriff auf das Web Interface der pfSense.
Danke trotzdem für die Unterstützung.
Danach funktionierte dann auch der Zugriff auf das Web Interface der pfSense.
Danke trotzdem für die Unterstützung.
1
Mit einem IKEv2 oder L2TP VPN wäre das nicht passiert. Hätte einem auch die unnötige Frickelei mit der VPN Clientsoftware erspart. 
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Und Fakt bleibt das dein WAN Interface aus IPv6 Sicht falsch bzw. fehlerhaft eingerichtet ist. Mit einer richtigen und korrekten IPv6 Adressierung am WAN Port sähe das so aus:
Aber egal, wenns mit deinem gruseligen v6 Frickelsetup jetzt rennt ist doch alles bella. Never touch a running system, egal ob sicher oder nicht.
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Und Fakt bleibt das dein WAN Interface aus IPv6 Sicht falsch bzw. fehlerhaft eingerichtet ist. Mit einer richtigen und korrekten IPv6 Adressierung am WAN Port sähe das so aus:
1
Das Einzige was hier offen gesprochen gruselig ist, ist die Art und Weise wie du dich verhältst.
Deine Anmerkungen zu dem Thema hatten bisher nichts mit meinem Problem zu tun, sondern wirkten auf mich stattdessen recht überheblich und belehrend.
Das eigentliche Problem ist aber, das wenn man schon so einen belehrenden Ton anschlägt, besser sicherstellt, das man mit seinen Behauptungen auch richtig liegt und das ist leider nicht der Fall.
Ich weiß, du hörst das nicht gerne aber ich sage es nochmal mit sehr viel Nächstenliebe und Feingefühl.
An meinem WAN Interface ist nichts falsch konfiguriert.
Nicht jeder ISP assigned an WAN eine GUA und es ist völlig IPv6 standardkonform dies nicht zu tun.
Liefern wir doch mal "receipts", die du wahrscheinlich nicht als Fakt akzeptieren wirst aber der Versuch
kann ja trotzdem nicht schaden: ;)
Hier zusätzlich noch ein Beitrag aus dem Netgate Forum, in dem dieses Thema auch angeschnitten wurde.
https://forum.netgate.com/topic/159324/no-ipv6-on-wan-interface-but-ipv6 ...
Noch nicht ausreichend überzeugt?
Hier noch ein Quote von stephenw10, Admin im offiziellen NetGate Forum, den ich direkt darauf angesprochen habe:
Für die Zukunft:
"Admitting a mistake is the first step toward wisdom."
Deine Anmerkungen zu dem Thema hatten bisher nichts mit meinem Problem zu tun, sondern wirkten auf mich stattdessen recht überheblich und belehrend.
Das eigentliche Problem ist aber, das wenn man schon so einen belehrenden Ton anschlägt, besser sicherstellt, das man mit seinen Behauptungen auch richtig liegt und das ist leider nicht der Fall.
Ich weiß, du hörst das nicht gerne aber ich sage es nochmal mit sehr viel Nächstenliebe und Feingefühl.
An meinem WAN Interface ist nichts falsch konfiguriert.
Nicht jeder ISP assigned an WAN eine GUA und es ist völlig IPv6 standardkonform dies nicht zu tun.
Liefern wir doch mal "receipts", die du wahrscheinlich nicht als Fakt akzeptieren wirst aber der Versuch
kann ja trotzdem nicht schaden: ;)
Quelle: ChatGPT KI
Prefix Delegation without a Direct GUA on the WAN Interface:
Some ISPs do not assign a direct GUA to the WAN interface itself. Instead, they delegate an IPv6 prefix (e.g., /56 or /64) to the customer’s router, which then uses this prefix to assign GUAs to devices on the internal network.
In this setup, the WAN interface has only a link-local address (fe80::/10), which is enough for communicating with the ISP’s router at Layer 2 and for routing purposes, while the ISP delegates a prefix for the local network through DHCPv6-PD.
This approach is common in IPv6 configurations and is not necessarily incorrect. The link-local address on the WAN interface is sufficient for the ISP to route traffic correctly to and from the customer's network.
Why Both Approaches are Valid
Some ISPs choose to assign a GUA directly to the WAN interface and also delegate a prefix for internal use,
while others only delegate a prefix without assigning a GUA on the WAN.
Both configurations are compliant with IPv6 standards. The latter setup, where only the prefix is delegated and
the WAN relies on a link-local address, is often seen in residential networks.
Some ISPs do not assign a direct GUA to the WAN interface itself. Instead, they delegate an IPv6 prefix (e.g., /56 or /64) to the customer’s router, which then uses this prefix to assign GUAs to devices on the internal network.
In this setup, the WAN interface has only a link-local address (fe80::/10), which is enough for communicating with the ISP’s router at Layer 2 and for routing purposes, while the ISP delegates a prefix for the local network through DHCPv6-PD.
This approach is common in IPv6 configurations and is not necessarily incorrect. The link-local address on the WAN interface is sufficient for the ISP to route traffic correctly to and from the customer's network.
Why Both Approaches are Valid
Some ISPs choose to assign a GUA directly to the WAN interface and also delegate a prefix for internal use,
while others only delegate a prefix without assigning a GUA on the WAN.
Both configurations are compliant with IPv6 standards. The latter setup, where only the prefix is delegated and
the WAN relies on a link-local address, is often seen in residential networks.
Hier zusätzlich noch ein Beitrag aus dem Netgate Forum, in dem dieses Thema auch angeschnitten wurde.
https://forum.netgate.com/topic/159324/no-ipv6-on-wan-interface-but-ipv6 ...
Noch nicht ausreichend überzeugt?
Hier noch ein Quote von stephenw10, Admin im offiziellen NetGate Forum, den ich direkt darauf angesprochen habe:
Nope you are not wrong. My ISP only provides a prefix so I have no routable IPv6 address on the WAN directly.
That's BT, the largest ISP here in the UK.
That's BT, the largest ISP here in the UK.
Für die Zukunft:
"Admitting a mistake is the first step toward wisdom."
