Messages

ich habe ein Problem bei der Nutzung von Aliasse. Ich habe das ungefähr so angelegt:

MeineListe [URL Table (IPs)] = {https://example.com/boeseIPs.txt}

MeineListe_Ausnahmen [Host(s)] = {tolleseite.de, nochtollereseite.de}

Ihr könnte euch schon denken, dass ich nun gerne einen weiteren Alias hätte, welcher quasi MeineListe - MeineListe_Ausnahmen ist.
quasi sowas -> FertigeListe = {MeineListe, !MeineListe_Ausnahmen}
Das funktioniert leider nur, wenn in MeineListe_Ausnahmen IPs mit einem ! davor eingetragen sind. Mit den Adressen geht es nicht und ich kann auch keinen anderen Alias mit einem ! versehen (wie hier in FertigeListe). Gibt es da eine Möglichkeit oder kann OPNsense das nicht?

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.