Problembehandlung von IPSec

Vorwort
Mit IPSec können Sie jede Netwerkkommunikation ändern, die von oder an einen Computer gesendet wird. Das mag
schon einschüchtern klingen, aber IPSec ist auch noch schwierig zu konfigurieren. Die Standardprogramme zur Pro-
blembehandlung funktionieren evtl. nicht, der der Netzwerkverkehr normalerweise verschlüsselt ist. Daher benötigen
Sie spezifisches Fachwissen, um Probleme mit der IPSec-Kommunikation effizient zu behandeln. Hier werden ge-
wöhnliche IPSec-Problembehandlungen besprochen, mit einer Beschreibung, wie Sie Probleme ermitteln und lösen
können.

Allgemeine Problembehandlungs-Richtlinien

Unabhängig von der Art des Problems, das Sie gerade haben, sollten Sie zuerst sicherstellen, dass alle benötigten
Dienste gestartet und auf beiden IPSec-Peers auf automatisch gesetzt wurden. Auf Computern unter Windows Ser-
ver 2003 müssen die IPSEC-Dienste gestartet werden. Auf Computern unter Windows 2000 muss der IPS-Richtlinien-
agent gestartet werden.

Manchmal, besonders wenn Sie wichtige Änderungen vorgenommen haben, können Sie ein Problem durch einen Neu-
start der IPSec-Dienste lösen. Dies löscht den IKE-Aushandlungsstatus vollständig. Sie können die IPSec-Dienste von
einer Befehlszeile aus neu starten, indem Sie die folgenden Befehle ausführen:

net stop policyagent
net start policyagent

Dies ist ein einfach ein schneller Weg, IPSec neu zu starten, ohne den Computer neu zu starten. Versuchen Sie nach
dem Neustart der IPSec-Dienste auf beiden Computern eine sichere Verbindung aufzubauen. Wenn das Problem fort-
besteht, starten Sie die Betriebssysteme auf beiden IPSec-Peers neu und versuchen Sie es erneut. Stellen Sie als
Nächstes sicher, dass die die richtige Richtlinie an jeden der IPSec-Peers zugewiesen wurde, indem Sie das IP-
Sicherheitsmonitor-Snap-In verwenden. Denken Sie daran, dass beim Erstellen einer neuen Richtlinie diese nicht auto-
matisch einem Computer zugewiesen wird. Dazu komm, dass bei der Weitergabe einer Richtlinie mit GPO die Einste-
llungen nicht sofort übertragen werden. Wenn die Richtlinie anders ist als erwartet, identifizieren Sie das verantwort-
liche GPO mit dem Richtlinienergebnissatz-Snap-In oder dem Netsh-Befehl Netsh Ipsec Static Show Gpoassigned-
policy.


Stellen Sie sicher, dass die IKE-Aushandlung erfolgreich ist, indem Sie Überwachen und Überprüfen des Sicher-
heitsereignisprotokolls
aktivieren. Wenn die IKE-Aushandlung nicht erfolgreich ist, stellen Sie sicher, dass Authenti-
fizizierungsverschlüsselungs- und Schlüsseländerungs-Einstellungen auf beiden IPSec-Peers gleich sind. Wenn es
keine Anzeichen gibt, dass die Aushandlungen erfolgreich sind, verwenden Sie Netzwerkmonitor, um sicherzustellen,
dass Pakete den richtigen Computer erreichen.

Wenn IKE-Aushandlungen erfolgreich sind, aber die IPSec-Kommunikation fehlschlägt, stellen Sie sicher, dass der
Schnellmodus funktioniert, indem Sie das Sicherheitsereignisprotokoll und das IKE-Ablaufverfolgungsprotokoll über-
prüfen. Wenn der Schnellmodus nicht funktioniert, überprüfen Sie, ob die Schnellmodus-Verschlüsselungs-, Integri-
täts-, Schlüsselstärke- und Schlüsseländerungs-Einstellungen auf beiden IPSec-Peers gleich sind.

Wenn IPSec-Aushandlungen einfach nicht stattfinden oder wenn die Art der Aushandlungen anders ist als erwartet,
überprüfen Sie die IPSec-Filter sorgfältig. Wenn Sie Quell- und Ziel-IP-Adressen im Filter angeben, stellen Sie sicher,
dass die Filter auf beiden IPSec-Peers gespiegelt sind. Wenn Sie Quell- und Ziel-Anschlussnummern angeben, muss
der Remote-IPSec-Peer die gleichen Anschlussnummern konfiguriert haben, aber mit umgekehrten Quell- und Ziel-
nummern.

Kerberos-Authentifizierungsprobleme

Kerberos Authentifizierung ist die Standard-IPSec-Authentifizierungsmethode. Sie können schnell feststellen, ob IPSec-
Verbindungsprobleme durch die Authentifizierung verursacht wurden, indem Sie die IPSec-Authentifizierungsmethode
vorübergehend auf beiden IPSec-Peers in Vorinstallierter Schlüssel ändern. Wenn die IPSec-Verbindung mit Vor-
installierter Schlüssel
funktioniert, ist die Kerberos-Authentifizierung die Problemursache.

Damit Kerberos-Authentifizierung erfolgreich ist, müssen beide IPSec-Peers gültige Computerkonten in vertrauens-
würdigen Domänen haben, und sie müssen fähig sein, Remotecomputer zu authentifizieren. Jeder IPSec-Peer muss
fähig sein, mit den Domänencontrollern zu kommunizieren, ohne dass die Authentifizierungsanforderungen gefiltert
werden. In früheren Windows-Versionen ließ IPSec automatisch Kerberos-Datenverkehr zu. Das Kerberos-Protokoll
ist jedoch nicht länger standardmäßig, ausgenommen in Windows Server 2003.

Um das Standardfilterverhalten für Windows Server 2003 zu ändern, verwenden Sie Netsh, um den IPSec-
Ausnahmewert auf 0, 1 oder 2 zu setzen.
Standardmäßig ist der Wert auf 3 gesetzt. Diese Einstellung legt fest,
dass nur ISAKMP-Verkehr (Internet Security Association And Key Management Protocol) vom IPSec-Filtern aus-
genommen ist. Wird ein Wert von 2 festgelegt, wird RSVP-(Resource Reservation Setup Protocol), Kerberos- und
ISAKMP-Verkehr zugelassen. Ein Wert von 1 läßt Multicat-, Broadcast- und ISAKMP-Verkehr zugelassen. Um einen
Wert festzusetzen, führen Sie diesen Befehl aus:

netsh ipsec dynamic set config ipsecexempt value= (0 / 1 / 2 / 3)

Beide IPSec-Peers müssen den jeweils anderen authentifizieren, daher kann das Problem bei der Authentifizierung
einer der beiden Computerkonten liegen. Aktivieren Sie auf beiden Computern die Richtlinie Anmeldeereignisse
überwachen
. Versuchen Sie, eine IPSec-Verbindung aufzubauen und überprüfen Sie dann das Sicherheitsereignis-
protokoll auf beiden Computern. Dort sollten Sie ein Fehlerüberwachungsereinis sehen, das Auskunft über den
Fehler gibt.

Zertifikats-Authentifizierungsprobleme

Zertifikate sind eine normale Methode zur Authentifizierung von Computern, die nicht in einer vertrauenswürdigen Do-
mänenumgebung sind. Wenn Sie IPSec-Verbindungsprobleme haben und bestätigen möchten, dass diese durch die
Authentifizierung verursacht wurden, ändern Sie die IPSec-Authentifizierungsmethode vorübergehend auf beiden IPSec-
Peers in Vorinstallierter Schlüssel. Wenn die IPSec-Verbindung mit Vorinstallierter Schlüssel funktioniert, hat
das Problem sehr wahrscheinlich mit Zertifikaten zu tun.

Wenn Sie mehrere Regeln in einer Richtlinie haben, überprüfen Sie sorgfältig, ob diese Regeln dieselbe Authentifizie-
rungsmethode konstant für jeden einzelnen Remotecomputer verwenden. Es ist akzeptabel, dass eine Richtlinie Ker-
beros-Authentifizierung für Hosts auf einem internen Netzwerk konfiguriert und Zertifikate für Hosts auf externen Netz-
werken verwendet. Sie können jedoch beispielsweise keine Regeln erstellen, die Kerberos verwenden, um nur TCP-
Daten (Transmission Control Protocol) zu authentifizieren und eine zweite Regel, die UDP-Verkehr (User Datagram
Protocol) durch Zertifikate authentifiziert. Das Snap-In Sicherheitsrichtlinienverwaltung hindert Sie nicht daran, solche
Regeln zu erstellen, diese werden jedoch nicht richtig funktionieren. Alle Regeln, die auf einen einzigen Remote Host
anwendbar sind, müssen eine einzige Authentifizierungsmethode verwenden.

Ein weiterer potentieller Grund für Authentifizierungsprobleme sind falsch bezogene Zertifikate. Falsch bezogene Zerti-
fikate können verursachen, dass die Zertifikate existieren und für die IKE-Authentifizierung ausgewählt werden, aber
nicht funktionieren, da der private Schlüssel, der dem öffentlichen Schlüssel des Zertifikats entspricht nicht auf dem
lokalen Computer präsent ist. So bestätigen Sie, dass ein Zertifikat, das Sie für IPSec verwenden möchten, einen
privaten Schlüssel hat:

  1. Öffnen Sie eine leere MMC-Konsole und fügen Sie das Zertifikat-Snap-In ein. Wenn Sie dazu aufgefordert werden,
    wählen Sie Computerkonto.

  2. Erweitern Sie Zertifikate (Lokaler Computer) und dann Persönlich.

  3. Klicken Sie auf den Zertifikatsknoten.

  4. Doppelklicken Sie auf der rechten Seite auf das Zertifikat, das Sie überprüfen möchten. Auf der Registerkarte
    Allgemein sollten Sie folgenden Text sehen: "Sie besitzen einen privaten Schlüssel für dieses Zertifikat".
    Wenn Sie diese Meldung nicht sehen, kann das System dieses Zertifikat nicht erfolgreich für IPSec verwenden.

Abhängig davon, wie das Zertifikat angefordert wurde und in den lokalen Zertifikatspeicher des Hosts abgelegt wurde,
existiert dieser private Schlüssel evtl. nicht oder ist für die Verwendung während der IKE-Aushandlungen nicht ver-
fügbar. Wenn das Zertifikat im persönlichen Ordner keinen entsprechenden privaten Schlüssel hat, ist die Zertifikats-
registrierung fehlgeschlagen.

Wenn das Zertifikat von einem Zertifikatsdienst bezogen wurde, dessen Option auf Angemessener Schutz durch
Privaten Schlüssel
festgesetzt war, muss der Benutzer eine PIN-Nummer eingeben, um auf den privaten Schlüssel
zuzugreifen, wenn dieser Daten in der IKE-Aushandlung signieren soll. Da die IKE-Aushandlung im Hintergrund von
einem Systemdienst ausgeführt werden, gibt es kein Fenster des Dienstes, in dem der Benutzer zur Eingabe der PIN
aufgefordert wird. Das bedeutet, dass Zertifikate, die mit dieser Option bezogen wurden, nicht für die IKE-Aushandlung
funktionieren.

Problembehandlung bei Firewalls, Routern und Paketfiltern

Paketfiltern bei Firewalls ist eine häufige Ursache für IPSec-Probleme, da IPSec nicht durch Techniken zugelassen
oder blockiert werden kann, die für die meisten Anwendungen benutzt werden. Ihre Firewall muss Zweiweg-Verkehr
mit einem UDP-Zielanschluss von 500 zulassen. Wenn die Firewall auch ein NAT-Server ist und Sie NAT-T (Net-
work Address Translation Traversal) verwenden, muss ebenfalls UDP-Verkehr mit einem Zielanschluss von 4500
zugelassen werden. Außerdem muss die Firewall Datenverkehr mit einer IP-Protokoll-ID von 50 (wird von ESP ver-
wendet)
zulassen. Wenn Sie AH anstelle von ESP verwenden, müssen Sie IP-Protokoll 51 zulassen.

Wichtig:
Das IP-Protokoll ID 50 ist nicht das Gleich wie UDP oder TCP-Anschluss 50.

Sie können keine konventionellen Paketfilter verwenden, um Datenverkehr selektiv zu blockieren, der innerhalb von
IPSec per Tunnel oder Transport gesendet wird. Die meisten Paketfilter blockieren Datenverkehr basierend auf der
TCP- oder UDP-Anschlussnummer, aber diese Nummern sind normalerweise durch ESP verschlüsselt. Nur auf
den beiden IPSec-Peers implementieren IPSec-Filter können anschlussbasierte Paketfilterung ausführen. Sie kö-
nnen Datenverkehr jedoch auch basierend auf Quell- oder Ziel-IP-Adresse filtern.

Netzwerkadressübersetzungs-Probleme


Netzwerkadressübersetzung (NAT) ist eine gebräuchliche Technik für die Verbindung eines privat nummerierten in-
ternen Netzwerks mit einem öffentlichen Netzwerk wie dem Internet. Es sind frühere Implementierungen von IPSec
nicht mit NAT kompatibel. Dies macht Sinn, denn der Zweck von NAT ist es, die Quell- oder Ziel-IP-Adresse in
einem Paket zu ändern, ohne dass Client oder Server etwas davon merken, und Teil des Zwecks von IPSec ist es,
Pakete zu verwerfen, die während der Übertragung geändert wurden.

Hinweis:
Sie werden beim Aufbau von IPSec-Verbindungen zwischen zwei Clients auf einem einzelnen, privaten Netzwerk
keine Probleme haben. Nur wenn der NAT-Server Adressübersetzungen in IPSec-geschützten Kommunkations-
vorgängen durchführt, können Probleme auftreten.

IPSec NAT Traversal (NAT-T) ermöglicht IPSec-Verkehr, kompatibel NAT-Server zu passieren. Sowohl die IPSec-
Hosts als auch der NAT-Server müssen jedoch NAT-T unterstützen und der NAT-Server muss so konfiguriert sein,
dass der Datenverkehr an UDP-Anschluss 4500 zuläßt. Windows Server 2003, Windows XP Professional und
Windows 2000 unterstützen NAT-T als IPSec-Clients. Microsoft ISA-Server (Internet Security And Acceleration)
und Windows Server 2003 unterstützen NAT-T als Firewall.

Wenn Sie Probleme beim Aufbau einer IPSec-Verbindung zu einem NAT-Server haben, bestätigen Sie zuerst, dass
beide IPSec-Clients und der NAT-Server NAT-T unterstützen. Clients mit Windows 2000 oder Windows XP benötigen
das Update 818043. (Dieses Update erhalten Sie unter http://support.microsoft.com/default.asp?kbid=818043.)
Wenn Sie die vordefinierten NAT-Funktionen eines Computers unter Windows XP oder Windows 2000 verwenden
oder frühere Versionen als Windows 2000, können Sie IPSec nicht mit NAT verwenden.

Vorsicht:
Stellen Sie sicher, dass Sie ESP verwenden. Sie können AH nicht für einen NAT-Server verwenden, da AH nicht
mit NAT-T kompatibel ist.

Windows Server 2003 unterstützt IPSec NAT-T wie beschrieben durch Version 2 der IPSec NAT-T Internetentwürfe,
aber manche Anwendungen funktionieren nicht, wenn ihr Datenverkehr zuerst mit IPSec geschützt wird und dann
durch einen NAT geleitet wird. Testen Sie in einer Übungsumgebung, wie Ihre geplanten Implementierungen von
IPSec mit NAT zusammenarbeiten, bevor Sie IPSec in Ihrer Umgebung einführen.

Wenn möglich, bestätigen Sie, dass IPSec richtig zwischen zwei Computern auf der gleichen Seite dieses NAT-
Servers funktioniert. Wenn das Problem fortbesteht, hat es vielleicht nicht mit NAT-T zu tun. Bestätigen Sie, dass
der NAT-Server keine Pakete filtert, die für IPSec notwendig sind, wie im Abschnitt Problembehandlung bei Fire-
walls, Routern und Paketfiltern beschrieben wurde.

Kompatibilitätsprobleme

Die meisten Probleme, besonders Probleme, die mit der Kompatibilität mit Nicht-Windwos-Betriebssystemen zusa-
mmenhängen, können durch die Erstellung einer möglichst einfachen Richtlinie anstelle der Standardrichtlinien ge-
löst werden. Wenn Sie beispielsweise eine neue Richtlinie erstellen, verwenden Sie den IP-Sicherheitsrichtlinien-Ass-
istent, um die Standardantwortregel zu löschen. Wenn Sie dann neue Regeln hinzufügen, wählen Sie die Standardop-
tion Diese Regel spezifiziert keinen Tunnel, anstatt einen Tunnel zu erstellen.

Als nächstes bearbeiten Sie die Richtlinie, um alle bis auf eine einzige Schlüsselaustausch-Sicherheitsmethod zu ent-
fernen. Um dies zu tun, öffnen Sie die Eigenschaftenseite der Richtlinie und klicken Sie auf die Registerkarte Allge-
mein
.Klicken Sie dann auf die Schaltfläche Einstellungen und dann auf Methoden. Verwenden Sie das Dialogfeld
Sicherheitsmethoden für den Schlüsselaustausch, um alle bis auf die Option zu entfernen, welche der Zielort ak-
zeptieren wird. Verwenden Sie beispielsweise die für RFC 2049 benötigten IKE-Sicherheitsalgorithmen von DES, SHA1
und der Low (1) Diffie Hellmann Gruppe (Siehe untere Abbildung)

Bild von Seite 572

Erstellen Sie als Nächstes einen Filterliste mit einem gespiegelten Filter, der die Quelle Eigene IP-Adresse und ein
Ziel mit der IP-Adresse festlegt, mit der Sie eine IPSec-Verbindung aufbauen wollen. Konfigurieren Sie dann die Filter-
liste nur für ICMP-Verkehr. Erstellen Sie eine neue Filteraktion zur Sicherheitsaushandlung mit nur einer Sicherheits-
methode. Verwenden Sie beispielsweise die für RFC 2049 benötigten Parameter, wie das Format ESP unter der Ver-
wendung von DES mit SHA1 ohne festgelegte Gültigkeitsdauer. Stellen Sie sicher, dass beide Kontrollkästchen für
Sitzungsschlüssel mit Perfect Forward secrecy (PFS) verwenden und Unsicher Komm. mit Computern zu-
lassen
,die IPSec nicht unterstützen, nicht markiert sind. Verwenden Sie eine Authentifizierungsmethod von Vorinsta-
llierten Schlüsseln für die Regel und stellen Sie sicher, dass es keine Leerzeichen in der Zeichenkette gibt. Das Ziel
muss genau den gleichen vorinstallierten Schlüssel verwenden. Konfigurieren Sie dann das Ziel mit der gleichen Kon-
figuration, aber kehren Sie Quell- und Ziel-IP-Adresse um.

Tipp:
Wenn Sie den Datenverkehr in den IPSec-formatierten Paketen mit Netzwerkmonitor sehen möchten, verwenden Sie
Mittlere Sicherheit (AH-Format).

Wenn Sie eine IPSec-Verbindung unter Verwendung der niedrigst möglichen Einstellungen aufbauen können, ändern
Sie die Einstellungen nacheinander, um sie an Ihre Sicherheitsstandards anzupassen. Testen Sie IPSec nach jeder
Änderung. Wenn die IPSec-Verbindung fehlschlägt, haben Sie die Problemquelle identifiziert. Sie können dann ent-
weder die kompatiblen - aber evtl. weniger sicheren - Einstellungen eingestellt lassen oder Sie können mit den Soft-
wareherstellern zusammenarbeiten, um die Kompatibilität der IPSec-Implementierungen zu verbessern.

Erstellt von: Haßlinger Stefan
Im: Jahr 2006