Messages

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.

So, ich konnte testen, leider nicht vor Ort, sodass das Konstrukt erstmal wieder auf den funktionierenden Stand gebracht wurde.

Ich habe die LAN default Rules auf Source "Any" gestellt. Die Pakete aus den 0, 1, 2er Netz werden nun durchgelassen - yay, erstmal teilerfolg! Jetzt komme ich dennoch nicht raus ins Internet. Ggf. habe ich damals beim Routing verkackt. Das schaue ich mir am Montag noch einmal an. Ich meine aber, dass ich routen gesetzt habe.

Ein Gateway dürfte von mir auch vorhanden sein mit der IP Adresse vom Switch um 198er Netz, worauf das GW der Route gesetzt ist. Das fuchst mich jetzt, dass ich erst am Montag wieder dran komme...

Ich meine sowas gemacht zu haben, ist bereits ein paar Wochen her, als der Versuch gemacht wurde.

Ich prüfe das morgen noch einmal.

Guten Morgen in die Runde, mein erster Beitrag hier mit Hoffnung auf etwas Hirnschmalz aus der Community :)

Ich setze bei Kunden seit einem Jahr OpnSense ein, i.d.R. mit klassischen LANs dahinter, /24, /22, keine VLANs.
Jetzt habe ich einen Kunden, wo der Vorgänger mit VLANs gearbeitet hat. Es kommen Aruba Switches zum Einsatz, wo die VLANs 10, 20, 30 vorhanden sind. Das Routing übernehmen die Switches. Das GW für die Clients im Netz ist 192.168.0.254/24

Die Uplinks sind entsprechend getagged. Alles an Datenverkehr wandert zum Switch im EDV-Raum (0.254/24) auf einen Port, welcher untagged ist. Dort hängt in einem eingenen Subnetz aktuell noch eine Fli4l, die weichen soll.

Der Aufbau sieht so aus:

      Telekom Glas
            :
            :
            :
      .-----+-----.
      |  Gateway  |  Fibertwist
      '-----+-----'
            |
        WAN
            |
    .-----+------.   
    |    Fli4l      | -> wird durch OpnSense ersetzt
    '-----+------'
            |
     LAN | 198.51.100.254/24
            |
       | 198.51.100.1/24
       | untagged Port
      .-----+------.
      | LAN-Switch |  EDV-Raum
      '-----+------'
       |      |      |         Tagged Ports /
       |      |      |         Routing über Switch
      V10  V20 V30
    ...-----+------... (Clients/Servers)


Die Sense ist konfiguriert:

WAN  PPPoE für Telekom Glas, VLAN7
LAN   198.51.100.254
FW LAN - default, keine weiteren Regeln

Zum ersten Test liegt mein Notebook im Netz 198.51.100.0/24. Internetverbindung steht, ich komme mit meinem Notebook raus ins Internet - Check...

Problem:

Jedes Datenpaket, was nun von den Subnetzen der VLANs über den untagged Port des EDV Raum Switches kommt, kommt an der Sense an, wird aber von der FW LANseitig geblockt mit der default deny rule. Ich sehe, aus welchem Subnetz die Pakete kommen, kein VLAN Tag oder sonst was.

ein Ping aus den Subnetzen zur Sense wird mit Timeout quittiert. Die ICMP Echos sehe ich auch in der Firewall geblockt. Ein Ping aus dem Netz, wo die Sense sitzen soll in die VLANs funktioniert.

Ich stehe auf dem Schlauch und bräuchte einen Gedankenanstoß. Ich freue mich auf Rückmeldungen :)

Gruß
Chris