OPNsense Wireguard Ipv6

[Anonymous User]

Hi,

bei meiner Verbindung kommt kein Handshake zustande.

Was habe ich vor?
Da ich bei der deutschen Glasfaser bin und hinter CGNAT stecke, versuche ich eine Wireguard Verbindung über einen Ipv6 Tunnel aufzubauen und darin Ipv4 zu routen. Ja ich weiß, kein statischer Präfix. Das löse ich später mit Ipv6 Dyndns. Erstmal geht es nur darum, eine Verbindung erfolgreich aufzubauen.

Ich möchte aus der Ferne von einem Client auf mein Home Lan zugreifen. Das mit Ipv4 konfiguriert wurde.

Das ist mir auch von meinem Pixel 6 (Graphene OS) gelungen, allerdings nur mit deaktivierter Firewall. Also pfctl -d.
Handshake kam zustande und ich konnte mit mobilen Daten auf die opnsense drauf.

Meine Konfiguration grob OPNsense
[System]

• Plugin Wireguard OS installiert
• wg Schnittstelle zugewiesen ohne konfig, nur aktiviert (sollte sich das Tunnelnetzwerk automatisch beziehen, glaube ich)

[WG Lokal]

• Port: 51820
• Tunneladresse: 172.16.10.1/30
• Peers: Pixel6
• MTU: 1420

[WG Peer]

• Pub Key: Pub von Pixel WG Interface
• Zugelassene Ips: 172.16.10.2/32
• Keepalive: 25

Firewall
[WAN]

• allow in
• quelle: any, port: 51822
• dest.: WAN ipv6, port: 51820

[LAN]

• vorerst allow any any

[WG_Local]

• quelle: 172.16.10.0/30 udp
• ziel: any (später noch restriktiver)

Ich bin nicht sicher, ob 172.16.10.0/30 oder 172.16.10.1/30 richtig ist, daher habe ich die Regel doppelt.


Meine Konfiguration Pixel Client
[Interface]

• Adressen: 172.16.10.2/32
• Eingangsport: 51822

[Teilnehmer]

• Pub Key von WG Server OPNsense
• Erlaubte IPs: 0.0.0.0/0
• Endpoint: [2a00:xxxx:xxxx:xx::1234]:51820 (Ipv6 der WAN Schnittstelle)
• Keepalive: 25

und funktioniert nicht, Logs vom Pixel zeigen: ... Sending handshake Initiation, Handshake did not complete...

Komischerweise funktioniert diese Konfiguration sofort, wenn ich die FW vorübergehend komplett deaktiviere.

Was übersehe ich?

 

[TheCadillacMan]

Wenn der Handshake fehlschlägt das sich aber mit dem Deaktivieren der Firewall lösen lässt sollte sehr wahrscheinlich die WAN-Regel das Problem sein. Hier würde ich den Quellport mal rausnehmen:

[WAN]

• allow in
• quelle: any, port: 51822
• dest.: WAN ipv6, port: 51820

Außerdem:

[WG_Local]

• quelle: 172.16.10.0/30 udp

Hier ist die Beschränkung auf UDP wahrscheinlich nicht sinnvoll/gewollt. Das ist schließlich nur der Traffic innerhalb des Tunnels in dem man sehr wahrscheinlich auch u. a. TCP und ICMP nutzen will.

Ich bin nicht sicher, ob 172.16.10.0/30 oder 172.16.10.1/30 richtig ist, daher habe ich die Regel doppelt.

Macht technisch keinen Unterschied. 172.16.10.0/30 ist in diesem Fall aber die übliche Notation.

 

[Der_Dicke82]

Moin,
sollte bei der Firewalleinstellung die Destination nicht dein Wireguardserver im LAN sein? Wenn ich es nicht total falsch verstehe schickst du im Moment jede Anfrage an Port 51822 wieder zurück ins Netz nur halt über Port 51820

Gruß, Stefan

 

[Zero_Official]

ich habe keinen Eingangs Port bei Client konfiguriert und bei NAT Ausgehend Hybrid.

dann hat es es gefunkt.

 

[Anonymous User]

Wenn der Handshake fehlschlägt das sich aber mit dem Deaktivieren der Firewall lösen lässt sollte sehr wahrscheinlich die WAN-Regel das Problem sein. Hier würde ich den Quellport mal rausnehmen:

Habe ich, keine Veränderung.

Hier ist die Beschränkung auf UDP wahrscheinlich nicht sinnvoll/gewollt. Das ist schließlich nur der Traffic innerhalb des Tunnels in dem man sehr wahrscheinlich auch u. a. TCP und ICMP nutzen will.

Hast Recht, habs auf any umgestellt, auch keine Veränderung.

Moin,
sollte bei der Firewalleinstellung die Destination nicht dein Wireguardserver im LAN sein? Wenn ich es nicht total falsch verstehe schickst du im Moment jede Anfrage an Port 51822 wieder zurück ins Netz nur halt über Port 51820

Ich denke das sollte passen. Weil die Endpunktadresse auf die Öfftl. IP der Wan Schnittstelle zeigt, lauscht Wireguard auf dieser Schnittstelle und diesem Port. So sieht es in den meisten Road Warrior Anleitungen aus.

ich habe keinen Eingangs Port bei Client konfiguriert und bei NAT Ausgehend Hybrid.
Anhang anzeigen 1375199dann hat es es gefunkt.

Bei mir bringt das leider auch nichts. Wenn ich dieses mal die Firewall deaktiviere, gehts auch nicht mehr.

Ergänzung (13. Juli 2023)

Hmm ich kapiers nicht. Ich probiere mal die Konfig mit nem Linux Client...

 

[TheCadillacMan]

Habe ich, keine Veränderung.

Schau doch mal unter Firewall -> Log Files -> Live View ob Verbindungen vom Client geblockt werden.
Du kannst zusätzlich bei der WAN-Regel für WG auch die Log-Option aktivieren, sodass alle Verbindungen, die die Regel betreffen geloggt werden.

Bei mir bringt das leider auch nichts. Wenn ich dieses mal die Firewall deaktiviere, gehts auch nicht mehr.

Komisch, denn normalerweise sollte der Hybrid-NAT-Mode identisch mit dem Automatic-Mode sein solange man keine eigenen Outbound-NAT-Regeln erstellt hat.
Ich habe bei meiner Outbound-NAT-Regel immer noch "Static Port" aktiviert, weil das bei bestimmten Fällen (z. B. VoIP) besser ist aber ich glaube nicht, dass das für WG relevant ist.

Grundsätzlich konfiguriere ich in der Client-Config keinen lokalen Port. Dann wird wie bei den meisten anderen ausgehenden Verbindungen ein zufälliger Port gewählt. Ich sehe im Normalfall auch keinen Grund warum man dem Client einen festen Port konfigurieren sollte.

 

[Anonymous User]

In den Logs sehe ich auf WAN eingehende Ipv6 Verbindungen vom Pixel an die ipv6 des WG Servers und ausgehend vom Ipv6 Gateway zurück ans Pixel.

Also geblockt wird Firwewall technisch nichts. Selbst wenn ich WAN seitig allow Any mache, kommt kein Handshake zustande.

Ich habe irgendwie das Gefühl, dass es mit Ipv6 zutun hat.

Ich habe noch eine OPNsense auf nem VPS mit ner öffentlichen Ipv4. Ich teste mal die selbe Konfig mit Ipv4 auf dem VPS.

 

[Holzkopf]

Läuft der WG-Server auf dem opensense oder auf einem server im netzwerk ?
Falls auf einem Server muss die ipv6-adresse des Server in der Firewall für den Port aufgemacht werden.

 

[Anonymous User]

Nabend @Holzkopf, läuft direkt auf der Sense. Die dient als Firewall und Router, Reverse Proxy für Server etc. und hängt am Glasfaser Modem.

Ich teste nachher mal den VPS, damit ich die Fehlerursache eingrenzen kann.. Hoffentlich...


-Edit-
Zwischenstand:

Ich habe dieselbe Konfiguration am VPS angewendet, mit Ausnahme des Tunnels, da nämlich mit Ipv4, und es funktioniert.

Später teste ich das ganze mit Ipv6. Bin gespannt auf das Ergebnis.

 

[Anonymous User]

Sobald ich am VPS WAN seitig Ipv6 an 51820 zulasse, klappt die Verbindung!! Also muss es an meiner Opnsense liegen oder an der Ipv6 von DG.... Ich teste mal generell ob ich über die Ipv6 die OPnsense Gui erreichen kann.

 

[Anonymous User]

Leute, Problem gelöst. Es lag tatsächlich an meiner Ipv6 Konfig an der OPNsense im Home Lan.

1. das Ipv6 Gateway war falsch eingetragen, wie auch immer das passiert ist.
2. ich hatte ausversehen eine Nat6 Regel drinnen, die dafür gesorgt hat, dass externe Anfragen an den internen Ipv6 Präfix weitergeleitet wurden und so das Ziel nicht erreichen konnte...

den Eingangsport habe ich beim Client weggelassen. Das hat zur Lösung beigetragen.

Alter, es kann so leicht sein...

jetzt habe ich dadurch auch ein besseres Verständins über Ipv6 erhalten

Danke euch für die Antworten bisher