Problem mit PacketFence: Kein Connect zwischen Switch und PacketFence, keine Switch-/Port-Zuordnung

Hallo zusammen,

ich habe ein Problem mit meiner PacketFence-Installation:
Die AD-Join funktioniert, und ich sehe die Clients im PacketFence-Interface, jedoch wird bei den Clients nicht angezeigt, an welchem Switch und Port sie angeschlossen sind. Es scheint keine Verbindung bzw. keine Kommunikation zwischen den Switches und PacketFence hinsichtlich der Switch-/Port-Informationen zu geben.

Meine Umgebung & Konfiguration:
Switch-Hardware: 2x Aruba Switch J9775A
Switch OS Version: ArubaOS 16.x (Release YA.16.11.0026)
Switch Group: erstellt und Switches eingebunden
Switch Group Mode: Production
RADIUS: Shared Secret korrekt hinterlegt
SNMP:
Version v2c
Community read: pf-monitor
Community write: pf-monitor
SNMP Host: 192.168.1.111 mit Community pf_monitor

SSH/CLI: aktiviert, Benutzer manager mit Passwort hinterlegt

Switch Config (Auszug):
snmp-server community "pf-monitor"
snmp-server community "pf_monitor" operator unrestricted
snmp-server host 192.168.1.111 community "pf_monitor"
snmp-server location "Werkstatt"
aaa authentication login privilege-mode
aaa authentication console login radius local
aaa authentication ssh login radius local
aaa authentication port-access eap-radius
aaa port-access authenticator active

PacketFence:
Switch Group und Switch korrekt angelegt
Connection Profile "8021x" erstellt
Dot1x recompute role from portal: aktiviert
Automatically register devices: aktiviert
Filter: Connection Type => Ethernet-Web-Auth

Profile aktiviert
Was funktioniert:

Clients werden nach AD-Join in PacketFence angezeigt
RADIUS Authentifizierung scheint grundsätzlich zu funktionieren
Was nicht funktioniert:
Keine Anzeige von Switch- und Portinformationen bei den Clients
Keine erkennbare Verbindung zwischen PacketFence und den Switches bezüglich Port-Status
Fragen:
Was könnte die Ursache dafür sein, dass die Switch- und Port-Informationen nicht in PacketFence auftauchen?
Welche Konfigurationsschritte sind für eine funktionierende Switch-Kommunikation (SNMP oder RADIUS CoA) mit PacketFence entscheidend?
Gibt es spezielle Debugging-Tools oder Logs, die ich prüfen sollte, um die Verbindung zu überprüfen?
Sind spezielle ACLs oder Firewall-Regeln notwendig, damit PacketFence die Switchdaten abfragen kann?

Ich freue mich über Tipps und Hinweise, danke schon mal!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 673807

Url: https://administrator.de/forum/packetfence-switch-port-kommunikation-673807.html

Ausgedruckt am: 18.07.2025 um 01:07 Uhr

5 Kommentare

Neuester Kommentar

Die Switch und Port Informationen werden per SNMP aus den jeweiligen Switches ausgelesen. Sehr wahrscheinlich stimmt also etwas mit dem SNMP Zugang nicht. (Wegen fehlernder Infos erstmal grob geraten)
Gibt es im Log des Switches (show logg) dort ggf. irgendwelche Hinweise zu einem gescheiterten SNMP Zugriff?? Das Switch Log wäre immer erste Anlaufstelle.

ACLs und Firewall Regeln wären natürlich dann wichtig, wenn dein Netzwerk überhaupt segmentiert ist und an den beteiligten Routern bzw. Firewalls die diese Netzsegmente routen es solche entsprechenden Regelwerke gibt. Leider machst du dazu keine zielführenden Angaben.
Diese müssten dann in Bezug auf SNMP und andere Managementprotokolle entsprechend angepasst werden damit z.B. SNMP ins Management Netz / Interfaces der Switches passieren darf. SNMP benutzt die Ports UDP 161 und 162.

Es wäre also sinnvoll wenn du einmal mit einem kleinen SNMP Test Tool grundsätzlich den SNMP Zugriff auf deine Switches mit deinem Community String überprüfst.
Solltest du einen unixoiden Server (VM, Raspberry, usw.) im Netz haben und die net-snmp Tools dort installiert haben kannst du mit einem...

snmpwalk -v 2c -c pf-monitor 192.168.1.2

(IP = Management IP des Switches)
...die Daten des Switches auslesen und so grundsätzlich checken ob der SNMP Zugang klappt.
Ggf. klappt das auch gleich direkt auf dem PF Server, denn der sollte alle diese SNMP Tools an Bord haben.
Hier ein Beispiel für einen Cisco Switch:

root@server:/# snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.1.1.0
iso.3.6.1.2.1.1.1.0 = STRING: "SG250-26 26-Port Gigabit Smart Switch"

Es gibt aber auch ein paar kostenlose Winblows Tools die dies ermöglichen wie z.B. der "SNMP Tester" von Paessler:
paessler.com/tools/snmptester

Hallo,

Switch Config (Auszug):
snmp-server community "pf-monitor"

sollte das nicht auch pf_monitor heissen?

cya

sollte das nicht auch pf_monitor heissen?

Kommt drauf an was bei den HP Billogurken mit "operator" gemeint ist??
Normalerweise gibt man üblicherweise den READ und WRITE Community String dort an. Möglich das die mit WRITE den Operator meinen der Hoheit über das Write Kommando hat?! 🤔 HP Logik...
Damit wären die Community Strings für SNMP Read und Write Operationen unterschiedlich, was bei WRITE Operationen auch unerlässlich wäre um die Infrastruktur nicht fahrlässig zu gefährden.
SNMPv2c ist bekanntlich offen und unverschlüsselt und damit hochgradig unsicher. Mit Kenntniss des WRITE Community Strings kann man die bösesten Sachen an den Komponenten anrichten.
Hoffen wir mal das es beim TO auch so gewollt ist und kein Tippfehler. So oder so ist es ob dieser Gefahr recht laienhaft für einen Administrator den Write String ähnlich wie den Read String zu setzen so das er einfach durch Probieren oder Erraten zu erkennen ist.

Ein Wireshark Trace zeigt das der Community String und auch alle SNMP Daten vollkommen ungeschützt übers Netz gehen! (Obige ISO OID 1.3.6.1.2.1.1.1.0 SNMP Abfrage des Systemnamens)

SNMPv3 wäre in Enterprise Netzen die deutlich bessere Wahl. Für ein einfaches Heimnetz aber je nach persönlichem Security Empfinden ggf. tolerabel.

Hallo aqui,
snmpwalk liefert schon Ergebnisse zurück.

Ausschnitt:
iso.3.6.1.2.1.2.2.1.12.32 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.33 = Counter32: 630
iso.3.6.1.2.1.2.2.1.12.34 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.35 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.36 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.37 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.38 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.39 = Counter32: 427
iso.3.6.1.2.1.2.2.1.12.40 = Counter32: 927
iso.3.6.1.2.1.2.2.1.12.41 = Counter32: 11222
iso.3.6.1.2.1.2.2.1.12.42 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.43 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.44 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.45 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.46 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.47 = Counter32: 1
iso.3.6.1.2.1.2.2.1.12.48 = Counter32: 291246
iso.3.6.1.2.1.2.2.1.12.49 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.50 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.51 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.52 = Counter32: 0

Somit könnten wir eigentlich die Firewall ausschließen.

Nebenbei ... Danke für den Hinweis, wir haben es zum Testen mit SMNP V2C gemacht.

Somit könnten wir eigentlich die Firewall ausschließen.

Und wohl auch einen fehlerhaften Community String...

Fragt sich jetzt nur ob PF dann auch die richtige SNMP Abfrage raushaut?? Da ist dann der Wireshark oder tcpdump dein bester Freund mit Paket Capture Filter auf die PF Source IP und Port 161 or 162.

Wenn der PF Server ein unixoider ist kannst du mit tcpdump -i <pf_interface> -s 65535 -w snmp.pcap port 161 or 162 so einen Trace in eine Wireshark Datei schreiben und diese dann mit dem Wireshark ansehen sofern du das grafisch sehen möchtest und nicht mit dem tcpdump CLI jonglieren willst. 😉
Ggf. haben die HP Gurken auch eine SNMP Debug Funktion wie z.B. Cisco die das direkt am Switch anzeigt?!

Frage Netzwerkmanagement

Heiß diskutiert