Messages

Kleines Update,

ich habe wieder eine Sense mit nicht startenden Adguard gehabt, diesmal vor Ort. Ich habe mir die config .yaml angeschaut und die Zeile mit der Version (bei mir Schema Version, ist die das?), wie oben geschrieben wurde, gefunden. Wenn ich sie entferne, läuft Adguard immer noch nicht. Ändere ich die Version von z.b. 34 auf 31, startet Adguard wieder. Ich habe die Versionsnummern mit anderen Sensen verglichen. Nachdem Adguard wieder lief, konnte ich nochmals das Update auf die 107.77 machen, seitdem geht das wieder.

Also sollte ich am Besten vor dem Update Adguard ausschalten, Unbound auf Port 53 setzen, updaten und das Ganze vice versa als kleiner Sicherheitsanker.

Im Log general finde ich nur die Einträge. In den anderen Logs taucht dazu nix auf, auch beim durchscrollen finde ich keinen Hinweis in die Richtung. Logt Adguard selbst nix? Ich finde in der Verzeichnisstruktur auch keine log davon.

Die Einträge seit gestern im Genral Log

2026-07-07T16:36:04
[47] Starting adguardhome.
2026-07-07T16:30:55
[48] Starting adguardhome.
2026-07-07T16:29:45
os-adguardhome-maxit-1.16: already unlocked

Edit: @Tuxtom
Verdammt, das schon was auf der 5353 ist, habe ich nicht im Kopf gehabt. Auch danke für die Info von dir.

ich habe dazu mal eine Sense genommen, wo ich Adguard nur deaktiviert hatte, ich habs eben aktiviert um Fehler im Log zu provozieren.... öhm Adguard läuft wieder? Das ist gruselig.

Moin in die Runde,

Ich habe um die 30 Sensen im Einsatz mit:

Unbound, lauscht auf 5353
Adguard Home, lauscht auf 53

Adguard ist bei mir der Upstream DNS für die Netzte dahinter, Unbound der Resolver fürs Adguard. Ich fahre alle paar Monate Updates bei den Sensen, mache vorher ein Backup, schaue, dass der Adguard aktuell ist.

Jetzt fliegen mir bei einem Teil der Sensen nach den Updates die Adguard Plugins um die Ohren, sie lassen sich nicht mehr starten. Bei einigen komme ich bim Kunden noch drauf, zwei Standorte musste ich vor Ort fixen, da - weil fehlendes DNS - diese offline waren. Dazu habe ich das Plugin runtergepfeffert und neu installiert/eingerichtet. Das ist natürlich mist und die Updateorgien sind dadurch nicht zuverlässig genug.

Wie handhabt Ihr das, wenn der Adguard ausfällt? Übersehe ich was? Kniffe? Ideen? Adguard über Board werfen?

Grüße
Chris

geht, Du arbeitest ja mit zwei Instanzen.
Eine für Road Warrior mit LDAP Auth und eine zweite für Site-Site.

kurz ausgrab:

nachdem ich keine Ahnung mehr habe, warum die Filterung der Gruppe nicht greift, habe ich am Ende, nach 4 Monaten sucherei, auf dem DC eine neue OU erstellt für die VPN User und diese dort reingepackt. Auf der Sense dann bei den Containern zur authentifizierung wird nun diese OU genutzt. Dann brauche ich hier keine Gruppe mehr, sondern VPN ist nur möglich für die, die in dieser OU drin sind.

So als Plan B geht das auch.

Von daher, erledigt

Ich habe meine Sensen auf Port z.B. 6666 gesetzt, http redirect ausgestellt und dem adguard bei der Einrichtung auch einen eigenen Port gegeben, z.B. 6667. Damit kann ich über https + port die Sense WebGui und http + port den adguard erreichen.

[einen einzigen User]

Moin in die Runde,

es geht noch einmal um meinen Sonderfall von Kunden... hier der Aufbau.

   Telekom Glas
            :
      .-----+-----.
      |  Gateway  |  Fibertwist
      '-----+-----'
            |
        WAN
            |
    .-----+------.   
    | Opnsense |  -> OpenVPN C-S 10.10.255.0/24 mit Remote User Auth und LDAP Backend
    '-----+------'
            | LAN 198.51.100.254/24
            |
            |
            |
            | LAN 198.51.100.1/24
    .-----+--------.
    | LAN-Switch |  EDV-Raum
    '-----+--------'
      |      |      |         
      |      |      |         
     V10  V20 V30
    ...-----+------... (SRV-DC / 192.168.0.1)

Nachdem er nun endlich online ist, geht es weiter mit den VPN Tunneln mit OpenVPN. Bzw. noch ein schritt vorher, die LDAP Anbindung.

Während bei meinen anderen Kunden das OpenVPN mit Remote User Auth und LDAP Backend sauber läuft, stellt sich hier ein Problem ein, welches mich mit Fragezeichen hier sitzen lässt.

Das AD ist mit Schema Server 2016, stammt im Ursprung von einem SBS2003 und wurde bis hier in immer weiter migriert. DC ist ein Server 2019.

---------------------------------------
LDAP Backend:

Type: LDAP
Hostname: 192.168.0.1 -> IP vom SRV-DC
Port: 389
Transport: TCP
Version: 3

Bind Credentials: CN vom User opnsense
Password: ****

Search Scope: Entire Subtree
Base DN: DC=Kunde,DC=local

Auth Containers: meine OUs, wo sich die User und Gruppen befinden
Extended Query: memberOf=CN=VPN-User,OU....

User Naming Attr.: sAMAccountName

Read Properties: Check
Synchronize Groups: Check
Constraint Groups: kein Check

Limit Groups: Nothing
Auto User Creation: kein Check
Match case insensitive: Check

---------------------------------------

Mit dem Tester kann ich mich im Normalfall mit einem der User authentifizieren, der in der AD-Gruppe VPN-User drin ist. Bei jedem meiner Kunden klappt das zuverlässig. Bei diesem Kunden hier kommt das kuriose: Ich kann einen einzigen User, der Mitglied in der Gruppe ist, erfolgreich authentifizieren, die anderen User, die in der Gruppe drin sind, aber nicht.

Meldung:

The following input errors were detected:

    Authentication failed.
    error: User DN not found

Nehme ich Extended Query memberOf raus, kann ich die anderen User auch erfolgreich authentifizieren. Das Problem ist dann aber, ich kann JEDEN User in der OU authentifizieren, nicht nur die, in der Gruppe VPN-User. Um das einzuschränken, nutze ich das Feld Extended Query mit memberOf=[DN der Gruppe VPN-User].

Ich dachte mir, dass evtl. die LDAP Verbindung nicht korrekt konfiguriert ist, ggf. falsche Container genutzt wurden oder sogar die Gruppe VPN-User einen weg hat.

Was habe ich bis dahin gemacht?
- Check der LDAP Anbindung -> funzt, keine Fehler im LOG, ohne memberOf Filterung kann ich jeden im Tester authentifizieren
- Den einzigen Benutzer, den ich anmelden kann mit memberOf Filterung getestet. User aus der Gruppe rausgenommen -> Auth geht nicht, Meldung: error: User DN not found -> korrekt, da User nicht mehr in der VPN-User Gruppe -> User wieder in die Gruppe rein -> Auth erfolgreich. Das gleiche mit anderen Usern versucht, kein Erfolg, es bleibt dabei, User DN not found
- Neue AD Usergruppe erstellt, LDAP Config angepasst, User in Gruppe rein -> lässt sich keiner authentifizieren
- Neuen User erstellt, diesen nur in die Gruppe VPN-User bzw. meine Testgruppe gepackt -> Auth nicht erfolgreich
- Den einzig funktionierenden User gegengeprüft auf Gruppenzugehörigkeit, Attribute, etc.
- Kopie vom funktionierenden User erstellt und getestet -> Auth nicht erfolgreich, wenn memberOf eingerichtet ist.
- Beim Tester geschaut, welche Gruppen aufgelistet werden, wo der User Mitglied ist -> sieht korrekt aus
- Neue Opnsense parallel aufgesetzt ohne Import der Config und getestet, das Ergebnis ist reproduzierbar

Kurios ist gestern Abend gewesen, dass ich auf einmal zwei weitere User erfolgreich authentifizieren konnte, ohne dass ich an der Config oder beim User was geändert habe.. Hä?. Diese User sind von den Gruppen her identisch mit dem einzig funktionierenden User und sitzen auch in der gleichen OU.

Aktuell sitze ich hier mit einem seriösen "WTF-Moment". Kann sich das jemand erklären?

Gruß
Chris

Moin,

ich habe das Update bei meiner Testsense durchgeführt, er geht von 23.7.12 auf 24.1_1 - alles klar :)
Dennoch hatte ich vorsichtshalber IPS ausgestellt.

Gruß
Chris

Hi Franco,

dann stimmte bei mir was nicht. Ich hatte das Update der Sense jetzt am Freitag, 09.02 gemacht. Ich beobachte das auf jeden Fall beim Update der nächsten Sense.

Gruß
Chris

Danke dir für die Info. Dann war ich wohl zu früh dran mit meinem ersten Update, denn meine Sense war mit GUI und Co tot. Ich mache dann noch einmal einen Test.

Moin in die Runde,

ich müsste meine Sensen langsam updaten und dies entsprechend planen.

Gibt es die Möglichkeit, das Update von der Version, der 23.7.12, direkt auf die 24.1.1 zu machen? Es geht mir um den bekannten Suricata 7 Bug. Mir bietet das Update über die GUI nur die Hauptversion 24.1 an.

Habs bis Dato immer remote durchgeführt. Alternativ muss ich dann halt die Dinger vor Ort in zwei Schritten updaten. Eine Sense war mir beim Update auf 24.1 schon lahm gelegt worden und der Standort war offline. Musste dann vor Ort per SSH einmal ran.

Grüße vom Chris

Was sagt das Log? Kernelpanic oder einen sauberen Reboot?

Welcher RAM ist verbaut? Ich hatte von Anfang an bei den Dingern mit Celeron 5105 Probleme mit RAM von Gskill. Getauscht gegen Crucial, Samsung, Kingston, seitdem läuft das Ding.

Update: gestern in Betrieb genommen und es läuft. Es lag tatsächlich an der Outbound NAT Regelung. Merci für die Tipps :)

Gruß

Heiliges NATting Batman!

https://forum.opnsense.org/index.php?topic=22934.0

man sollte auch wissen, wonach man sucht, ich bin eben durch Zufall drauf gestoßen und dies beschreibt auch meine Problematik.

Durch Krankheit im Dezember bin ich leider nicht dazu gekommen, weiter zu machen. Jetzt bin ich dem Thread nach meine Einstellungen durchgegangen und das deckt sich auch mit der Aussage von Hausen mit dem Outbound NAT.

Ggf. am Freitag kann ich die Sense noch mal beim Kunden ins Netz hängen. Bin gespannt.

Oh backe, danke für den Tipp. Bis dato habe ich Outbound hybrid nur im Einsatz, wo die Telefonie Probleme macht. Dort gibt es dann für die TK Anlage eine Outbound Regel. Muss prüfen, wie das bei meinem Problemkind konfiguriert ist.