Messages

[eigentlich]

Hi.

Wenn Du mit HAproxy als Reverse Proxy arbeitest, macht der doch die TLS-Terminierung inkl. der Beantragung der ACME-Zertifikate?

Ja, das macht der HAProxy auch -- und eigentlich funktioniert das auch. Allerdings haben wir hier zusätzlich auf dem unbound diverse Domain-/IP-Überschreibungen. Wenn ich mich richtig erinnere, hat das immer wieder Ärger gemacht, wenn dann das Zertifiktat nicht direkt auf dem Host war. Für die DMZ bin ich mir da gerade nicht sicher aber bei anderen Servern (einer davon ist nochmal wie weiter oben schon vermutet hinter einem Router), musste ich das Zertifikat dann leider immer lokal übertragen. Wie gesagt: Es ist sehr gut möglich, dass das viel eleganter geht.
In diesem Fall war es auch so, dass sich der Webserver nicht so pingelig angestellt hat wie openssl/curl.


Diese Seite hat mir übrigens weitergeholfen ... vielleicht auch für andere hilfreich:
https://linuxconfig.org/testing-https-client-using-openssl-to-simulate-a-server

Hallo.
Danke für die Tipps. Ich wollte eigentlich schon länger auf caddy als reverse Proxy wechseln -- komme aber im Moment nicht dazu. HAProxy finde ich (leider) recht unübersichtlich. Aber das eigentliche Problem steckte hier tatsächlich in dem verwendeten Zertifikat auf dem Server. Da es sich dort um zwei Installationen (LXC- bzw docker) handelte, war die Einstellung ziemlich versteckt. Ich musste den Containern beibrigen, dass sie die fullchain.cer nehmen sollen. Seitdem hat curl funktioniert und die Verbindung kam zustande.
Dennoch danke für's Mitdenken.

[fullchain]

Hallo.
Ich habe eine Frage zum Herunterladen und Weiterleiten von Let's Encrypt Zertifikaten.
Es ist so, dass bei uns die OPNSense zusammen mit HAProxy als reverse Proxy dient. Der ACME-Client erneuert für unterschiedliche Server die LE-Zertifikate regelmäßig direkt auf der OPNSense. Bis dahin alles kein Problem.
Wenn ich von außen etwas versuche wie

Code Select Expand

openssl s_client -connect mein-server.meine-domain.de:443
erhalte ich die vollständige Zertifikateskette

Code Select Expand

depth=3 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=2 C = US, O = ISRG, CN = Root YR
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = YR1
verify return:1
depth=0 CN = mein-server.meine-domain.de
verify return:1
---
Nun ist es aber so, dass ich diese Zertifikate auch herunterlade (und zwar: firewall:/var/etc/acme-client/cert-home/$id/$hosts/fullchain.cer !!) und lokal direkt auf die Server verteile, damit man auch lokal bzw im Intranet damit arbeiten kann. Wenn ich das mache, ist die "Chain of Trust" plötzlich kürzer und besteht nur noch
aus

Code Select Expand

Certificate chain
 0
und nicht mehr aus

Code Select Expand

0
1
2
Ich kenne mich nicht gut genug aus, um sagen zu können, was da genau fehlt, aber nach allem, was ich gelesen habe, scheint es so zu sein, dass in dem Fall, dass ich aus dem Intranet den Befehl

Code Select Expand

openssl s_client -connect mein-server.meine-domain.de:443
verwende, nicht die fullchain.cer/pem verwendet wird, sondern dass in diesem Fall (warum?) das Intermediate-Zertifikat fehlt? Stimmt das so?
Meine Frage ist natürlich, warum und wie man das verhindern kann?

(Der Hintergrund der Frage ist eigentlich ein völlig anderer: Ich wollte einen LXC-Container unter Proxmox installieren, der immer merkwürdige Fehler ausgespuckt hat. Dort funktioniert auf der Shell aber schon ein einfaches "curl https://..." nicht
("curl: (60) SSL certificate problem: unable to get local issuer certificate"))

Wie kann man das Problem lösen? Die ACME-Zertifikate werden auf alle genau gleich erstellt. (Challenge Typ http-01)
Danke für einen guten Tipp.

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