OPNsense VLAN vergibt keine DHCP IP

Hallo,

Hast Du eingehend DHCP Port 67 und 68 UDP/TCP freigegeben? Standard bei der OPNSense ist eingehend blocken.

Grüße

lcer

Moin,

in welchem Netzwerk läuft denn der AP?
Ist das unter "Networks" entsprechend konfiguriert?

Ausserdem solltest Du mal auf die letzte Version von Unifi wechseln.....

Frage zur Cisco-Konfig: Wieso sind alle Ports auf dem Switch als "Trunk" eingetragen?

Gruß

Looser

Hallo,

Nochmal: passen die Firewallregeln der OPNSense? Du hast so viele Screenshots gepostet, aber die noch nicht.

Grüße

lcer

Läuft Deine OPNSense als VM? (Gerade erst gesehen) Prüfe mal die Einstellungen für die VM. Diese muss auch in beiden VLAN hängen!


Um einen Client über einen AP in ein anderes VLAN zu schieben, brauchst Du (vorrausgesetzt es ist korrekt konfiguriert) keine Firewallregeln.

Hallo,
DHCP-Server ist die OPNSense, Der Client zieht keine IPs - Natürlich braucht man da Firewallregeln.

Grüße

lcer

Nope. Ist bei mir auf der pfSense ohne Firewall Regeln konfiguriert. Ebenso im Büro auf der UTM 300.

Nun, beides ist keine OPNSense.

Also bei mir habe ich auf der OPNsense nur das DHCP-Relay aktiviert. Dabei sind manuelle Firewallregeln erforderlich, sonst werden die tatsächlich geblockt. Automatische DHCP-Regeln sind nicht eingerichtet. Ob das beim "richtigen" DHCP-Server anders ist, kann ich gerade nicht testen.

Grüße

lcer

Zumindest bei der pfSense ist es so. Der eigene Onboard DHCP Server funktioniert immer auch ohne zusätzliche Regeln am Interface. Das mag aber natürlich bei OPNsense anders sein ?!
Sehr wahrscheinlich ist der Fehler aber das falsche oder fehlende VLAN 10 Tag Handling auf dem internen vSwitch des Hypervisors. Die getaggten VLAN 10 Pakete kommen nicht durch den vSwitch und damit dann auch nicht aus der physischen NIC zum physischen Switch.
Ein einfacher Wireshark Trace hätte das dem TO auf Anhieb ohne lange Rumeierei auch gezeigt ob das VLAN 10 Tag vorhanden ist oder nicht und ob dort überhaupt VLAN 10 getaggte Frames an dem Port auftauchen.
(Wireshark Beispiel hier mit der VLAN Tag ID 14 statt 10)

Im folgenden Thread sieht man einmal am Beispiel von VmWare was dabei im vSwitch Setup zu beachten ist:
Sophos Software Appliance UTM - VLAN - CISCO SG Series Switches

Eine kluge Entscheidung will man sich nicht einen Wolf suchen. Das ist leider nicht der einzige Bug oder ungewöhnlicxhes Verhalten was OPNsense hat. In puncto Betriebssicherheit und Stabilität ist bei denen noch Luft nach oben.

Das kann sein und ist vermutlich auch der Fall.
Das liegt daran das du sehr wahrscheinlich deine LAN Netzwerkkarte nicht so eingestellt hast das sie VLAN Tags anzeigt bzw. an den Wireshark weiterreicht !
Das ist bei den verschiedenen Netzwerkkarten Chipsätzen auch leider sehr unterschiedlich. In der Wireshark Knowledgebase gibt es diverse Einträge dazu:
https://wiki.wireshark.org/CaptureSetup/VLAN#Windows
Bei Intel basierten Karten muss man etwas in der Registry fummeln das es klappt:
https://www.intel.com/content/www/us/en/support/articles/000005498/netwo ...
Vermutlich hast du das vergessen zu aktivieren.
Ein VLAN Capture sollte dann so aussehen. Hier mit VLAN ID 14:

Nur nochmal zur Klarstellung das du auch keinen Mist misst oben....
Wenn du einen untagged Wireshark Client an einen Firewall Tag Port klemmst dann wirst du VLAN Tags nur dann sehen wenn die Firewall selber Frames aussendet. Dein UNtagged Client kann ja niemals auf Tagged Frames antworten.
Du kannst provozieren das die Firewall etwas auf den getaggten VLANs sendet indem du im "Diagnostics" Menü den Punkt "Ping" klickst und dort einen Ping z.B. auf irgendeine IP in dem VLAN sendest. Wichtig ist das du die Absender IP auf eines der VLAN Interfaces setzt !
Dann solltest du ICMP Echo Request Paket an dem Port mit entsprechendem VLAN Tag sehen sofern dein Rechner richtig customized ist das er diese auch anzeigt. Siehe oben !
Wenn du einen managebaren Switch am Firewall Port hast kannst du dort auch einen Mirror (Spiegel) Port einrichten und den Tagged Switchport an dem die Firewall angeschlossen ist spiegeln.
Das Auswerten des 802.1q Tags am Woireshark Rechner musst du aber natürlich trotzdem machen, denn der Siwtch Mirrorport reicht die Tags ja weiter.

Das oben die ARP Frames nicht beantwortet werden ist komisch. Das darf nicht sein, denn die sind rein Layer 2 und filtert auch keine Firewall.
Das ist eher ein Indiz dafür das du falsch snifferst und (untagged) im falschen VLAN hängst was eigentlich Tags erwartet.
Das ist sehr wahrscheinlich ein UNtagged ARP Request deines Wireshark Rechners der nach der Mac Adresse der Firewall .10.1 fragt.
Der Frame kommt vermutlich niemals bei der Firewall an, weil die diesen ARP Frame mit einem VLAN 10 Tag erwartet um ihm dem VLAN 10 Interface zuordnen zu können. Folglich antwortet sie nicht bzw. kann gar nicht antworten weil sie den Frame ohne den VLAN Tag gar nicht "sieht".
UNgetaggte Frames gehen normal immer per Default nur auf das physische Interface (Parent). Wenn du dort keine IP Adresse gesetzt hast und nur mit getaggten VLANs Interfaces dort arbeitest, werden UNgetaggte Frames an der Firewall generell verworfen ! Klar, denn sie kann dann diese Frames keinem Interface zuordnen.
Es macht also auch immer Sinn dem Parent Interface eine IP zu setzen. Zumindestens fürs Testen des richtigen Taggings.

Ob dein Sniffer VLAN Tags anzeigt oder auch nicht kannst du auch ganz einfach nur mit deinem VLAN Switch checken.
Generiere dir einfach ein Test VLAN z.B. 99 da drauf und ordne dem einen Tagged und einen UNtagged Port zu.
Den UNtagged Port steckst du in dein bestehendes Heimnetz und am Tagged Port misst du mit dem Wireshark.
Den gesamten Broad- und Multicast Traffic deines Heimnetzes muss der Switch dann auch auf den Tagged Port fluten und dort kannst du dann alle diese Broad- und Multicast Pakete des Heimnetzes immer mit einem VLAN 99 Tag sehen.
Wird der Tag nicht angezeigt, dann ist dein Wireshark Rechner bzw. seine Karte nicht richtig customized zur Anzeige des VLAN Tags. (Siehe oben)