1
Cisco Catalyst 3850, 802.1X und IP-Sourceguard
Moin-Moin!
Ich habe hier ein paar Cisco Catalyst 3850 mit IOS 15.x stehen, die Router für ein paar VLANs sind.
Da werden Geräte angeschlossen, die per 802.1X authentifiziert werden - größtenteils aber direkt über die MAC-Adresse, weil es sich um autorisierte Geräte handelt, die aber kein 802.1X können.
Die RADIUS-Authentifizierung funktioniert, auch die Zuordnung ins korrekte VLAN.
Was nicht funktioniert ist, die Geräte auf die ihnen zugewiesenen IP-Adressen einzuschränken.
Theoretisch funktioniert das mit IP-Sourceguard in Kombination mit DHCP-Snooping. Praktisch haben wir da eine größere Anzahl Geräte mit statischen IP-Adressen (die Geräte können teilweise kein DHCP).
Da scheint es bei Cisco keine Lösung für zu geben, wenn man das nicht manuell konfigurieren will.
Was ich erfolglos versucht habe:
Einzige Lösungen bisher:
Beide Lösungen können aber scheinbar nicht über RADIUS-Attribute gesteuert werden. Das wäre aber das gewollte Ergebnis, damit Leute vor Ort mit wenig technischem Verständnis Geräte autorisieren können.
Gibt es da einen Trick, wie man den Switch dazu bekommt nicht nur die MAC-Adresse auf dem Interface zu filtern sondern auch die IP-Adressen und speziell ARP?
Es reicht ja, wenn der IP Sourceguard über ein RADIUS-Attribut mitgeteilt bekommen könnte, welche IP er zulassen soll.
Danke!
Hintergrund: Wir haben da teilweise für Entwicklungszwecke immer wieder mal eine größere Anzahl Geräte aller möglicher Art und Coleur, die von den Entwicklern selbst administriert werden und die dann oft genug Probleme durch doppelte statische IP-Adressen oder teilweise auch MAC-Adressen (durch virtuelle Maschinen) erzeugen. Damit da nicht ständig jemand von Hand irgendwelche Sachen freischalten muss, haben wir da ein Webinterface hingestellt, mit dem man die Geräte im RADIUS eintragen kann. Denen wird dann auf dem Wege auch eine IP zugewiesen und das soll dann auf dem Switch/Router enforced werden.
Und das möglichst dynamisch, damit das über ebendieses Webinterface geht.
Ich habe hier ein paar Cisco Catalyst 3850 mit IOS 15.x stehen, die Router für ein paar VLANs sind.
Da werden Geräte angeschlossen, die per 802.1X authentifiziert werden - größtenteils aber direkt über die MAC-Adresse, weil es sich um autorisierte Geräte handelt, die aber kein 802.1X können.
Die RADIUS-Authentifizierung funktioniert, auch die Zuordnung ins korrekte VLAN.
Was nicht funktioniert ist, die Geräte auf die ihnen zugewiesenen IP-Adressen einzuschränken.
Theoretisch funktioniert das mit IP-Sourceguard in Kombination mit DHCP-Snooping. Praktisch haben wir da eine größere Anzahl Geräte mit statischen IP-Adressen (die Geräte können teilweise kein DHCP).
Da scheint es bei Cisco keine Lösung für zu geben, wenn man das nicht manuell konfigurieren will.
Was ich erfolglos versucht habe:
- RADIUS-Attribute wie "Framed-IP-Address" mitgeliefert, die werden aber bei Ethernet natürlich ignoriert
- Cisco-AVPair-Attribute gesetzt, die eine dynamische "inacl" auf dem Port setzen und nur die erlaubte Source-Adresse durchlassen. Funktioniert nur mittelmäßig, weil diese ACL nur auf Layer 3 greift und damit weiterhin falsche ARP-Antworten zulässt.
- Ciscvo-AVPair-Attribute gesetzt, die die zugewiesene IP-Adresse als /32-Route auf das Switchport-Interface routen sollen und dann mit rpf ungültige Pakete droppen lassen. Funktioniert aber auch nicht, weil man keine Routen auf Ports legen kann, die vom Typ "switchport" sind, das kann man nur bei Routed interfaces. Und selbst wenn es ginge hätte ich vermutlich das selbe Problem mit ARP wie bei der inacl.
- IP-Vergabe als /31-Präfix an den Client, dann ein Routed Interface benutzen, dort die erste Adresse binden. Geht aber nicht, weil nur Access-Ports 802.1X können.
Einzige Lösungen bisher:
- IP-Sourceguard mit manuellen IP-Bindings
- ARP-Access-List mit einer Liste gültiger MAC-IP-Kombinationen für ARP-Inspection
Beide Lösungen können aber scheinbar nicht über RADIUS-Attribute gesteuert werden. Das wäre aber das gewollte Ergebnis, damit Leute vor Ort mit wenig technischem Verständnis Geräte autorisieren können.
Gibt es da einen Trick, wie man den Switch dazu bekommt nicht nur die MAC-Adresse auf dem Interface zu filtern sondern auch die IP-Adressen und speziell ARP?
Es reicht ja, wenn der IP Sourceguard über ein RADIUS-Attribut mitgeteilt bekommen könnte, welche IP er zulassen soll.
Danke!
Hintergrund: Wir haben da teilweise für Entwicklungszwecke immer wieder mal eine größere Anzahl Geräte aller möglicher Art und Coleur, die von den Entwicklern selbst administriert werden und die dann oft genug Probleme durch doppelte statische IP-Adressen oder teilweise auch MAC-Adressen (durch virtuelle Maschinen) erzeugen. Damit da nicht ständig jemand von Hand irgendwelche Sachen freischalten muss, haben wir da ein Webinterface hingestellt, mit dem man die Geräte im RADIUS eintragen kann. Denen wird dann auf dem Wege auch eine IP zugewiesen und das soll dann auf dem Switch/Router enforced werden.
Und das möglichst dynamisch, damit das über ebendieses Webinterface geht.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 21639172029
Url: https://administrator.de/forum/cisco-catalyst-3850-802-1x-und-ip-sourceguard-21639172029.html
Ausgedruckt am: 31.12.2024 um 04:12 Uhr
1 Kommentar
Der Cisco .1x Deployment Guide gibt das Radius Attribut 8 (Framed_IP_Address) lediglich fürs Radius Accounting an. Das bedeutet dann aber das das Endgerät dann schon eine irgendwie geartete IP Adresse bekommen hat.
Meiner Meinung nach sieht .1x und MAB per se keine dynamische Zuweisung einer IP Adresse per Radius für den authentisierten Ethernet Client vor. PPP und SLIP usw. ist etwas anderes.
Dazu müsste bei Ethernet dann ja auch im IP Address Setup des Clients, außer der 2 üblichen Optionen DHCP und Static, dann noch sowas wie "get IP from Radius" o. ä. vorhanden sein.
Port Authentication und Zuweisung einer IP sind m. E. nach 2 unterschiedliche Baustellen bei .1x und MAB die unabhängig voneinander sind.
Dir wird dann vermutlich nur deine 2 o.g. Optionen oder spezifische DHCP Zuweisung auf Basis der spezifischen Client Mac Adresse bleiben, was dann aber wieder die Kenntnis dieser Adresse voraussetzt.
Das wiederum dann zusätzliche Tools wie beispielsweise MacMon usw. erfordert wenn man die Mac nicht immer manuell statisch zuweisen will.
Die andere Option ist nicht authentisierte Endgeräte, egal ob fehlgeschlagene Authentisierung per .1x oder MAB oder ganz ohne .1x Client, in ein Web authentisiertes VLAN auf dem Switch zu zwingen und dann die Web Authentisierung dieser Clients wieder per Radius zu machen. Aber auch da kann man m.E. dann keine spezifische Client IP zuweisen. Wie auch, denn diese Endgeräte brauchen ja schon eine gültige IP, weil nur HTTP(S) Traffic das Captive Portal für die Webauthentisierung auf dem Switch triggert.
Meiner Meinung nach sieht .1x und MAB per se keine dynamische Zuweisung einer IP Adresse per Radius für den authentisierten Ethernet Client vor. PPP und SLIP usw. ist etwas anderes.
Dazu müsste bei Ethernet dann ja auch im IP Address Setup des Clients, außer der 2 üblichen Optionen DHCP und Static, dann noch sowas wie "get IP from Radius" o. ä. vorhanden sein.
Port Authentication und Zuweisung einer IP sind m. E. nach 2 unterschiedliche Baustellen bei .1x und MAB die unabhängig voneinander sind.
Dir wird dann vermutlich nur deine 2 o.g. Optionen oder spezifische DHCP Zuweisung auf Basis der spezifischen Client Mac Adresse bleiben, was dann aber wieder die Kenntnis dieser Adresse voraussetzt.
Das wiederum dann zusätzliche Tools wie beispielsweise MacMon usw. erfordert wenn man die Mac nicht immer manuell statisch zuweisen will.
Die andere Option ist nicht authentisierte Endgeräte, egal ob fehlgeschlagene Authentisierung per .1x oder MAB oder ganz ohne .1x Client, in ein Web authentisiertes VLAN auf dem Switch zu zwingen und dann die Web Authentisierung dieser Clients wieder per Radius zu machen. Aber auch da kann man m.E. dann keine spezifische Client IP zuweisen. Wie auch, denn diese Endgeräte brauchen ja schon eine gültige IP, weil nur HTTP(S) Traffic das Captive Portal für die Webauthentisierung auf dem Switch triggert.
