Hallo zusammen,
ich habe folgendes Verhalten bei meiner OPNsense beobachtet. Sobald ich den Mini-PC, auf dem die Sense installiert ist, vom Strom trenne und mich nach Start der Box wieder mit ihr via Browser verbinden möchte, funktioniert es nicht.
Der Browser läuft einfach in einen Timeout rein. Ich habe bereits die Box komplett neu konfiguriert, weil ich dachte, dass es an meinen Einstellungen liegt, doch kam ich nach zig Stunden wieder zum selben Ergebnis. Diesmal war ich dann jedoch besser vorbereitet, sodass ich mich via SSH auf die Box aufschalten konnte. Dort half dann alle Dienste neuzustarten und das WebGUI funktionierte wieder.
Problem ist jedoch, dass ich diesen Workaround nun immer anwenden muss, wenn obrige Bedingungen eintreffen. Das ist ziemlich nervig. Die Box habe ich grad noch mit den neusten Updates versorgt, doch besteht das Problem immer noch.
Hat jemand eine Idee?
Hallo zusammen,
ich habe mich etwas mit dem Thema beschäftigt und konnte aus den Logs folgende Informationen herausziehen:
2024-06-22T21:16:33 Notice opnsense /usr/local/etc/rc.reload_all: plugins_configure local (execute task : webgui_configure_do(1))
2024-06-22T21:16:31 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : webgui_configure_do(,opt1))
2024-06-22T21:16:16 Error opnsense /usr/local/etc/rc.reload_all: The command '/usr/local/sbin/dhcpd -6 -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid vlan0.23.10 vlan0.23.40 vlan0.23.30 igc0 vlan0.23.20' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.4.3-P1 Copyright 2004-2022 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Config file: /etc/dhcpdv6.conf Database file: /var/db/dhcpd6.leases PID file: /var/run/dhcpdv6.pid There's already a DHCP server running. If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging. exiting.'
2024-06-22T21:16:13 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : webgui_configure_do(,opt2))
2024-06-22T21:13:45 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : webgui_configure_do(,opt2))
2024-06-22T21:13:45 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : webgui_configure_do(,opt1))
2024-06-22T21:13:23 Notice kernel <118>Starting DHCPv6 service...done.
2024-06-22T21:13:22 Notice kernel <118>Starting web GUI...failed.
2024-06-22T21:13:22 Error opnsense /usr/local/etc/rc.bootup: The command '/usr/local/bin/flock -ne /var/run/lighty-webConfigurator.pid /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2024-06-22 21:13:22: (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.76/src/network.c.604) bind() [****::****:****:****:****]:443: Can't assign requested address'
2024-06-22T21:13:22 Notice opnsense /usr/local/etc/rc.bootup: plugins_configure early (execute task : webgui_configure_do(1))
Wenn ich die Sense gestartet habe und ich nicht auf das WebGUI komme, wähle ich mich via SSH ein und starte alle Dienste neu. Danach funktioniert das WebGUI wieder und es fällt auf, dass der DHCPv6 Service nicht gestartet ist. Ich starte ihn dann immer über das Dashboard und sehe keine augenscheinlichen Probleme.
Hast du das Listen Interface für das Web UI irgendwie anders konfiguriert als "All (recommended)"?
https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces
Quote from: Patrick M. Hausen on June 22, 2024, 10:09:02 PM
Hast du das Listen Interface für das Web UI irgendwie anders konfiguriert als "All (recommended)"?
Oh, ja! Stimmt! Ich "lausche" nur auf LAN, da ich dachte, dass es die Sicherheit erhöhen würde, alle anderen auszuschließen. Aber wie ich in dem Link von Monviech entnehmen kann, ist das problematisch, wenn ich für eine 4To6 Tunnel IPv6 das WAN tracke. Ich probiere es mal aus, es auf ALL zu stellen.
Das Problem ist mit dem Setzen auf "All" behoben. Kann ich denn über Firewall Regeln einschränken, dass das WebGUI nur über LAN erreichbar ist?
Ja. :)
> Kann ich denn über Firewall Regeln einschränken, dass das WebGUI nur über LAN erreichbar ist?
Ich ergänze: ja, ist auch in der Standardeinstellung schon so.
Grüsse
Franco
Quote from: Baender on July 17, 2024, 09:42:11 AM
Das Problem ist mit dem Setzen auf "All" behoben. Kann ich denn über Firewall Regeln einschränken, dass das WebGUI nur über LAN erreichbar ist?
Auf LAN ist die anti lock-out rule gesetzt, damit du auf LAN an die GUI kommst. Kann man aber durch spezifischere Regel für einzelne Clients ersetzen, ala:
allow ipv4/TCP SOURCE:specific clients alias PORT:any DESTINATION:LAN address PORT:443
block ipv4/TCP SOURCE:LAN net PORT:any DESTINATION:LAN address PORT:443 Auf WAN ist ja sowieso verboten, was nicht ausdrücklich erlaubt ist.
Bei deinen weiteren interen Interfaces (IOT oder Gast oder sonstwas) musst du zuerst mal den Traffic zu LAN und allen weiteren interen Interfaces ganz oben blocken. Und um nicht an die GUI zu kommen:
block ipv4/TCP SOURCE:IOT net PORT:any DESTINATION:IOT address PORT:443 für jedes interne Interface entsprechend. Und unter der Voraussetzung das unsichere, experimentelle network stacks (aka ipv6) komplett geblockt werden, auf allen Interfaces.
Happy networking....
Eure Aussage verstehe ich nicht so ganz. Ich hätte jetzt erwartet, dass mit der Einstellung Listen in All interfaces auch genau das passiert. Klar, ein Test aus dem VLAN USERS zeigt, dass sich auf 192.168.20.1 nicht das WebGUI im Browser öffnet, aber genau das hätte ich jetzt erwartet.
Dass irgendwo ein Dienst "lauscht", heißt nicht, dass es da eine Firewall-Regel gibt, die auch den Zugriff erlaubt.
Frei nach dem Motto: Vertraue keinem Test den du gar nicht gemacht hast. ;)
Ah, das habe ich mir gedacht.
@franco: das mag in der Natur meines Berufs liegen. Auf Dinge zu prüfen, die es entweder eigentlich nicht geben dürfte oder zu prüfen, ob etwas tatsächlich so ist..
Ich glaube, das bringt man oft auch in IT-Berufen ein. Dinge nicht als gegeben hinzunehmen.
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.
Quote from: Andi75 on July 19, 2024, 02:47:47 PM
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.
Dasn liegt an dem Socket-API. Ein Socket ist sowas wie ein File-Descriptor für's Netzwerk. Ein Prozess kann auf eine bestimmte IP-Adresse "lauschen". Dann wird er vom Kernel immer dann aufgeweckt, wenn da ein Paket auf dem best. Port zu dieser IP-Adresse rein kommt.
Damit das klappt, muss die IP-Adresse konfiguriert sein - auf irgendeinem Interface. Ansonsten schlägt der Aufruf fehl und der Prozess ist an gar kein Interface gebunden. Oder nur an die anderen, die zufälligerweise da waren.
Ziehst du aus einem Interface den Stecker raus, geht das Interface in den Status "down". Damit entfernt das System auch die IP-Adresse und der Socket verschwindet ebenfalls. Steckst du das Kabel wieder rein, kommt alles wieder, aber die meiste Software wie DNS-Server, Webserver und Konsorten - genau so wie das ganze API - stammen aus einer Zeit, da haben sich IP-Adressen nicht verändert, ohne dass die Kiste gebootet wurde.
Warum klappt es jetzt mit "All (recommended)"?
Weil das nicht bedeutet "mach dir eine Liste aller verfügbaren Adressen und mach auf jeder einzeln einen Socket auf". Es bedeutet "benutz bitte die spezielle Adresse 0.0.0.0 - auch bekannt als INADDR_ANY". Diese verschwindet nie und der Prozess wird jedesmal aufgeweckt, wenn zu *irgendeiner* lokalen Adresse ein Paket für z.B. Port 443 rein kommt. Im Fall unseres Web UI verhindert dann die Firewall, dass das z.B. auf WAN passiert.
HTH,
Patrick
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.
Es kann ja trotzdem einen Sinn haben, wenn man z.B. in einer RZ-Umgebung mit redundanten Links ist und sich Adressen tatsächlich nicht ändern (sollten ;)) Und man dann das UI warum auch immer auf Port 443 lassen möchte, auf vielen anderen Interfaces aber z.B. HAproxy am Laufen hat ...
Whatever. Also die Funktion selbst kann sinnvoll sein. Was außer "recommended" soll mann denn noch hin schreiben, damit die Leute nicht daran rumfummeln, wenn sie nicht genau wissen, was da eigentlich passiert?
"Only accept connections from the selected interfaces. Leave empty to listen globally. Use with care." ist jetzt auch nicht so uneindeutig und die Doku sagt nochmal ihren Teil.