Messages

[laufende]

Was bei Dir offenbar schiefgeht, ist, dass dass "Native VLAN/Network" auf "None" steht - somit wird der untagged traffic gar nicht durchgelassen. Du müsstest das auf "Default" stellen, damit der Verkehr von ax0 durchkommt.

Danke für die Erklärung. Also im Moment funktioniert es schon ... ich habe nicht die laufende Konfiguration des Unifi-Switches sondern die geplante Konfig geschickt. Im Moment ist es so eingestellt wie von Dir beschrieben: VLAN1 ist untagged und alles andere kommt tagged mit. Wenn nur die falsche Statistik auf der OPNSense ein Problem ist, kann ich es vielleicht ja doch so lassen wie es ist (Stichwort "Never touch a running system!")?? Falls es mit diesem Aufbau aber noch weitere Probleme auf der OPNSense gibt (???), wäre eine Änderung vielleicht doch ganz gut?!

Wir sind irgendwann mal mit dem Management-Netz in das VLAN.1 umgezogen. Vermutlich war der Grund genau wie von Dir beschriben: "Nur" da wurden die Accesspoints ohne größere Klimmzüge sofort gefunden?!?

Oder wenn man einen Port an der Sense frei hat, dann steckt man da das VLAN1 untagged vom Switch rein. Mache ich hier im Büro.

Das geht hier leider nicht, da sich zwischen dem Unifi-Switch und der OPNSense 6 Etagen befinden und "nur" eine 10GBit-Glasfaser-Leitung als direkte Verbindung zwischen den beiden zur Verfügung steht.

-deleted-

[beiden]

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:

Code Select Expand

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

Code Select Expand

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 

Code Select Expand

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.

[wo]

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.

Noch etwas zur Migration ... mein Kollege hat dieses Script erfolgreich auf einem Testsystem verwendet:
https://github.com/EasyG0ing1/Migration

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.

[automatisch]

Leider noch nicht ganz gelöst, da das Portal auch weiterhin nicht automatisch geladen wird, sobald man sich mit dem entsprechenden WiFi verbindet ...

Ich habe nochmal nachgelegt:
https://github.com/opnsense/core/issues/8695

Das ging ja schnell ... der neue Patch ist jetzt da!

Ok ... mal sehen, was daraus wird:
https://github.com/opnsense/core/issues/8689

[Source]

Hallo, die dritte.
Mich wundert, dass das Problem scheinbar sonst niemand hat? Hier ist es definitiv so, dass die Regeln, die laut neuer Doku
https://docs.opnsense.org/manual/captiveportal.html#redirect-traffic-to-the-zone-webserver
im Portforwarding entweder auftauchen oder aber neu selbst erstellt werden sollen, nicht vorhanden sind und auch nachträglich nicht angelegt werden können. Es bleibt leider dabei, dass unter Source das automatisch erzeugte Alias

Code Select Expand

__captiveportal_zone_0 gar nicht erscheint und demnach auch nicht ausgewählt werden kann.
Kann das Problem jemand bestätigen? Danke!

Mittlerweile ist die neue Doku da:
https://docs.opnsense.org/manual/captiveportal.html#redirect-traffic-to-the-zone-webserver

Die automatischen Regeln sind bei uns vorhanden und

Code Select Expand

__captiveportal_zone_0 ist ebenfalls da.
You cannot view this attachment.
Diese Regeln sollen laut Anleitung neu angelegt werden. Wenn man das macht (Firewall -> Regeln -> + ) erscheint unter Quelle das Alias für die Captive-Portal-Zone leider nicht. Das gilt aber auch für alle anderen automatisch angelegten Aliase.

Daher nochmal die Frage, wie man hier weiter vorgehen soll oder ob das weiterhin ein kleiner Fehler ist?
(Auf einem 2. Testsytem haben wir das ebenfalls genauso beobachtet.)

[nicht]

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

Code Select Expand

[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

Code Select Expand

[x] Disable firewall rules ist man sofort online -- allerdings erscheint das Captive Portal nicht!

Wenn man den Haken allerdings nicht setzt

Code Select Expand

[ ] 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:

Update: 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.

Hi.
We installed the patch 09324af (https://github.com/opnsense/core/commit/09324af15d14d58c0937d74d26d451db673c3468) to fix the problem.
Now there ist the option under "Captive Portal -> Settings"

Code Select Expand

[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.

But it still does not work: If activated everyone is online and the captive portal does not appear
If not activated: Not online

So: What else to do in this case?
Thanks.

... we have the same issue here with OPNsense 25.1.5_5-amd64

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

Code Select Expand

/usr/local/etc/crowdsec/parsers/s02-enrich
existiert bereits eine Datei

Code Select Expand

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.