Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - white_rabbit

#46
Kein Unterschied ... da steht kein anderer Eintrag vom dhclient als die o.g.

Wir haben hier keine statische IP (das wird vom Provider nicht angeboten -- peinlich aber ist leider nicht zu ändern)
Aber die dyn. Adresse bleibt vermutlich sehr lange bestehen ... soll ich das so deuten, dass das beobachtete Verhalten dann unproblematisch ist?
#47
Ok -- nur: Die steht da nicht (zumindest nicht unter "latest.log")!??

Daher: Wo finde ich die? Es sind wirklich nur diese beiden Einträge in der Log-Datei zu sehen ... da steht leider auch nichts von wegen "DHCPACK" oder "renewal" oder ähnliches...

#48
Hallo.
Ich habe unter /var/log/system/latest.log im 15-Min-Takt diese Meldung:


dhclient 26219 - [meta sequenceId="1"] dhclient-script: Reason RENEW on igb0_vlan532 executing
dhclient 26447 - [meta sequenceId="2"] dhclient-script: Creating resolv.conf


Bin leider nicht sicher, ob das den laufenden Betrieb stört, wenn die WAN-Schnittstelle das so oft macht oder ob das problemlos ist?
Hat jemand einen guten Tipp diesbzgl? (Die WAN-Schnittstelle hängt an einem ONT, der Provider ist e.ON (Fiber).)





#49

Das ist es! Super -- danke!
#50
Oh -- das ist super. Dann begebe ich mich mal auf die Suche ... besten Dank für den Tipp!
(-> Firewall -> Gruppen meinst Du aber nicht, oder?)
#51
Ok -- das geht natürlich auch aber dann ist das gleiche Problem nur zurück auf das OPNSense-WebUI verlagert, oder?
#52
Man muss nicht - aber man kann .... um z.B. zu erreichen, dass für die Geräte mit IP-Adresse aus dem DHCP-Bereich andere (z.B. striktere) Filter-Regeln gelten als für die anderen Geräte.
#53
Hallo.
Wir wollen gerne AdGuard auf der OPNSense einsetzen und sind dazu dieser Anleitung gefolgt:
https://www.max-it.de/adguard-dns-blocker-neues-opnsense-plugin/

Nun ist es so, dass wir hier ein relativ großes WLAN haben. Es sieht so aus:
Subnetz    172.16.0.0
Subnetzmaske    255.255.0.0
Verfügbarer Bereich    172.16.0.1 - 172.16.255.254

Der DHCP-Bereich ist aber viel kleiner und umfasst "nur":
172.16.8.1 bis 172.16.15.254

Meine Frage ist, was ich bei den Client-Einstellungen im AdGuard in diesem Fall eintragen muss:
Wir haben die eigenen Geräte aus historisch gewachsenen Gründen "um diesen Bereich herum gelegt": Es gibt also Geräte mit festen IP-Zuordnungen unter 172.16.1.0/24 und ebenfalls im Bereich 172.16.16.0/24.
Diese beiden Subnetze kann ich ja auch problemlos im AdGuard eintragen, doch wenn ich als dritten Bereich dann
172.16.8.0/20 eintrage, gibt es doch eine Überschneidung, oder??

Leider kann ich im AdGuard keinen Bereich "von ... bis" eintragen sondern nur das ganze Subnetz  -- oder verstehe ich das falsch?
Danke jedenfalls für's Mitdenken.
;)


#54
Hallo.
Wir haben bei uns die Situation, dass wir ein WLAN für Gäste mit Captive Portal und ein anderes für alle anderen Geräte haben.

Natürlich sollen die Geräte eigentlich immer in "ihrem WLAN" bleiben und nicht in das Gast-Netz wechseln, doch das tun sie aus den unterschiedlichsten Gründen häufig nicht. Dann entsteht eine Situation, wie man sie nicht haben will, denn die Geräte sind in einer Art "Zwischenwelt" -- sie bekommen also zwar eine interne IP-Adresse aber sind natürlich nicht online und über das Internet erreichbar, da das Captive Portal das noch verhindert.

Auf diese Weise entgehen die Geräte aber auch der "Kontrolle" durch das MDM, da angestoßene Geräterichtlinien nicht am Gerät ankommen können. Da die Endgeräte bei uns iPads sind, hat Apple bei allen Aktionen leider auch die Finger mit im Spiel, so dass man bei vielen Aktionen eine Verbindung zu Apple-Servern haben muss.

(Leider ist es nicht möglich, dass man das Wechseln des WLANs komplett unterbinden kann, denn dann wäre das Problem ja schon gelöst. Genauso wenig ist es angeblich nicht mehr möglich, dass man den Schalter "Automatisch mit WLAN verbinden" per MDM deaktiviert. Das kam scheinbar mit einem der letzten iOS-Updates rein und führt dazu, dass die Geräte nicht immer automatisch verbunden sind. )

Daher meine Frage, ob man es (z.B. mit geschickten Firewall-Regeln) hinkriegen kann, dass alle Geräte in allen Netzen immer das Apple-Universum 17.0.0.0/8  erreichen können, auch wenn das Captive-Portal das ohne Credentials oder gültiges Voucher noch verhindert? Auf diese Weise wären die Geräte trotzdem über das MDM erreichbar ...
Vielleicht gibt es für so einen Fall ja einen sinnvollen Weg?


#56
Ich habe eine Fehlermeldung gefunden -- deutet also wirklich auf ein Problem seit dem letzten Update hin?


tail /var/log/configd/latest.log

Script action failed with Command
'/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py /zoneid '0'
/output_type 'json'' returned non-zero exit status 1. at Traceback (most recent call last):   
File "/usr/local/opnsense/service/modules/actions/script_output.py", line 44, in execute
subprocess.check_call(script_command, env=self.config_environment, shell=True,   
File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call     
raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError:
Command '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py /zoneid '0'
/output_type 'json'' returned non-zero exit status 1.


Kann das jemand reproduzieren?


Versionen OPNsense 24.1.6-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

#57
Hallo.
Wir setzen das OPNSense-Captive-Portal für ein bestimmtes WLAN ein.

Da aber ein paar Geräte ohne Captive Portal ins WLAN gelangen können sollen, haben wir in den erweiterten Einstellungen ein paar MAC-Adressen unter " Erlaubte MAC-Adressen" eingetragen.

Das funktionierte bis vor kurzem auch: für diese Geräte wurde das Portal nicht angezeigt.
Jetzt ist es aber leider so, dass auch für diese Geräte zunächst die Portalseite erscheint und diese Geräte nicht mehr direkt online sind. Kann das mit dem kürzlich durchgeführten Update auf 24.1.6 zusammenhängen?
Oder wonach kann man da sonst schauen?
Danke für einen guten Tipp.

Ich sehe gerade, dass das gleiche Problem hier schon mal lief:
https://forum.opnsense.org/index.php?topic=32859.msg159241#msg159241
Das klang aber so, als sei das gefixt??

Was mir übrigens gerade erst aufgefallen ist:
Unter >>> Dienste: Captive Portal: Sitzungen
standen bisher immer viele Einträge  -- das ist jetzt komplett leer.


#58
Das Problem ist gelöst! Bei uns lag es daran, dass wir für dieses Netz externe DNS-Server im DHCP-Server eingetragen hatten. Damit wurde scheinbar das Portal nicht geladen.
Sobald als erster DNS-Server wieder die OPNSense-FW stand, lief es wieder!
#59
... ach ja:
noch eine Beobachtung dazu: Wenn man auf Dienste -> Captive Portal -> Sitzungen wechselt, steht dort bei allen Verbindungen unter Verbunden seit: Invalid Date.
Die Uhrzeit auf der Firewall stimmt aber!
#60
Hallo.
Wir haben hier sei ein paar Tagen Probleme mit dem Captive Portal der OPNSense. Die Portalseite erscheint nicht mehr automatisch, wenn man sich mit dem WLAN verbindet. Man kann sie aber erreichen (wenn man die IP-Adresse der Firewall kennt) und sich manuell anmelden. Diese Seite sollte aber automatisch geladen werden ... hat jemand eine Idee, woran das scheitern kann? Wir nutzen
OPNsense 24.1.5_2-amd64 und haben an den Captive-Portal-Einstellungen nichts verändert.
Ein Neustart der Firewall hat leider auch nicht geholfen.
Danke für einen guten Tipp.