Zwei Baustellen ISC->KEA / old FW Rules versus new

[0zzy]

Moin zusammen,
also es ist völlig egal was ich anstelle ich bekomme es nicht gebacken.

Zur Migration von ISC -> KEA (aktuell nur v4) habe ich das Tool aus dem Forum hier genommen (https://github.com/EasyG0ing1/Migration).

Das funktioniert soweit auch.

Soweit so gut.

Nun deaktiviere ich jegliches DHCP auf ISC (vorher dafür gesorgt das ich mich nicht aussperre ;)) und aktivere KEA.

Das läuft soweit teilweise, als dass ich auf konfigurierten VLANs nur noch eine APIPA bekomme. Lediglich mein LAN welches ich statisch konfigiert habe leistet noch seine Arbeit.


Wenn ich nun noch den EX- Import für die neuen FW Regeln mache geht garnichts mehr.


Wo ist mein Denkfehler bzw. was muss ich tun um das mit den aktuellen Möglichkeiten wieder ans fliegen zu bekommen?

[Patrick M. Hausen]

Das Tool migriert ja nur deine statischen Mappings. Hast du denn die Subnetze und die Bereiche in Kea alle manuell angelegt? Ohne die gehts nicht :-)

[Tuxtom007]

Du solltest erst mal die Subnetz anlegen.

Die DHCP-Reservations hab ich mir exportiert in eine CSV, nachbearbeitet und dann in KEA importiert, das lief problemlos.
Gestern hab ich ISC komplett rausgeworfen über die AddOns, was praktischerweise ja nun möglich ist.


Die neuen FW-Rules sind mir derzeit noch nicht so klar, muss ich mich noch informieren, vor allen was der Migrations-Assistent  überhaupt macht

[0zzy]

Ja ich vergas zu erwähnen: natürlich hab ich die Subnetze erst in KEA angelegt :)

[viragomann]

Vergiss auch nicht, alle benötigten Interfaces am Settings Tab zu aktivieren.

[0zzy]

Hab ich auch:
General Settings -> Interfaces alle bisherigen drin.

[viragomann]

Also mir fallen nur 4 Einstellungen ein, die nötig sind, um KEA zum Arbeiten zu bewegen:
- Settings > enabled - anhaken
- Settings > Interfaces - die gewünschten auswählen
- Settings > Firewall rules - anhaken
- Subnets > die entsprechenden Subnets mit den passenden Pools hinzufügen

Versichere dich auch, dass ISC auf allen Interfaces deaktiviert ist.

Wenn du damit keine IP bekommst, mach mal ein Packet Capture auf einem betroffenen Interface mit Portfilter "67". Das soll zeigen, ob vom Client überhaupt eine Anfrage kommt, und wenn, ob KEA auch antwortet.
Ist damit nichts zu sehen, besteht wohl ein Problem in der Netzwerkkonfiguration.

[Swtrse]

Bei mir war es so, dass KEA nicht laufen wollte, solange ISC auch nur auf einer Schnittstelle gelaufen ist.
Ich musste ISC wirklich komplett abdrehen, damit KEA angefangen hat, zu arbeiten.

Das hat meinen Plan, Schnittstelle für Schnittstelle langsam umzustellen, schön durcheinandergebracht ...

[Patrick M. Hausen]

Bei mir war es so, dass KEA nicht laufen wollte, solange ISC auch nur auf einer Schnittstelle gelaufen ist.
Ich musste ISC wirklich komplett abdrehen, damit KEA angefangen hat, zu arbeiten.

Das ist so. ISC bindet an alle Interfaces, selbst wenn er nur an einem aktiv ist.

[Tuxtom007]

Das ist so. ISC bindet an alle Interfaces, selbst wenn er nur an einem aktiv ist.

Die Erfahrung hab ich damals auch gemacht, weil ich den schrittweise umziehen wollte - hatte sich damit erledigt.
KEA läuft super bei mir, daher war der Umstieg das beste was ich machen konnte.

ISC hab ich komplette deinstalliert.

Gestern abend hab ich auch auf die neuen FW-Rules umgestellt, gingt auch recht entspannt in wenigen Minuten

[0zzy]

Oh das ist zum Mäusemelken....

Was ich hin bekomme:
Firewall von alt zu new --> check
isc -> kea check

Alles funktioniert bis auf der AP. Leckofatzi!

Lustigerweise habe ich alles ex und wieder importiert, danach kommt etwas lustiges zustande:

Ich bekomme an WIFI Clients ein lease -> yiaaay
Aber im unifi-control server und via ping keine Verbindung zum UFO U6+

Setze ich alles per snapshot zurück funktioniert alles wie gewohnt.

Der unterschied:

ISC einmal WIFIMGMT auf opt 1 GW: 192.168.12.252/29 AP hat die IP 192.168.12.2
ISC WIFI vlan0.20 GW: 192.168.13.252/24 -> da bekommen die clients dann wifi

In Kea alles händisch eingetragen, rein ne va plus!

Nach Recherche brauche ich wohl die Möglichkeit die option 43 zu vergeben weil der AP sonst blind ist.
Ich hab es per Unbound DNS override probiert, nope will einfach nicht.

Ich gebs für heute auf... Ratschläge / Erklärung sehr willkommen.

[Tuxtom007]

Firewall von alt zu new --> check

Mit der neuen Ansicht muss man sich erst mal anfreunden.


Wegen der DHCP-Option, schau mal hier in den Thread:
https://forum.opnsense.org/index.php?topic=40080.0

[0zzy]

die Ansicht bereitet mir, aufgrund der Logik dahinter weitaus weniger Kopfschmerzen als die art und weise (sehr strict) die Kea verfolgt.
Ich denke ich muss mir mal in ruhe anlesen wie genau KEAs Logik funktioniert (denn am ende des Tages geht es nur darum).

Wie gesagt was ich nicht ganz verstehe:

Im Endeffekt ist das alles ein Routing Thema,
Wenn man irgendein interface als MGMT interface nutzt welches mit einem VLAN Interface kommuniziert muss man dafür sorgen das beide sich "sehen" also kommunizieren können.

Wo ich mit meiner Menschlichen Logik nicht hinterherkomme ist das genannte Szenario.

MGMT (physical) interface und ein VLAN Interface kommunizieren bereits, die Clients des VLAN Interface bekommen per DHCP ihr lease.

Aber und obwohl (mehrfach kontrolliert) jedes Interface sein eigenes oder das der OPNSense als Gateway definiert hat, können trotz entsprechenden Regeln, ein anderes VLAN Interface welches für den Unifi-Server genutzt wird, nicht kommunizieren.

Der Weg einfach erklärt ist hier in meinem Verständnis:

WIFI MGMT teilt dem UNIFI-Controller in VLAN X mit das in VLAN Y ein UFO hängt.


Das funktionierte bisher mit ISC auch, soweit ich das aber nachvollziehen kann war ISC nicht so strikt und hat gern mit Broadcast abfragen gearbeitet, welche auch wiederum bösartige Ausnutzung ermöglicht.

KEA ist dort strikter und kommuniziert nur wenn man mitteilt wie der weg funktioniert.

Demnach muss man den Rout(ing)enplaner bereits vorab eingestellt haben, sonst schreit KEA halt: " ey wat du wolle, ich nix verstehe!".


Sollte meine Logik hier hinken o.ä. immer her mit Konstruktiver Kritik.

[nero355]

WIFI MGMT teilt dem UNIFI-Controller in VLAN X mit das in VLAN Y ein UFO hängt.

Konstruktiver Kritik.

Since your titel contains English and my German "sehr slecht ist" despite the fact that I am "your friendly Niederlandische nachbarn" let me explain what you should do or should have done :

Your UniFi UAP needs to be connected to a Switch Port that has :
- PoE+/PoE Enabled ofcourse.
- Native/Untagged VLAN 1.
- Tagged VLAN for the actual WiFi. Let's say 10 for now.

Your UniFi Controller should :
- Be active in VLAN 1.
For the sake of simplicity you could use the Default LAN Network in OPNsense for this.
- Tell your UAP that it's WiFi SSID is Tagged with VLAN 10.
- Communicate with your UAP via the simple DNS A Record called 'unifi' that should point to the IP Address of the UniFi Controller.
You can do this either in DNSmasqd or Unbound depending on your setup.


To give you an example of what I have got running here :
- OPNsense as Router.
- UniFi Switches.
- UniFi In Wall Accesspoints.
- Intel Atom NUC running Debian and hosting the UniFi Controller.
- Pi-Hole + Unbound runnning on a Raspberry Pi 3B for all my DNS needs.
- All of this can be accessed via the OPNsense Default LAN 192.168.1.0/24 that I use as Management LAN.
- UniFi Controller IP Address : 192.168.1.2
- DNS A Record for 'unifi' points to 192.168.1.2
- All UniFi devices communicate this way with the UniFi Controller.
- WiFi SSID is part of the VLAN 10 Network and configured as Tagged VLAN 10 in the UniFi Controller.

And since I switched from the UniFi USG 3P Router to OPNsense the DHCP Option 43 thing is no longer in use because I can't be bothered to mess around with it a.k.a. pure lazyness !! ;)


Good luck!

[Patrick M. Hausen]

Ich verstehe beim besten Willen nicht, was du meinst. Der DHCP-Server teilt dem Client im Normalfall dessen Default-Gateway mit. Das tun Kea und ISC exakt gleich.

Interessant wäre daher, was mit den beiden DHCP Varianten dann beim Client ankommt. Also z.B. unter Windows "ipcomfig /all" oder Mac OS oder BSD  "ifconfig; netstat -rn", keine Ahnung, was Linux heute wieder genau benutzt 😬

Der DHCP Dienst beschickt ausschließlich die Clients mit Informationen, wie sie sich konfigurieren sollen. Mit dem weiteren Verhalten von OPNsense in Bezug auf Routing und Filtering hat er überhaupt nichts zu tun.