Messages

Na, mit IPv4 ist das kein Ding, ddclient schreibt die IP automatisch um, das funktioniert sehr zuverlässig. ddclient setzt auch die AAAA Records passend, aber eben eine volle Adresse (halt die vom WAN-Interface, keine Ahnung ob man das beeinflussen kann)

Ja, definitiv. :) ich schalte am Smartphone WLAN aus...

wozu brauchst du eingehendes Portforwarding für IPv6? Da lässt man das NAT eigentlich weg und erlaubt einfach die Ports direkt auf die IPv6-Zieladresse.

Stimmt auffallend. Aber wie konfiguriere ich das denn? Weil... die v6-IP ist ja erst mal gar nicht öffentlich bekannt. Das Prefix wird ja auch dynamisch vergeben, und der hintere Teil der IP des Endgeräts wird doch auch regelmäßig (über die Private Extensions? heißt das so?) geändert.
Ich scheine da noch etwas Nachholbedarf zu haben...

Wireguard ist nun fest im core integriert, nicht mehr als plugin (hat bei mir nach dem Upgrade auch direkt anstandslos funktioniert)

[any]

Kann es mit den verschiedenen IPv6 Adressen zu tun haben?
WAN hat ja automatisch zwei unterschiedliche IPv6, die eine mit fe80:..., die andere mit 2003:... Im AAAA Record steht die 2003:... drin

Allerdings, selbst wenn ich als Destination any eintrage, wird die Rule nicht berücksichtigt.

Nein, das hat leider keine Auswirkung. Auch mit pass statt automatischer Rule wird (für IPv6) die default deny rule angewandt.

Gerne.
By the way: Gibt es einen effizienteren Weg, als mühsam alles abzuschreiben oder einen Screenshot zu machen?

Interface: WAN (pppoe Interface, Telekom, IPv4+v6)
TCP/IP Version : IPv6 (hab die Rules zuletzt aufgetrennt, vorher mit v4+v6)
Protocol: TCP
Destination: WAN address
Destination Port Range: from 1122 to 1122
Redirect target IP: Alias auf ssh
Redirect target port: SSH
Pool Options: Default
NAT Reflection: Use system default
Filter rule association: (automatisch generiert)

Update: da ich noch eine zweite Kiste habe, die noch nicht upgedatet ist, habe ich mal kurz auf die alte Version zurückgeschwenkt.
Nun muss ich meine ursprüngliche Behauptung revidieren, dass das Problem mit der Version 24.1 zusammenhängt. Das Problem muss schon vorher aufgetreten sein, was es nun etwas schwieriger macht, es einzugrenzen...

Was mir allerdings bei intensivem Nachdenken dazu einfällt: evtl. ist das eigentliche Problem hier IPv6, denn gewöhnlich verwende ich den Remote Zugriff von meinem Smartphone aus von der Arbeit, dort bin ich natürlich in einem (IPv4 only) WLAN eingeloggt, so dass alle Anfragen immer über IPv4 rein kommen. Das kann ich aber momentan nicht verifizieren, da ich Urlaub habe. :) Wenn ich mein Smartphone aus dem WLAN raus nehme geht es natürlich nur über IPv6, andere Clients aus dem LAN heraus haben eine lange Wartezeit, bauen anschließend aber eine Verbindung auf (evtl. über IPv4?)

Das Problem besteht dauerhaft. OPNsense verhält sich einfach so, als seien die Rules überhaupt nicht vorhanden, egal was ich auch anstelle.

[Default deny / state violation rule]

Ich habe seit Jahren ein paar NAT Forwardings eingerichtet, die bisher auch immer funktionierten. Nach dem Upgrade nun aber nicht mehr.
Was habe ich schon versucht? NAT Forwardings gelöscht und neu angelegt, Ports geändert, Reihenfolge der Rule geändert, komplette Konfiguration neu eingelesen...
Der Witz: Mein Telefon benötigt ebenfalls NAT Forwarding, die Rules stehen direkt unter den nicht funktionierenden, telefonieren geht aber...
Im Live Log sehe ich, dass die Default deny / state violation rule auslöst, obwohl die ja eigentlich als letztes ansprechen soll.
Ich nutze nur ein WAN Interface (allerdings IPv4+IPv6) und habe an anderer Stelle (englischer Forenteil) gelesen, dass teilweise das Gateway weggeflogen wäre. In den Interfaces steht als Option auch nur Auto-detect zur Verfügung, ich kann gar kein bestimmtes Gateway auswählen...

Irgendwelche Ideen, was ich falsch mache?

Als Ergänzung möchte ich erwähnen, dass, wenn die IPv6 Adressen weg sind, der Dienst dhcpd6 steht und sich auch nicht starten lässt.
Ich habe das Relay nicht aktiv konfiguriert, unter den Leases wird aber im Normalzustand angezeigt, dass der Dienst gestartet ist.

Gestern lief (nachdem ich mein Posting abgesetzt hatte) alles sehr unauffällig, heute morgen war IPv6 wieder dysfunktional. (Abhilfe wie im 1. Posting beschrieben)

Moin,

ich habe gestern IPv6 eingeschaltet... :)

Nun sieht es so aus, dass der Datenverkehr eine Weile funktioniert, dann aber nicht mehr. Wenn ich ins Dashboard schaue, haben die Interfaces dann nur noch eine IPv4, aber keine IPv6. Ich muss dann eines der Interfaces abspeichern (ohne etwas zu ändern) und die Konfiguration neu laden, anschließend haben dann alle Interfaces, auf denen ich IPv6 aktiviert habe auch wieder eine Adresse.
Mein Aufbau entspricht

Code Select Expand

      WAN / Internet
            :
            : VDSL2 Telekom
            :
      .-----+-----.
      |  Gateway  |  (Draytek Vigor 165 als reines Modem)
      '-----+-----'
            |
        PPPoE auf VLAN 7 + 192.168.1.1/24 ungetaggt für Zugriff auf das Modem
            |
      .-----+------.   
      |  OPNsense  |--------------------------------------------
      '-----+------.                  |                         |
            |                         |                         |
        LAN | 192.168.x.1/24  VLAN251 | 192.168.y.1/24  VLAN252 | 192.168.z.1/24 
            |                         |                         |
      .-----+------.                  |                         |
      | LAN-Switch |--------------------------------------------
      '-----+------'
            |     |
            |     ---------------------------------------------|
    ...-----+------... (Clients/Servers)                 getaggt zu den APs

Ich habe die Anleitung in der offiziellen OpnSense Doku befolgt (bzw. glaube ich, sie befolgt zu haben ;) )
Firmwarestand ist OPNsense 21.7.1-amd64, Unterbau ist ein APU Board (ähh... das mit drei igb)

Für mich sieht es so aus, dass die Lease abläuft und das Interface anschließend keine neue IPv6 zugewiesen bekommt.

Was hab ich denn da vergessen?