Wie richte ich RadSec mit DTLS auf einem Cisco Catalyst 9300 mit IOS XE 17.15.05 und Cisco ISE ein?

**RadSec mit DTLS auf einem Catalyst 9300 unter IOS XE 17.15.05 funktioniert nur sauber, wenn du Zertifikate auf beiden Seiten korrekt zuordnest und auf CoA-Besonderheiten achtest: Authentifizierung per DTLS geht, CoA über denselben Auth-Kanal aber nicht.** ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) ## Was zuerst wichtig ist Die wichtigste Korrektur vorweg: Viele setzen RadSec mit „RADIUS über TLS auf Port 2083“ gleich. Auf dem Catalyst 9300 mit IOS XE 17.15.x ist aber **RadSec sowohl über TLS als auch über DTLS** dokumentiert, und für **DTLS darf der Port nicht im Bereich 1–1024 liegen**. Außerdem empfiehlt Cisco, innerhalb einer AAA-Servergruppe nicht TLS und DTLS zu mischen. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) Praktisch heißt das: Wenn du **DTLS** willst, nimm einen **freien UDP-Port >1024** auf ISE und Switch, verwende **gegenseitige Zertifikatsprüfung**, und plane **CoA getrennt**. Denn **CoA über denselben Authentifizierungstunnel wird nur bei TLS unterstützt, nicht bei DTLS**. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) ## Was du auf der Cisco ISE brauchst Auf der ISE muss ein Systemzertifikat vorhanden sein, das für **RADIUS DTLS** freigegeben ist. Cisco beschreibt diese Zertifikatsrolle ausdrücklich für die DTLS-Verschlüsselung zwischen NAD und ISE. Empfehlenswert ist ein CA-signiertes Zertifikat; SAN-Einträge für **FQDN und IP** der ISE sind sinnvoll, damit die Gegenstellenprüfung nicht an Namensabweichungen scheitert. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215621-tls-ssl-certificates-in-ise.html)) Wenn du in ISE die Option **Enable RADIUS/DTLS Client Identity Verification** aktivierst, vergleicht ISE den konfigurierten DNS-Namen des Netzwerkgeräts mit dem Namen im Client-Zertifikat. Genau daran scheitern viele Setups: Das Zertifikat des Switches enthält nur einen CN, aber keinen passenden SAN/FQDN zur NAD-Definition in ISE. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-2/admin_guide/b_ise_admin_3_2/b_ISE_admin_32_secure_wired_access.html)) Kurz gesagt: - ISE-Serverzertifikat mit Rolle **RADIUS DTLS** - Zertifikatskette der ausstellenden CA vollständig importiert - NAD in ISE mit korrekter IP/FQDN angelegt - Falls Client-Identity-Verification aktiv ist: Name im Switch-Zertifikat muss exakt passen ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215621-tls-ssl-certificates-in-ise.html)) ## Was auf dem Catalyst 9300 konfiguriert werden muss Cisco zeigt für IOS XE 17.15.x die DTLS-Konfiguration direkt unter `radius server`. Relevant sind dabei: - `dtls connectiontimeout` - `dtls idletimeout` - `dtls retries` - `dtls ip radius source-interface` - `dtls match-server-identity ...` - `dtls port` - `dtls trustpoint client ...` - `dtls trustpoint server ...` ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) Der Punkt, den viele Standardanleitungen zu oberflächlich behandeln: **`match-server-identity` ist praktisch der entscheidende Sicherheitshebel**. Im aktuellen Cisco-RADIUS-Guide ist diese Prüfung als **mandatory configuration** hervorgehoben. Ohne saubere Server-Identitätsprüfung baust du zwar eventuell einen Tunnel auf, aber nicht vertrauenswürdig. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/sec-crypto/radius/radius-configuration-guide.pdf)) ## Beispielkonfiguration auf dem Switch Das folgende Beispiel ist für einen Catalyst 9300 mit IOS XE 17.15.05 und einer ISE als RadSec-DTLS-Server gedacht. Werte wie IP, Port, Trustpoint-Namen und Interface musst du anpassen. ```ios conf t ! aaa new-model ! crypto pki trustpoint ISE-CA enrollment terminal revocation-check none ! crypto pki authenticate ISE-CA ! crypto pki trustpoint SW-RADSEC enrollment terminal subject-name CN=sw01.example.local revocation-check none rsakeypair SW-RADSEC-KEY ! crypto pki enroll SW-RADSEC ! radius server ISE1 address ipv4 10.10.10.20 auth-port 1812 acct-port 1813 key 0 DummySharedSecret dtls connectiontimeout 10 dtls idletimeout 75 dtls retries 15 dtls ip radius source-interface Vlan100 dtls match-server-identity ip-address 10.10.10.20 dtls port 2084 dtls trustpoint client SW-RADSEC dtls trustpoint server ISE-CA ! aaa group server radius ISE-GRP server name ISE1 ! aaa authentication dot1x default group ISE-GRP aaa authorization network default group ISE-GRP aaa accounting dot1x default start-stop group ISE-GRP end write memory ``` ## Der wichtige Sonderfall beim Shared Secret Auch wenn RadSec/DTLS den RADIUS-Verkehr verschlüsselt, arbeitet ISE bei der NAD-Definition weiterhin mit dem klassischen **RADIUS Shared Secret** für die Gerätezuordnung. Cisco beschreibt in der ISE-Dokumentation, dass ISE bei eingehenden RADIUS-Anfragen die passende Device Definition und das konfigurierte Shared Secret heranzieht. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-1/admin_guide/b_ise_admin_3_1/b_ISE_admin_31_secure_wired_access.html)) Das ist in der Praxis der Punkt, den viele falsch interpretieren: **DTLS ersetzt auf ISE-Seite nicht automatisch jede klassische RADIUS-Gerätezuordnung.** Du brauchst also in ISE weiterhin einen sauber definierten Network Device-Eintrag. ## CoA mit DTLS: der häufigste Planungsfehler Wenn du 802.1X, MAB oder Policy-Änderungen mit ISE nutzt, ist CoA oft Pflicht. Genau hier ist **DTLS die heikle Wahl**: - **Auth über DTLS**: unterstützt - **CoA über denselben Tunnel**: **nicht** unterstützt - **Same-tunnel CoA** gibt es nur bei **RadSec über TLS** ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) Die praktische Konsequenz ist klar: Wenn du ein Design willst, bei dem ISE CoA elegant über denselben gesicherten Kanal zurückschickt, ist **TLS die bessere Wahl als DTLS**. DTLS ist auf dem 9300 zwar möglich, aber funktional nicht die bequemste Variante für typische ISE-Access-Deployments. ## Reihenfolge für die Inbetriebnahme ## 1. Zertifikate vorbereiten Auf ISE: - Serverzertifikat mit Rolle **RADIUS DTLS** - CA-Kette vollständig - optional Client-Identity-Verification nur aktivieren, wenn Zertifikatsnamen sauber geplant sind ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215621-tls-ssl-certificates-in-ise.html)) Auf dem Switch: - ein **Client-Trustpoint** mit eigenem Zertifikat - ein **Server-Trustpoint** mit der CA, die das ISE-Zertifikat signiert hat ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) ## 2. ISE als NAD-Eintrag anlegen - Switch-IP als Network Device eintragen - Shared Secret setzen - falls mit FQDN/Identity-Verification gearbeitet wird: Namen exakt konsistent halten ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-1/admin_guide/b_ise_admin_3_1/b_ISE_admin_31_secure_wired_access.html)) ## 3. DTLS-Port festlegen - kein Port 1–1024 - derselbe Port auf ISE und Switch - Firewall/ACLs für UDP-Port freigeben ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) ## 4. Switch auf DTLS konfigurieren - Source-Interface festlegen - `match-server-identity` setzen - Client- und Server-Trustpoint korrekt zuweisen ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) ## 5. Funktion prüfen Cisco nennt dafür vor allem: - `show aaa servers` - `debug radius radsec` - bei Bedarf Zähler mit `clear aaa counters servers radius ...` zurücksetzen ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) ## Woran es in der Praxis meist scheitert Der größte Unterschied zu typischen Kurz-Anleitungen: Nicht die DTLS-Befehle sind das Problem, sondern die **Identität im Zertifikat**. Typische Fehler sind: - ISE-Zertifikat ohne passende SANs - Switch-Zertifikat passt nicht zum in ISE erwarteten Namen - `dtls match-server-identity` fehlt oder prüft auf den falschen Wert - falsches Source-Interface - DTLS-Port unter 1025 - Erwartung, dass CoA über denselben DTLS-Tunnel funktioniert ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) ## Klare Empfehlung Wenn dein Ziel einfach nur **verschlüsseltes RADIUS zwischen Catalyst 9300 und ISE** ist, dann ist **RadSec über TLS meist die bessere Architektur**, weil CoA über denselben Kanal unterstützt wird. **DTLS lohnt sich nur, wenn du bewusst UDP-basiertes RadSec willst und die CoA-Einschränkung akzeptierst.** ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html)) Für die Cisco-Befehle auf IOS XE 17.15.x ist die offizielle Referenz die [RadSec-Konfiguration für Catalyst 9300](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/configuring_radsec.html). Die ISE-seitige Zertifikatsrolle für DTLS ist in der Cisco-Doku zu [TLS/SSL-Zertifikaten in ISE](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215621-tls-ssl-certificates-in-ise.html) beschrieben.