Hallo,
ich habe ein kleines Netzwerk, ein PC über LAN an der Opensense (aktuelle Updates auf des opnsense sind eingespielt). Jetzt ist mir seit einigen Monaten folgendes aufgefallen.
Wenn ich den PC starte und der Desktop startbereit ist, den Browser dann direkt starte, ist ein Seitenaufbau
erst mal nicht möglich. Ich kann also keine Internetseite aufrufen oder mich auf das Webinterface der
opensense schalten. Es wird nichts angezeigt, es dauert immer erst 30 bis 40 Sekunden bis der Seitenaufbau klappt. Danach klappt alles wie es soll.
Jetzt frage ich mich ob das am PC liegt (Linux) oder ob es die opnsense ist. Nur diese ist ja immer 24/7 an.
Deshalb müsste ja die verbindung auch sofort mit dem Browser (firefox) vorhanden sein.
Als DNS nutze ich auf der opnsense unbound. Kann es eventuell damit zusammen hängen?
Muss Unbound erst mal was mit dem Client aushandeln usw.?
Ein ping auf die opnsense ist sofort möglich, auch der update Befehl von Linux (pacman -Syu) über die shell usw.
Nur der Seitenaufbau ist für die ersten 40 Sekunden gestört.
Neue Plugins im Browser habe ich nicht installiert, nutze nur ublockOrigin.
Ich meine das Phänomen ist erst seit der Umstellung auf unboundDNS aufgetreten.
Hat jemand ein ähnliches verhalten wie bei mir?
Klingt nach einem typischen DNS Problem: IPv6 wird bevorzugt, aber funktioniert nicht richtig. Einfach am WAN mal das IPv6 abschalten und schauen was passiert.
Grüsse
Franco
Das ipv6 ist schon abgeschaltet auf WAN
1. ist die sene eine vm oder metal
2. wie ist dein netz aufgebaut, hängt der pc wirklich direkt an der sense (sollte der aufbau anders sein bitte einen grafischen netzwerkplan)?
3. was für ein internet, macht die sense PPPoE, wie genau kopmmst du ins ubnternet, welcher provider?
4. screenshot von deiner WAN konfiguration
Wenn der Packagemanager sofort funktioniert (braucht ja auch DNS) würde ich eher mal den Rechner bzw. Browser in's Visier nehmen. Irgendwelche (alten) Configs z.B. mit Proxy? Mal einen anderen Browser installiiert?
Quote from: micneu on March 30, 2023, 02:01:02 PM
1. ist die sene eine vm oder metal
2. wie ist dein netz aufgebaut, hängt der pc wirklich direkt an der sense (sollte der aufbau anders sein bitte einen grafischen netzwerkplan)?
3. was für ein internet, macht die sense PPPoE, wie genau kopmmst du ins ubnternet, welcher provider?
4. screenshot von deiner WAN konfiguration
1. Die Sense ist metal
2. Der PC hängt direkt per LANkabel an der Sense
3. Vodafone Kabel Anschluss --> am WAN der Sense hängt die VodafoneStation im BridgeMode
4. werde ich heute abend hochladen, bin aktuell nicht zuhause
@chemlud
ja, vielleicht im firefox unter Verbindungs-Einstellungen, die Proxyeinstellungen überprüfen.
Da sollte am besten kein Proxy ausgewählt sein.
Vielleicht hat ein Update das verstellt --> da schaue ich heute abend auch mal nach
...bei Vodafone würde ich mal blind auf irgendwelchen ipv6-Murks tippen..
PS: oder irgendwelchen DNS-Voodoo im Frozila Eiermox konfiguriert?
Ich habe das noch mal jetzt genauer getestet.
Also wenn der PC gestartet wird, ist auch kein Update über die shell mittels "pacman -Syu" möglich.
Im Browser firefox sind keine Seiten aufrufbar, ich komme auch nicht auf das Webinterface der OPNSense.
Ein Aufrufen des Webinterfaces der VodafoneStation ist auch nicht möglich.
Ich komme aber ohne Probleme auf den AccessPoint. Meinen Netzplan habe ich angehängt, ich denke der zeigt meinen Aufbau ganz gut. Die opnsense ist ein APU Board, 24/7 an.
Die opnsense rufe ich im Browser per DNS Name auf, die Vodafone Station per IP.
Beide Aufrufe klappen ja nicht.
Unbound DNS kann es dann ja eigentlich nicht sein, weil die Vodafone Station per IP angesprochen wird und das auch nicht klappt.
Nach ca. 40 Sekunden erreiche ich alle Geräte wieder über das Webinterface und alles funktioniert "normal".
Ich verstehe das nicht mehr :-(
Ist da irgendein Switch involviert? Eine ganz traditionelle Spanning-Tree Implementierung ohne Portfast braucht genau 30 Sekunden bis ein Port von "Interface up" in den "forearding" Zustand wechselt.
Nein, ich habe kein switch, der PC hängt direkt am LAN-Port der opnsense, weil das ist mein einziger PC.
Die andere Geräte wie smartphone oder PS4 sind per WLAN verbunden.
Auf allen Interfaces habe ich IPv6 Configuration Type auf None gestellt
Ich vermute das es am unboundDNS liegt.
Wenn ich z.B. nach dem PC start eine shell aufmache und ein ping auf www.heise.de mache klappt das nicht.
--> www.heise.de: Temporärer Fehler bei der Namensauflösung
Ich habe die Zeit mal gestoppt --> es sind ca. 85 Sekunden, dann wird der ping aufgelöst.
Ich kann das Opnsense Webinterface nicht per DNS Name direkt nach dem Start aufrufen, aber über die IP (192.168.1.1).
Ich habe mal am PC geschaut:
Meine Netzwerkkarte wird mittels "systemctl status systemd-networkd.service" gestartet.
Direkt nach dem Login erfolgreich gestartet.
--> Active: active (running) since Thu 2023-03-30 20:13:00 CEST; 19s ago
DNS aber nicht funktionsfähig.
Jetzt schaue ich mir den LOG vom unboundDNS auf der opnsense an, da steht folgendes:
2023-03-30T20:14:26 Informational unbound [61244:0] info: start of service (unbound 1.17.1).
Startzeit meines Netzwerkdienstes am Client war 20:13:00
Der Unbound startete dann 20:14:26
Das sind ungefähr die 85 Sekunden die ich auch gemessen habe.
Jetzt meine Frage:
Warum startet der unboundDNS auf der opnsense neu wenn ein Client im Netzwerk startet?
Oder interpretiere ich den LOG falsch?
Lass mich raten: du hast den Unbound ausdrücklich auf einzelne Interfaces gebunden? Nun, wenn das Interface down ist, kann der Unbound nicht laufen. Stell ihn auf "All" und lass die Firewall-Regeln dafür sorgen, dass von außen niemand Unsinn treibt. Dann ist er auch immer sofort da.
Warum fummeln immer alle an den Interface-Einstellungen rum? Hatten wir gerade auch wieder beim Web UI. Da steht nicht umsonst "All (recommended)" im UI. ;)
Wenn gemeint ist: Services --> Unbound DNS --> General
da habe ich unter Network Interfaces kein ALL
Ich kann da einzelene Interfaces auswählen, LAN, WAN und WLAN
Ausgewählt habe ich da LAN und WLAN
Wähle alles ab, dann steht da "All".
ok, muss ich dann noch eine Regel in der firewall erstellen oder reicht das dann so?
Weil ich mir da nicht sicher war wegen der WAN Schnittstelle habe ich den unbound damals nur auf LAN und WLAN begrenzt.
Aber jetzt wird mir so einiges klarer weil der unbound erst mal down war.
Wenn du auf WAN nach wie vor ein "deny all" hast, dann reicht das so. Du hättest für LAN und WLAN auch mit diesen expliziten Zuweisungen eine Firewall-Regel gebraucht, die den Zugriff erlaubt. Folglich hast du die schon.
Mal zur Erklärung: "All" ist in der IP-Welt speziell. Die Adresse heißt symbolisch INADDR_ANY und ist für IPv4 0.0.0.0 und für IPv6 ::
Wenn ein Service an diese Adresse einen Socket bindet, dann ist der immer "da".
Sagst du dem Service dagegen "nimm nur LAN", dann bindet er den Socket an die Adresse (z.B.) 192.168.1.1. Fährst du nun den PC runter, geht auch das Interface bei der OPNsense auf "down". Und damit ist die Adresse nicht mehr da. Und damit der Service dann natürlich auch nicht mehr.
Deshalb sollte man alle Dienste einfach wie auch voreingestellt auf "All" stehen lassen, es sei denn, man weiß sehr genau, was man tut und warum.
Gruß
Patrick
Ich habe das jetzt auf ALL umgestellt in unbound, jedoch startet der Dienst trotzdem erst verzögert nach dem der PC gestartet wurde.
Das sind meine Einstellungen:
Was sagt denn?
netstat -na | grep 53
Direkt anch dem Start des Clients:
udp 0 0 192.168.1.10:39509 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:39741 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:35909 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:52801 192.168.1.1:53 ESTABLISHED
unix 3 [ ] STREAM CONNECTED 22533 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 22534 /run/user/1000/wayland-0
unix 2 [ ACC ] STREAM LISTENING 20653 /run/user/1000/p11-kit/pkcs11
unix 3 [ ] STREAM CONNECTED 18153 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 20153
unix 3 [ ] STREAM CONNECTED 22536 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 20053
unix 3 [ ] STREAM CONNECTED 22535
unix 8 [ ] DGRAM CONNECTED 15531 /run/systemd/journal/dev-log
unix 10 [ ] DGRAM CONNECTED 15533 /run/systemd/journal/socket
unix 2 [ ACC ] STREAM LISTENING 15535 /run/systemd/journal/stdout
unix 2 [ ACC ] SEQPACKET LISTENING 15539 /run/udev/control
und dann ca. 90s später wenn DNS funktioniert:
unix 3 [ ] STREAM CONNECTED 22533 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 22534 /run/user/1000/wayland-0
unix 2 [ ACC ] STREAM LISTENING 20653 /run/user/1000/p11-kit/pkcs11
unix 3 [ ] STREAM CONNECTED 18153 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 20153
unix 3 [ ] STREAM CONNECTED 22536 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 20053
unix 3 [ ] STREAM CONNECTED 22535
unix 8 [ ] DGRAM CONNECTED 15531 /run/systemd/journal/dev-log
unix 8 [ ] DGRAM CONNECTED 15533 /run/systemd/journal/socket
unix 2 [ ACC ] STREAM LISTENING 15535 /run/systemd/journal/stdout
unix 2 [ ACC ] SEQPACKET LISTENING 15539 /run/udev/control
Das kann m.E. nicht vollständig sein.
Quote from: pmhausen on March 30, 2023, 09:20:40 PM
Das kann m.E. nicht vollständig sein.
Doch, mehr war da nicht.
Aber ich schaue morgen abend noch mal in Ruhe und poste das dann.
Schon mal vielen Dank für die Hilfe
Mach mal einen kompletten Neustart mit Interfaces: All.
Da sollte ein "*.53" in der Ausgabe von netstat sein.
Ich habe die opnsense neu gestartet, jedoch keine Veränderung.
Hier netstat wo DNS noch nicht funktioniert: netstat -na | grep 53
Die UDP Verbindungen sind aber immer etwas unterschiedlich.
So steht da auch nichts von *.53, obwohl ich ja danach filter.
udp 0 0 192.168.1.10:45963 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:41786 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:33826 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:50427 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:50502 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:34206 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:50842 192.168.1.1:53 ESTABLISHED
udp 0 0 192.168.1.10:45207 192.168.1.1:53 ESTABLISHED
unix 3 [ ] STREAM CONNECTED 22530 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 18053
unix 3 [ ] STREAM CONNECTED 22539
unix 3 [ ] STREAM CONNECTED 20953 /run/user/1000/akonadi/akonadiserver-cmd.socket
unix 3 [ ] STREAM CONNECTED 22533 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 20453 /run/user/1000/akonadi/mysql.socket
unix 3 [ ] STREAM CONNECTED 20538
unix 3 [ ] STREAM CONNECTED 21553
unix 3 [ ] STREAM CONNECTED 19053 /run/dbus/system_bus_socket
Und hier dann wenn DNS funktioniert, nach ca. 85 Sekunden immer:
tcp 0 0 192.168.1.10:50998 185.199.108.153:443 ESTABLISHED
unix 3 [ ] STREAM CONNECTED 23539
unix 3 [ ] STREAM CONNECTED 22530 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 18053
unix 3 [ ] STREAM CONNECTED 22539
unix 3 [ ] STREAM CONNECTED 20953 /run/user/1000/akonadi/akonadiserver-cmd.socket
unix 3 [ ] STREAM CONNECTED 22533 /run/user/1000/wayland-0
unix 3 [ ] STREAM CONNECTED 20538
unix 3 [ ] STREAM CONNECTED 23532
unix 3 [ ] SEQPACKET CONNECTED 25366
unix 3 [ ] SEQPACKET CONNECTED 25365
unix 3 [ ] STREAM CONNECTED 21553
unix 3 [ ] STREAM CONNECTED 19053 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 23533
Ich habe so ja nichts umgestellt in der opnsense, immer nur die Updates eingespielt.
Ich vermute das Verhalten hat mit einem Update zutun.
Ich weiss das es früher auch eine kleien VErzögerung gab, aber daswaren vielleicht nur wenige Sekunden, nicht lange 85 Sekunden wie heute. Die kleine Verzögerung wohl deshalb weil ich auf unbound nicht ALL als Schnittstelle ausgewählt hatte.
Moooment ... du sollst den Befehl natürlich auf der OPNsense ausführen, nicht auf deinem Linux!
upps... sorry :-(
mache ich dann heute abend
Hier "netstat -na | grep 53" auf der opnsense direkt nach PC Start wo unbound nicht funktioniert:
tcp4 0 0 127.0.0.1.953 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
udp4 0 0 *.53 *.*
udp4 0 0 *.53 *.*
udp4 0 0 *.53 *.*
udp4 0 0 *.53 *.*
fffff800391d5400 dgram 0 0 0 fffff80039248300 0 fffff800391d5300
fffff800391d5300 dgram 0 0 0 fffff80039248300 0 0
Und hier wo der unbound funktioniert:
tcp4 0 0 63.101.118.16.2303 134.130.5.9.53 ESTABLISHED
tcp4 0 0 63.101.118.16.39163 134.130.5.9.53 ESTABLISHED
tcp4 0 0 63.101.118.16.6666 134.130.4.9.53 ESTABLISHED
tcp4 0 0 63.101.118.16.57370 134.130.4.9.53 ESTABLISHED
tcp4 0 0 63.101.118.16.18587 134.130.4.9.53 ESTABLISHED
tcp4 0 0 63.101.118.16.19889 149.38.1.26.53 ESTABLISHED
tcp4 0 0 127.0.0.1.953 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
tcp4 0 0 192.168.1.1.22 192.168.1.10.53620 ESTABLISHED
udp4 0 0 *.53 *.*
udp4 0 0 *.53 *.*
udp4 0 0 *.53 *.*
udp4 0 0 *.53 *.*
fffff800391d5400 dgram 0 0 0 fffff80039248300 0 fffff800391d5300
fffff800391d5300 dgram 0 0 0 fffff80039248300 0 0
Da fragt gerade der Updater vom Client PC die Server der FH Aachen ab.
Nur diese IP kann ich mir nicht erklären: 149.38.1.26
scheint in Belgien zu sein.
In der ersten Ausgabe läuft der Unbound aber und nimmt Requests entgegen. Das sind die ganzen *.53 Einträge.
Oder läuft dort am Ende noch etwas anderes als Unbound, was diese Ports belegt? sockstat ist dein Freund ...
Auf der opnsense läuft eigentlich auf dem Port 53 nichts anderes als unbound
sockstat | grep :53
unbound unbound 22471 5 udp4 *:53 *:*
unbound unbound 22471 6 tcp4 *:53 *:*
unbound unbound 22471 7 udp4 *:53 *:*
unbound unbound 22471 8 tcp4 *:53 *:*
unbound unbound 22471 9 udp4 *:53 *:*
unbound unbound 22471 10 tcp4 *:53 *:*
unbound unbound 22471 11 udp4 *:53 *:*
unbound unbound 22471 12 tcp4 *:53 *:*
Irgendwas scheint mit dem unbound nicht OK zu sein.
Z.B. lädt dieser auch nicht mehr Nachts die Blocklisten.
Das steht auch im Log:
blocklist download : unable to download file from https://blocklistproject.github.io/Lists/alt-version/ransomware-nl.txt (error : HTTPSConnectionPool(host='blocklistproject.github.io', port=443): Max retries exceeded with url: /Lists/alt-version/ransomware-nl.txt (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x8027cf970>: Failed to establish a new connection: [Errno 8] Name does not resolve')))
Quote from: ziegler on March 31, 2023, 04:09:22 PM
Auf der opnsense läuft eigentlich auf dem Port 53 nichts anderes als unbound
sockstat | grep :53
unbound unbound 22471 5 udp4 *:53 *:*
unbound unbound 22471 6 tcp4 *:53 *:*
unbound unbound 22471 7 udp4 *:53 *:*
unbound unbound 22471 8 tcp4 *:53 *:*
unbound unbound 22471 9 udp4 *:53 *:*
unbound unbound 22471 10 tcp4 *:53 *:*
unbound unbound 22471 11 udp4 *:53 *:*
unbound unbound 22471 12 tcp4 *:53 *:*
Irgendwas scheint mit dem unbound nicht OK zu sein.
Z.B. lädt dieser auch nicht mehr Nachts die Blocklisten.
Das steht auch im Log:
blocklist download : unable to download file from https://blocklistproject.github.io/Lists/alt-version/ransomware-nl.txt (error : HTTPSConnectionPool(host='blocklistproject.github.io', port=443): Max retries exceeded with url: /Lists/alt-version/ransomware-nl.txt (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x8027cf970>: Failed to establish a new connection: [Errno 8] Name does not resolve')))
Errno 8] Name does not resolve
Quote from: ziegler on March 31, 2023, 04:10:07 PM
Quote from: ziegler on March 31, 2023, 04:09:22 PM
Auf der opnsense läuft eigentlich auf dem Port 53 nichts anderes als unbound
sockstat | grep :53
unbound unbound 22471 5 udp4 *:53 *:*
unbound unbound 22471 6 tcp4 *:53 *:*
unbound unbound 22471 7 udp4 *:53 *:*
unbound unbound 22471 8 tcp4 *:53 *:*
unbound unbound 22471 9 udp4 *:53 *:*
unbound unbound 22471 10 tcp4 *:53 *:*
unbound unbound 22471 11 udp4 *:53 *:*
unbound unbound 22471 12 tcp4 *:53 *:*
Irgendwas scheint mit dem unbound nicht OK zu sein.
Z.B. lädt dieser auch nicht mehr Nachts die Blocklisten.
Das steht auch im Log:
blocklist download : unable to download file from https://blocklistproject.github.io/Lists/alt-version/ransomware-nl.txt (error : HTTPSConnectionPool(host='blocklistproject.github.io', port=443): Max retries exceeded with url: /Lists/alt-version/ransomware-nl.txt (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x8027cf970>: Failed to establish a new connection: [Errno 8] Name does not resolve')))
[Errno 8] Name does not resolve
Ich habe bis auf die Updates eigentlich nichts an der OPNsense geändert, die Updates hatten auch immer geklappt.
Hatte das ab und an immer kontrolliert
...ein Screenshot von System -> Settings -> General könnte erhellend sein...
Wird gemacht.
Ich würde den Haken "Prefer ipv4 even if ipv6 is available" grundsätzlich setzen. Danach reboot (sense und client) und nochmal probieren. DNSsec ist gewünscht laut unbound config, aber keine spezifischen präferierten DNS Server ausgewählt? Hmm...
Ich habe den Haken gesetzt und jeweils neu gestartet, jedoch keine Verbesserung.
Was ist mit "DNSsec ist gewünscht laut unbound config, aber keine spezifischen präferierten DNS Server ausgewählt?" gemeint?
Ich bin was opnsense angeht kein Experte, ist mein unbound falsch eingestellt?
Quote from: chemlud on March 31, 2023, 06:31:21 PM
Ich würde den Haken "Prefer ipv4 even if ipv6 is available" grundsätzlich setzen. Danach reboot (sense und client) und nochmal probieren. DNSsec ist gewünscht laut unbound config, aber keine spezifischen präferierten DNS Server ausgewählt? Hmm...
Wie muss der unboundDNS denn "richtig" eingestellt werden?
Wenn ich unter https://www.dnsleaktest.com/ den DNS Test mache, dann zeigt dieser mir meine WAN IP als DNS an.
Wäre das denn falsch?