Messages

Nun bin ich schlauer, aber nicht weiter.

Nachdem meine OPNsense nicht mitspielen wollte habe ich pfsense probiert.
Dort verlässt das TCP-ACK das WAN-Interface tatsächlich mit der erwarteten übersetzen GUA-Absendeadresse. Allerdings kommt auch hier keine Verbindung zu Stande.

In diesem Fall verhindert eine abweichende TCP-Checksum die Verbindung. Das passiert, da die Absendeadresse in die Checksum-Berechnung einbezogen ist. Durch NPT wird diese ja geändert. RFC6296 welcher NPT beschreibt hat dafür einen Mechanismus indem der IPv6-Header so gestaltet wird, dass die Checksum ihre Gültigkeit (trotz anderem Absender) erhält. Aber das scheint nur für eingehende Verbindungen von OPN/pfSense implementiert zu sein. Eine Einschränkung das NPT generell nur für intern initiierte Verbindungen funktioniert (wie bei IPv4 mit NAT ohne Portweiterleitung) konnte ich aus dem RFC6296 nicht herauslesen.

Aber Ok, NPT ist und bleibt eh eine Krücke. Daher versuche ich es mit mehreren Adressen (GUA+ULA) auf den NICs erneut. Aber auch da hab ich nur Probleme mit. Als wenn der Kram nicht schon seit 20 Jahren erprobt wäre.....  :-\

Hallo,

zuletzt habe ich festgestellt das es 2019 ist. Also höchste Zeit mein professionelles Familiennetzwerk IPv6-Fähig zu machen. Ich hätte es lassen sollen.... IPv6 hat leider noch immer einen desolaten Zustand. Die Schuld sehe ich nicht beim Protokoll selbst, sondern bei den Vergewaltigungen (dynamische Präfixe) welche die ISPs veranstalten. Aber ich komme vom Thema ab...

Das Netzwerk fußt nun auf ULAs welche OPNsense mittels NPT auf GUAs übersetzt und routet. Das funktioniert ganz gut. (Habe einen Cronjob der die NPT-Regeln automatisch aktualisiert, da OPNsense keine dynamischen Präfixe in Regeln beherrscht) Andere Lösungen mit GUAs oder mehrere IPv6-Adressen (GUA und ULA zugleich) auf den Interfaces habe ich bereits erprobt und aufgrund diverser "Nebenwirkungen" verworfen.

Jetzt das Problem: Ich möchte einen Webserver in dem Netzwerk aus dem globalen IPv6-Internet erreichbar machen. Kein Problem: Entsprechende PASS-Regel auf dem WAN-Interface definiert und.... nichts. Kein Verbindungsaufbau von außen möglich.

Beim Debuggen habe ich dann folgendes beobachtet:

• TCP-SYN kommt auf WAN-Interface an
• Empfänger wird per NPT auf mein ULA-Adressbereich abgebildet
• Wird durch die FW-Regeln durchgewunken
• Verlässt OPNsense über das DMZ-Interface zum Server
• TCP-ACK vom Server kommt auf dem DMZ-Interface des OPNsense an
• Wird entsprechend der FW-Regeln durchgewunken
• Verlässt OPNsense über das WAN-Interface mit ULA-Absendeadresse als Absender!

Schritt 7 ist das Problem. ULAs werden im Internet nicht geroutet und mein Paket verschwendet beim nächstbesten richtig konfigurierten Router im Nirvana. Eigentlich müsste hier die Übersetzung auf die GUA noch stattfinden. Für ausgehende Verbindungen funktioniert NPT auch wie vorgesehen. Nur für eingehende Verbindungen scheint sich OPNsense einen Verbindungszustand zu merken, der dann bei der Antwort NPT verhindert.

Hat von euch jemand eine Idee wie man OPNsense zum richtigen verhalten bewegen kann? Denn ich bin gerade mit meinem Latein am Ende....

Entdeckt habe ich das Problem mit 19.1.10. Aber auch ein Upgrade auf das aktuelle 19.7.1 ändert nichts an dem verhalten.