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

Topics - white_rabbit

#1
Hallo.
Ich möchte einen Trunk zwischen unserer OPNSense (noch auf 25.1.12) und einem Unifi-US-16-XG (10 GBit Ports) neu konfigurieren, weil ich glaube, dass da bei uns ein Konfigurationsfehler vorliegt.

Im Moment ist es so, dass ich auf der OPNsense-Seite unter den Zuweisungen für alle VLANs, die auf der OPNSense ankommen sollen, eine Schnittstelle eingerichtet habe, die immer so lautet: ax0_vlan<xy> Nach meinem Verständnis werden diese VLANs damit tagged über den Trunk übertragen, richtig?

"Aus Gründen" (leider weiß ich nicht mehr warum) gibt es die Ausnahme für VLAN1. Dort haben wir lediglich die Zuweisung ax0 gemacht (also ganz ohne VLAN). Ist es richtig, dass damit über diese Schnittstelle VLAN1 (automatisch?) untagged übertragen wird? Ich denke, dass das ungünstig bzw sogar falsch ist, da z.B. bei den Statistiken zu den Schnittstellen viel zu viel Traffic über VLAN1 angezeigt wird, der da eigentlich gar nicht hingehört.

Wenn man es richtig/vernünftig machen will, muss offensichtlich auf beiden Seiten die gleiche Konfiguration eingestellt werden und hier kommen meine Fragen ins Spiel: Reicht es aus, wenn man auch für vlan1 die Zuordnung  ax0_vlan1  erstellt?
Auf der Unifi-Seite sieht das ganze so aus wie im angehängten Screenshot zu sehen. Ich habe dort schon mal vorab ein Profil erzeugt, bei dem alle VLANs tagged übertragen werden sollen. Was ich aber nicht weiß: Wie ist es mit den Optionen ganz unten? Welche davon sind notwendig und welche nicht?

Leider weiß ich nicht mehr, warum wir das damals zunächst anders eingerichtet hatten. Ist es möglich, dass eine ältere Version des Unifi-Controllers immer ein VLAN untagged mit übertragen will?
Über kurze Hilfe würde ich mich freuen.
Vielen Dank.


#2
Hallo.
Wir haben hier folgendes Setup: Auf einem Proxmox-Hypervisor läuft in einem VLAN ein Windows-10-Server. Der konnte sich bisher über Wireguard mit einem anderen Netzwerk (physikalisch getrennt) verbinden, um von dort ein paar Daten zu holen. Das funktioniert neuerdings aber nicht mehr. Beim Aufbau der Verbindung erscheint in Dauerschleife:
"Handshake for peer 1 () did not complete after 5 seconds, retrying"

Die initiale Verbindung über Port 51820 wird zwar aufgebaut aber danach geht's offenbar nicht weiter.
Zunächst hatte ich ein Win-10-Update im Blick, da man darüber viel finden kann, dass es ab einem bestimmten Update nicht mehr funktioniert hat.
Doch gestern fiel mir etwas anderes auf:
Wenn ich die VM nicht über das VLAN sondern über das Management-Netz verbinde, klappt alles. Daher muss es offenbar so sein, dass sich auf der OPNSense etwas verändert hat und jetzt z.B. eine weitere Regel eingestellt werden muss, die den Handshake erlaubt?
Ich weiß nicht genau, wonach ich hier suchen muss, denn die Verbindung läuft so:

VM mit Win10 auf Proxmox
 -> OPNSense I (zZ 25.1.11-amd64)
 -> Internet
 -> OPNSense II (zZ 25.1.10-amd64)
 -> VM mit SQL-Server (Ziel)

Wer hat einen guten Tipp, wo ich hier nachjustieren muss und wie diese Einstellungen aussehen müssen?
Danke.
#3
Hallo.
Der Dienst "ISC DHCP" auf der OPNSense ist bekanntlich abgekündigt -- stattdessen wird "Kea DHCP" übernehmen.
Meine Frage ist: Wird es eine automatische Übernahme der Daten geben oder muss man selbst migieren bzw sind zwischendurch irgendwelche eigenen Handgriffe notwendig?
Danke.
#4
Hallo.
Wir haben hier seit dem Update von 25.1.5_4 auf _5 das bekannte Problem mit dem Captive Portal: Es war bei uns so wie hier beschrieben:
https://forum.opnsense.org/index.php?topic=46796.0

Mittlerweile ist Version 25.1.5_6 erschienen mit einem Fix für das Problem. Wir haben diese Version heute installiert und die Option
[x] Disable firewall rules

If this option is set, no automatic firewall rules for portal redirection
and traffic blocking will be generated. This option allows you to override
the default portal behavior for advanced use cases, such as redirections
for DNS.
See the documentation to see which rules you should implement in this scenario.
ist nun auch vorhanden. Leider funktioniert das Captive Portal bei uns aber weiterhin nicht.
Es ist so: Wenn man den Haken setzt
[x] Disable firewall rules ist man sofort online -- allerdings erscheint das Captive Portal nicht!

Wenn man den Haken allerdings nicht setzt
[ ] Disable firewall rules
ist man nicht online, aber das Portal erscheint auch hier nicht automatisch.

Wenn man das Captive Portal manuell über Port : 8000 aufruft, kann man sich anmelden und ist anschließend online. Nur das automatische Einblenden funktioniert nicht mehr.

Wir haben auch diese Seite gefunden:
https://github.com/opnsense/core/issues/8585
Dort schreibt AndyX90:
QuoteUpdate: The issue seems to be related to the NAT Rule, which redirects DNS traffic on cp-interface to the BIND DNS.
Disabling was somehow not enough, i had to delete it.
For the moment i will use unbound on the portal interface.
Was genau ist hier zu tun?

Übrigens: Bei uns läuft AdGuard mit auf der OPNSense. Kann es da einen Zusammenhang geben, dass das Portal nicht mehr erscheint?

Hat jemand von Euch das Problem bereits gelöst?
Danke für einen guten Tipp.

#5
Hallo.
Wir haben hier ein merkwürdiges Problem mit Crowdsec, das ich nicht verstehe.
Es geht um die Domain *.webuntis.com, die innerhalb unseres Netzes neuerdings sehr häufig aufgerufen wird. Diese Domain wird neuerdings von Crowdsec intern gesperrt (nicht permanent sondern mittlerweile zum zweiten Mal) -- mir ist aber nicht klar warum: Eigentlich sollte das Tool doch nicht bei Aufrufen von innen die Domain blockieren, oder?
Ich habe den Dienst im Moment deaktiviert, doch unter
/usr/local/etc/crowdsec/parsers/s02-enrich
existiert bereits eine Datei
mywhitelists.yaml.
 Wie müsste dort ein entsprechender Eintrag für die Domain aussehen? Und: Warum reagiert Crowdsec so, obwohl es doch eigentlich Angriffe von außen abwehren soll??
Zudem: Ich sehe im OPNSense-WebUI nichts davon. Sollten die gesperrten Domains dort nicht auch aufgelistet werden?
Vielen Dank.
#6
Hallo.
Kurze Frage:
Ich lasse nachts die config.xml als Backup verschlüsselt auf ein Share kopieren.

Nun würde ich gerne in eine ältere Version schauen -- allerdings möglichst ohne die aktuelle Konfiguration überschreiben zu müssen. Ich will nur einen alten Eintrag wiederfinden und mit der aktuellen Version vergleichen. Eigentlich also keine große Sache. Da die Datei auf dem Share aber verschlüsselt liegt, wüsste ich gerne, ob man die Datei auch auf der Konsole entschlüsseln kann, um sie wieder im Klartext vergleichen zu können?
Danke.
#7
Hallo.
Ich frage mich schon länger, ob ich hier einen Denkfehler habe oder ob das ein "Designproblem" ist:

Wenn man auf der OPNSense z.B. HAProxy + ACME für die LE-Zertifikate verwendet, ist es ja problemlos möglich, dass die OPNSense die Zertifikate regelmäßig erneuert und man beim Zugriff von außen immer beim richtigen internen Server auf Port 443 landet. Der HAProxy wählt dann das richtige LE-Zertifikat und alles ist gut.

Wenn man das gleiche aber von einem internen Client im gleichen Subnetz versucht, bekommt man das LE-Zertifikat nicht, da der Traffic ja auch nicht über die OPNSense muss sondern ein direkter Zugriff über den nächsten Switch möglich ist.

Daher habe ich mir bisher immer so geholfen, dass ich die LE-Zertifikate von der OPNSense zusätzlich auf die einzelen Server kopiert habe, so dass dieses Problem auch beim internen Zugriff nicht mehr auftaucht.
Was mir aber nicht ganz klar ist: Ist das überhaupt sinnvoll so oder geht das auch eleganter/anders? Kann man also auf das Kopieren verzichten, wenn es anders macht? Oder ist das bei diesem Setup unvermeidlich?

Ich frage das auch deshalb, weil zunehmend docker-Container zum Einsatz kommen und es da manchmal nicht so einfach zu entscheiden ist, wie/wo man das LE-Zertifikat ablegen muss, damit der Zugriff auf Port 443 auch intern über https:// funktioniert...

Danke jedenfalls für einen guten Tipp.
#8
Hallo.
Leider ist bei uns das OPNSense-Update von Version 24.7.2 auf  24.7.11 schief gegangen. Das Update ist über angeblich fehlenden Config-Files gestolpert und ist letztlich hängengeblieben

Letztlich haben wir das System neu aufgesetzt und anschließend ein Backup der Konfiguration eingespielt. Das hat zwar funktioniert, doch leider waren die Konfigurations-Files vom AdGuardHome nicht dabei.
Ist das ein bekannter Fehler?
Es war auch so, dass die Erweiterung für das AdGuard-Paket (selbst hinzugefügt) offenbar nicht mit im Backup gespeichert wurde, so dass ich sie neu manuell hinzufügen musste.

Das sollte eigentlich so nicht sein, oder?

#9
German - Deutsch / caddy vs. nginx als reverse-Proxy
December 11, 2024, 08:48:15 PM
Hallo.
Ich habe zufällig dieses Video gefunden und wüsste gerne, ob das os-caddy-Plugin direkt auf der OPNSense in größeren Umgebungen mithalten kann? Weiß jemand genaueres? Danke.
https://www.youtube.com/watch?v=N5PAU-vYrN8
#10
Hallo.
Wir haben hier immer wieder Probleme mit Geräten im WLAN (iPads), die von unserem MDM Befehle annehmen sollen. Scheinbar kommen diese Änderungen nicht immer zuverlässig genug bei allen Geräten an!?

Ich habe mir daher nochmal diese Seite angesehen:
https://support.apple.com/de-de/guide/deployment/dep2de55389a/web
Es ist also so, dass alle Geräte im WLAN Kontakt über Port 5223 zu Apple aufbauen können müssen:
"Durch die Verwendung von APNs werden Apple-Geräte über Aktualisierungen, MDM-Richtlinien und eingehende Nachrichten informiert."

Bei uns sieht die Regel für die Portweiterleitung so aus (s. Attachment). Ist das so richtig? Oder ist diese Regel überflüssig?
Was seltsam an der Sache ist: viele Clients im WLAN bekommen eine Änderung durch das MDM direkt mit ... aber es gibt immer wieder einzelne Geräte, die entweder gar nicht oder erst sehr viel später reagieren, wenn eine Aktion vom MDM ausgelöst wird.
Daher dachte ich, dass evtl die Einstellungen zum Port 5223 nicht ganz korrekt sind? Wie seht ihr das?
#11
Hallo.
Wir haben hier ein merkwürdiges Routing-Problem. Im WLAN (Unifi Accesspoints, falls das relevant ist...) sind hier vormittags viele Geräte vorhanden.
Manche davon finden einen Rechner, der bei uns intern läuft und auf dem sich das MDM für die Geräte befindet aber nicht 100%ig zuverlässig sondern es gibt immer wieder Geräte mit Verbindungsproblemen.

Ich habe auf zwei iPads die App "Network Utils" verwendet, um mir das Tracerouting anzusehen. Auf einem Gerät, das alles richtig macht, läuft das so:
IP-Adresse des Gerätes (172.16.1.xy) -> OPNSense-Firewall (172.16.16.254) -> MDM (in der DMZ) unter 172.17.17.xy
Diese Route ist korrekt und es funktioniert so wie es sein soll.

Auf dem Gerät, das es falsch macht, sieht das aber so aus:
IP-Adresse des Gerätes (172.16.1.xy) -> Adresse im Internet (also nach draußen geroutet, obwohl es hier intern läuft)

Ich weiß leider nicht, warum das auf einigen Geräten manchmal so auftritt und wonach ich hier schauen soll?!? Als DNS-Server haben wir in dem WLAN für die Geräte ein Pi-Hole laufen, das wiederum die IP-Adresse des MDM-Servers richtig auflöst (das klappt auch auf allen Geräten korrekt!).
Aber die Route ist offenbar trotzdem manchmal falsch. Auf beiden iPads ist das gleiche Standard-Gateway und auch der gleiche DNS-Server eingetragen. Daher meine Frage, wo ich auf der OPNSense nachschauen soll, um das Problem eingrenzen zu können. Hat jemand einen guten Tipp für mich? Danke!

#12
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).)





#13
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.
;)


#14
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?


#15
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.


#16
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.
#17
Hallo.
Ich habe bei uns (OPNSense 24.1.2_1-amd64) unter
Berichterstattung -> Unbound DNS gesehen, dass als "Top passed Domain" einfach nur "to." gelistet wird.
Was hat es damit auf sich?

Wenn man einen Client anklickt steht da auch nur sowas wie:

mein-client A to. Pass Cache NOERROR 0ms 1407

Diese Einträge wiederholen sich oft. Wer hat eine gute Erklärung?
#18
Hallo.
Wir lassen unsere OPNSense die LE-Zertifikate erstellen und kopieren diese dann per ssh an die Stellen, wo wir sie zusätzlich benötigen. Nun hat sich scheinbar kürzlich etwas an den Pfaden auf der OPNSense geändert, denn die Zertifikate liegen nun z.B. unter
/var/etc/acme-client/cert-home/5dd6479883d14.23163922/$hosts

Was hat es mit der neuen Bezeichnung (insbesondere dieser neu eingeführten "ID") auf sich?
Bleiben diese "IDs" (oder sind das Zeitstempel??) bei der nächsten Erneuerung der Zertifikate erhalten oder werden die bei jeder Erneuerung der Zertifikate neu vergeben??

Ich frage deshalb, weil durch die Änderung der Pfade auf der OPNSense nun auch die selbst geschriebenen Scripte geändert werden müssen. Wenn ich die neuen Pfade nur einmalig ändern muss, wäre das nicht so dramatisch -- aber wenn sich das jedes Mal ändert schon ... wer weiß Rat? Danke!
#19
Hallo.
Wenn ich auf einem Client in unserer DMZ diesen Befehl verwende:

ntpdate -d time-1.rz.uni-duesseldorf.de

erhalte ich:

18 Jan 12:16:21 ntpdate[307681]: no server suitable for synchronization found

In der OPNSense-Firewall steht dann sowas wie:

Blocked:
DMZ  -> 172.17.17.199:56501 134.60.1.27:123 udp Default deny / state violation rule

Das verstehe ich nicht ganz: Offenbar geht die Anfrage raus aber kommt nicht zurück -- dennoch steht bei Direction "IN" ...
Mit anderen Worten: Muss da eine Extra-FW-Regel her? Ich habe es gerade versucht aber ich sehe gerade den Wald vor lauter Bäumen nicht, wie die auszusehen hat!?
Danke für einen Wink mit dem Zaunpfahl!
#20
Hallo.
Wir haben haben nun zum zweiten Mal folgendes im OPNSense-WebUI beobachtet. Die Werte unter
"Fehler eingehend/ausgehend" zeigten Werte, die ziemlich ziemlich ziemlich hoch waren (s. Attachment).
Beim ersten Mal habe ich einfach einen Neustart der OPNSense gemacht und mir "nichts weiter" dabei gedacht, aber da das ganze gerade zum zweiten Mal aufgetreten ist, wundere ich nun doch, was das ist bzw wodurch das ausgelöst wird?
Natürlich liegt nahe: Defektes Netzwerkgerät -- aber warum taucht das dann nicht *immer* auf??
Ich wüsste gerne, wie man das debuggen kann. Danke für einen guten Tipp.