Wie richte ich RADIUS DTLS mit Cisco ISE 3.4 und Catalyst 9300 unter IOS XE 17.15.05 ein?

**RADIUS DTLS zwischen Cisco ISE 3.4 und einem Catalyst 9300 mit IOS XE 17.15.05 richtest du nicht nur mit einem Shared Secret ein, sondern zusätzlich mit Zertifikaten auf beiden Seiten; genau daran scheitern die meisten Setups.** Cisco dokumentiert für IOS XE 17.15.x die RadSec-/DTLS-Konfiguration auf dem C9300 und für ISE 3.4 die DTLS-Optionen pro Network Device. ([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 vorab wichtig ist Der wichtigste Unterschied zu normalem RADIUS über UDP: Bei **RADIUS DTLS** wird zuerst ein DTLS-Tunnel aufgebaut, erst danach laufen die RADIUS-Nachrichten geschützt darüber. Dafür braucht der Switch ein Client-Zertifikat und ISE ein passendes Server-Zertifikat; ISE kann zusätzlich die Identität des Switches per Zertifikat prüfen. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/222537-configure-radius-dtls-on-ise-and-9800-wl.html)) Zwei Einschränkungen sind praktisch entscheidend: - **CoA über denselben Auth-Kanal wird bei DTLS nicht unterstützt**; Cisco nennt das nur für RadSec over TLS, nicht für DTLS. Wenn du CoA-Designs 1:1 aus klassischem RADIUS übernimmst, passt das oft 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)) - **DTLS-Ports 1–1024 sind nicht unterstützt**; Cisco nennt als typischen Port **2083**. ([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)) ## ISE 3.4 vorbereiten In ISE brauchst du zuerst ein System-Zertifikat mit der Rolle **RADIUS DTLS**. Cisco weist darauf hin, dass das Default Self-Signed Certificate zwar oft zugewiesen ist, für produktive Umgebungen aber besser ein internes oder öffentlich signiertes Zertifikat verwendet wird. Sinnvoll ist, FQDN und IP des ISE-Knotens in den SANs zu haben. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215621-tls-ssl-certificates-in-ise.html)) Dann legst du den Switch unter **Administration > Network Resources > Network Devices** an und aktivierst dort die **RADIUS DTLS Settings**. Relevant sind vor allem: - Shared Secret setzen - optional **DTLS Required** aktivieren - falls Zertifikatsprüfung gewünscht: DNS-Name des Clients sauber pflegen, weil ISE diesen mit dem Zertifikat abgleichen kann, wenn **Enable RADIUS/DTLS Client Identity Verification** aktiv ist. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html)) Praktisch wichtig: **DTLS Required** erst aktivieren, wenn der Switch bereits sauber per DTLS kommt. Sonst sperrst du dir funktionierendes Fallback über UDP unnötig ab. Das ist der Punkt, den viele Standardanleitungen zu knapp erklären. Die sichere Reihenfolge ist erst „DTLS erlauben“, testen, danach optional „DTLS Required“. Diese Empfehlung ist eine technische Ableitung aus dem ISE-Verhalten bei aktiviertem „DTLS Required“. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html)) ## Zertifikate auf dem Catalyst 9300 Der Switch braucht: - eine vertrauenswürdige CA für das ISE-Zertifikat - ein eigenes Zertifikat für die DTLS-Client-Authentisierung Cisco beschreibt für DTLS allgemein, dass auf dem NAD die passende PKI-Basis vorhanden sein muss; beim Cisco-Beispiel zu RADIUS DTLS wird ausdrücklich auf **Client Authentication** beim NAD-Zertifikat und **Server + Client Authentication** auf ISE-Seite hingewiesen. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/222537-configure-radius-dtls-on-ise-and-9800-wl.html)) Wichtig für die Praxis: Wenn ISE die Client-Identität prüfen soll, muss der **Subject/SAN-Name des Switch-Zertifikats** zu dem in ISE hinterlegten DNS-Namen passen. Sonst steht der DTLS-Handshake, obwohl Shared Secret und Erreichbarkeit korrekt sind. Genau das ist der typische „alles sieht richtig aus, aber DTLS kommt nicht hoch“-Fehler. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html)) ## Beispielkonfiguration auf dem Catalyst 9300 Die genaue PKI-Einrichtung hängt von deiner CA ab, aber die AAA-/RADIUS-DTLS-Konfiguration auf IOS XE 17.15.x sieht sinngemäß so aus: ([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)) ```ios aaa new-model radius server ISE1 address ipv4 10.10.10.10 auth-port 1812 acct-port 1813 key 0 MeinSharedSecret dtls port 2083 dtls connectiontimeout 10 dtls retries 15 dtls ip radius source-interface Vlan100 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 ``` Der entscheidende Teil ist nicht nur `dtls port 2083`, sondern auch die **Source-Interface-Festlegung**. Cisco weist darauf hin, dass der RADIUS-Client einen ephemeren Source-Port nutzt und dass die Port-/Transport-Kombinationen sauber geplant werden müssen. In der Praxis vermeidest du mit einem festen Source-Interface viele unnötige Zertifikats- und Erreichbarkeitsprobleme. ([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 auf dem Switch oft zusätzlich fehlt Viele Anleitungen bleiben beim RADIUS-Block stehen. In der Praxis brauchst du meist zusätzlich: - Trustpoint mit CA-Zertifikat - Identity-Zertifikat auf dem Switch - Zuordnung des Zertifikats für die DTLS-Nutzung - saubere Uhrzeit/NTP, sonst scheitert die Zertifikatsprüfung Gerade **Zeitabweichungen** sind bei DTLS deutlich kritischer als bei klassischem RADIUS. Wenn Zertifikate „noch nicht gültig“ oder „abgelaufen“ wirken, ist der Tunnel sofort tot. Das ist banal, aber einer der häufigsten echten Ursachen. ## Empfohlene Reihenfolge 1. ISE-Systemzertifikat mit **RADIUS DTLS** prüfen. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215621-tls-ssl-certificates-in-ise.html)) 2. Switch als Network Device in ISE anlegen, Shared Secret setzen, DTLS zunächst **nicht erzwingen**. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html)) 3. CA-Chain und Client-Zertifikat auf dem C9300 importieren. 4. RADIUS-Server auf dem Switch mit `dtls port 2083` und Source-Interface konfigurieren. ([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. DTLS-Handshake testen. 6. Erst wenn das stabil läuft, in ISE optional **DTLS Required** aktivieren. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html)) ## Wichtiger Unterschied zu typischen Standardanleitungen Der häufigste Denkfehler ist: „RADIUS DTLS ist normales RADIUS plus ein Häkchen in ISE.“ Das ist falsch. **Technisch ist es ein Zertifikatsprojekt mit AAA-Anbindung**, nicht nur ein RADIUS-Projekt. Wenn Zertifikate, SAN/FQDN, Trust-Chain oder Zeit nicht sauber sind, hilft dir das korrekt gesetzte Shared Secret praktisch gar nicht. Diese Einordnung fehlt in vielen oberflächlichen Anleitungen, ist aber für eine funktionierende Inbetriebnahme entscheidend. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html)) ## Für die Cisco-Doku sind diese zwei Stellen die wichtigsten Für den Switch ist die relevante Referenz die Cisco-Seite zur **RadSec-/DTLS-Konfiguration auf IOS XE 17.15.x**: [Configuring RadSec](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). ([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 ISE 3.4 ist die wichtigste Stelle die Admin-Doku zu den **RADIUS DTLS Settings** am Network Device, inklusive **DTLS Required** und Client Identity Verification: [RADIUS DTLS Settings](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html). ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/admin_guide/b_ise_admin_3_4/b_ISE_admin_threat_containment.html)) Wenn du es fachlich sauber aufbauen willst, ist die beste Kurzform: **ISE-Zertifikat mit RADIUS-DTLS-Rolle, Switch-Zertifikat mit Client-Auth, gegenseitiges Vertrauen, DTLS-Port 2083, Source-Interface festlegen, erst testen, dann DTLS erzwingen.** ([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))