Messages

Danke für die ausführliche Antwort.

Wäre es dann vielleicht nicht sinnvoll, die 'Listen Interface'-Option nicht so umzubauen, dass sie immer auf 0.0.0.0 lauscht und stattdessen, der Einstellung entsprechend, einfach passende Firewallregel erstellt (in den automatisch generierten Regeln)? Für den User wäre das Ergebnis dann doch das, was er erwartet und das Problem mit der nicht erreichbaren GUI wäre dahin.

Dieses Problem mit der nicht erreichbaren WebGUI taucht ja in schöner Regelmäßigkeit auf. Und nahezu immer ist die Lösung die Option 'Listen Interface' wieder auf "All (recommended)" zu setzten. Was ich mich jetzt frage... warum gibt es diese Option überhaupt, wenn sie offensichtlich mehr Ärger macht als Nutzen bringt? Gibt es ein Szenario, in denen es Sinn macht etwas anderes als "All" zu setzen?

Ich selber musste selbst auf die harte Tour lernen, dass es zu Problemen führt, wenn etwas anderes als "All" einstelle. Aber warum ist das überhaupt so? Was passiert da? Ich frage aus rein technischem Interesse.

Ich hatte das Problem schon mal relativ früh bei einer der ersten 23.1er-Versionen. Das war dann aber nach einem Update verschwunden. Leider weiß ich nicht mehr genau mit welchem.

Erst mit diesem Update tritt es wieder auf und ist bisher bei jedem Boot reproduzierbar (bei so ca zehn Versuchen).
Ich versuche erstmal damit zu leben und bastel vielleicht etwas, dass den Dienst ein bis zwei Minuten nach einem Boot einfach noch mal restartet. Oder gibt es vielleicht eine elegantere Lösung?

Hallo,

nach dem Update auf 23.1.10_1 wird nach dem Reboot keine GUA an die Clients weitergereicht. Eine IPv6-Konnektivität ist aber grundsätzlich vorhanden (Prefix wird erfolgreich durch den Provider zugewiesen). Die ULA wird wiederum korrekt verteilt. Es scheint als wüsste der Dienst nur nichts davon.
Erst ein Neustart des radvd-Dienstes bringt Abhilfe und die GUA wird dann sofort verteilt. Im Grunde nicht so schlimm, da ein Neustart eher selten ist. Aber unschön ist es schon :-)

Kann man da etwas machen? Evtl. den radvd später starten oder gibt es eine Möglichkeit den Dienst nach dem erfolgreichen Bootvorgang nach einer Weile neu zu starten?

After a reboot Unbound denys requests on the WireGuard interface. It a normal behavior, because the WG-interface is not yet ready when the unbound service starts after a reboot.
Simply go to Services/Unbound/Access Lists and add your WireGuard Subnet. Then it should work.

Ich hab mich nach dem Upgrade auf 23.1 selbst mit dem gleichen Problem rumgeschlagen und hatte lange HAProxy im Verdacht, weil sich das Problem immer erst dann bemerkbar gemacht hat. Hatte alles mögliche durch und hatte immer wieder mal das Problem, dass die WebUI nicht starten wollte. Manchmal ging es, manchmal nicht... Das Log hat mich auch nicht wirklich weitergebracht. Es sah halt immer so aus, als würde bereits ein Service auf dem Port lauschen (bei mir war's 8443).

Am Ende bin ich drauf gekommen, dass ich immer 'Listen Interface' für die WebGUI auf "LAN" gestellt hab. Nachdem ich dort auf "All" gegangen bin, war das Problem Geschichte.

I did not run DHCPv6 to configure the clients. I'm only using radvd to do the stateless address auto-configuration. That's working great for me.

Have you tried to restart the Router Advertisement service? Some minutes ago something similar happened to me. I lost my connection and after getting back online, all clients lost IPv6. After restarting the RA service they got their new GUA.

why is lighttpd running on 8043 and 8443 now?

root@OPNsense:~ # sockstat | grep "lighttpd"
root     lighttpd   28331 6  tcp4   127.0.0.1:8043        *:*
root     lighttpd   28331 8  tcp6   ::1:8043              *:*
root     lighttpd   28331 9  tcp4   192.168.0.1:8043      *:*
root     lighttpd   28331 10 tcp6   fd81:...:8043 *:*
root     lighttpd   28331 11 tcp6   2003:...:8043 *:*
root     lighttpd   45507 4  tcp4   127.0.0.1:43580       *:*
root     lighttpd   45507 5  tcp6   ::1:43580             *:*
root     lighttpd   45507 6  dgram  -> /var/run/logpriv
root     lighttpd   23990 6  tcp4   127.0.0.1:8443        *:*
root     lighttpd   23990 8  tcp6   ::1:8443              *:*
root     lighttpd   23990 9  tcp4   192.168.0.1:8443      *:*
root     lighttpd   23990 10 tcp6   fd81:...:8443 *:*
root     lighttpd   23990 11 tcp6   2003:...:8443 *:*

changing the webgui port from 8443 to 8043 solved it for me. Now the webgui is accessible and the service is green now \o/

interestingly, the service is still available under port 8443, too  :o

Yesterday I spend some hours to identify the problem. I did a fresh install and everything was working. But at that point I installed the haproxy and the acme plugin and redid the configuration the problem reapeared. But I can't believe they are the cause, but it seems so.
The webgui freezes or can't get loaded. Sometimes I got a 503. When I deactivated both plugins, everything is running fine.

After some trying around (changeing haproxy config, some clean installs), the webgui is accessable but the service will be shown as ,,down". Very strange...
There are no errors in the logs and there are no other services that were touching the webgui port (8443).

I can't access my WebGui, too. I figured out, that haproxy and/or the acme client is the cause. But I didn't know why it is happening.
haproxy is listening on port 80 und 443, the webgui is listening on 8443. Before the update to 23.1 the config is working perfectly for months.

I had the same problem. No IPv6-connectivity from the clients, but OPNsense was okay. I then noticed that the GUA is not passed to the clients. Restarting the RA service nor a reboot didn't help.
I then checked and saved the RA settings (without changing anything) and after that it worked. Since then the problem has not occurred.

Ich nutze Magenta ja nun inzwischen nicht mehr und folglich ist die Konfig bei mir nicht mehr aktiv.
Die Konfiguration der Interfaces ist aber nach wie vor die selbe wie ,,damals". ,,Block Bogon Networks" ist nur auf dem WAN-Interface aktiv. Auf dem LAN-Interface (in dem war auch mein Magenta-Receiver), war es deaktiviert.
Der Rest der Konfiguration war genauso wie oben beschrieben. Entscheidend war das ,,Allow Options". Ohne dem ging es nicht. Und noch dazu musste man das ganze Geraffel (Reiceiver, OPNsense) nach Konfigurationsänderung einmal neu starten damit es sauber läuft ...warum auch immer. Von dem Moment ab lief es monatelang ohne Probleme.

[IGMP Proxy Konfiguration]

moin...

ich hab mich auch eine Weile mit dem Problem rumgeschlagen und irgendwie scheint es wirklich ein Ding der Unmöglichkeit zu sein eine brauchbare Anleitung im Net zu finden. Viele scheinen nur voneinander abzuschreiben.  ::)

Hier ist mal meine (bei mir mal funktionierende) Konfiguration:

Das Plugin os-igmp-proxy wird benötigt.

IGMP Proxy Konfiguration:
Interface:   WAN
Type:   Upstream Interface
Threshold:   1
Networks:   232.0.0.0 / 8
      87.141.0.0 / 16

Interface:   LAN
Type:   Downstream Interface
Threshold:   1
Networks:   [IP LAN-Network] (Bsp. 192.168.1.0/24)

Firewall Aliases:
Name:   IPTV_Source
Type:   Host(s)
Content:   87.141.215.251

Name:   IPTV_Destination
Type:   Network(s)
Content:   232.0.0.0/16
   224.0.0.0/4

Firewall Rules:
WAN
Action:   Pass
Interface:   WAN
Direction:   In
TCP/IP Version:   IPv4
Protocol:   IGMP
Source:   any
Destination:   IPTV_Destination
Description:   MagentaTV (IGMP)
allow options:   True

Action:   Pass
Interface:   WAN
Direction:   In
TCP/IP Version:   IPv4
Protocol:   UDP
Source:   IPTV_Source
Destination:   IPTV_Destination
Destination port:   10000
Description:   MagentaTV (RTP)
allow options:   True

LAN
Action:   Pass
Interface:   LAN
Direction:   In
TCP/IP Version:   IPv4
Protocol:   IGMP
Source:   any
Destination:   IPTV_Destination
Description:   MagentaTV (IGMP)
allow options:   True

Action:   Pass
Interface:   LAN
Direction:   In
TCP/IP Version:   IPv4
Protocol:   UDP
Source:   IPTV_Source
Destination:   IPTV_Destination
Destination port:   10000
Description:   MagentaTV (RTP)
allow options:   True

Wichtig ist das "allow options". Die Option findet sich in der Firewall Regel unten unter "Advanced Options".

Ich hoffe, dass ist alles halbwegs selbsterklärend und ich kann damit ein wenig weiterhelfen. Inzwischen habe ich selbst kein MagentaTV mehr. Ich gehe jetzt aber mal davon aus, dass sich da in dem letzten halben Jahr nicht viel geändert hat.