Teil 6 – Abschnitt G:  Weitere Tools zum TroubleshootingEinrichten einer L2TP/IPSec Verbindung mit Zertifikaten

Teil 6 – Abschnitt H: L2TP, Firewalls und NAT

Autor: Claus Greck [MVP], MCSEboard.de

L2TP und Firewalls

L2TP bietet selber ja keine Verschlüsselung an, sondern bedient sich des Protokolls IPSec.

IPSec funktioniert so lange gut, bis die Pakete eine Firewall zu passieren haben. Dann ist in der Regel Schluss, wenn keine entsprechenden Filter gesetzt sind.

Man benötigt für den L2TP/IPSec-Verkehr auf der Firewall folgende Paketfilter:

  • Port 500    UDP
  • Port 4500  UDP (bei NAT, siehe auch unten)
  • Protokollkennung 50 für ESP-Verschlüsselung

Man beachte den Filter für die ESP-Pakete: das Protokoll 50 NICHT den Port 50. Ein ESP-verschlüsseltes Paket sieht so aus:

Abb. 1
Abb. 2

Wem das nichts sagt, hier ein Screenshot eines ESP-Pakets mit dem Netzwerkmonitors betrachtet. Man kann deutlich erkennen, dass oberhalb des IP-Headers nur noch ein ESP-Header kommt, kein TCP-Header, kein UDP-Header, folglich auch keine Ziel- oder Quellportangabe.

Da Firewalls normalerweise  IP-Verkehr gemäß den eingetragenen Regeln an Hand von TCP- oder UDP-Ports zulassen, ist das bei ESP-Paketen nicht möglich. Daher muss die Firewall für die Protokollnummer 50 geöffnet werden, welche im IP-Header im Feld Protocol eingetragen ist. Dies nennt man auch VPN-Passthrough, die verschlüsselten IP-Pakete ohne TCP- oder UDP-Header anhand der vordefinierten Protokollnummern nicht zu verwerfen, sondern weiterzuleiten (gilt auch für PPTP, dort sind es GRE-Pakete mit der Protokollnummer47).

Wie das bei der einzelnen Firewall einzustellen ist bzw. ob das die Firewall überhaupt unterstützt ist den Datenblättern und Handbüchern des jeweiligen Modells zu entnehmen.

Anmerkung: Ich habe bei der Aufzählung der an der Firewall zu öffnenden Ports den Port 1701 nicht vergessen. Den braucht man dort nicht zu öffnen. Die IPSec-Pakete benötigen nur die oben angegeben Ports. Der Port 1701 wird für den L2TP-Header gebraucht, der wie in der obigen Grafik zu sehen, mit eingekapselt ist. Man muss nur dann eine Filterregel für den Port 1701 erstellen, wenn auf dem VPN-Server selber Pakete gefiltert werden, z.B. ein ISA-Server ist gleichzeitig VPN-Server oder im Routing und RAS-Dienst des VPN-Servers sind Paketfilter gesetzt. (Vgl. auch: www.microsoft.com/resources/documentation/WindowsServ/2003/datacenter/proddocs/en-us/Default.asp)

L2TP und NAT

Wenn alles ordnungsgemäß installiert und konfiguriert ist, sollte es mit einer L2TP/IPSec Verbindung keine Probleme geben. Die meisten Personen, die sich Hilfe suchend an Newsgroups oder Foren wenden, berichten auch, dass sie im LAN die L2TP-Verbindung problemlos aufbauen können, der Verbindungsaufbau über das Internet zum selben VPN-Server dann aber scheitert.

Die Hauptursache hierfür liegt neben nicht geöffneten Ports, oder keiner VPN-Passthrough-Unterstützung, bei NAT (Network Address Translation). Entweder sitzt dann der VPN-Client, oder der VPN-Server, oder beide, hinter einem Router, der auch Firewallfunktionalität haben kann, und der die Absender IP-Adresse oder die Ziel-IP-Adresse ändert.

Problemszenario: VPN-Server hinter NAT-Gerät

(die öffentlichen IP-Adressen im Szenario sind frei gewählt!)

Abb. 3

Ein typisches Szenario. Der VPN-Server steht hinter einer Firewall, die auch NAT macht, der Client ist direkt mit dem Internet verbunden. Die externe Schnittstelle der Firewall und der VPN-Client haben öffentliche IP-Adressen.

Um den Tunnel zum VPN-Server aufzubauen, muss in den Eigenschaften des VPN-Clients als Ziel die öffentliche IP-Adresse der Firewall am VPN-Server angegeben werden, hier die 213.84.1.17, nur diese Adresse erreicht der Client aus dem Internet. Die Firewall leitet das Paket nach hinten zum VPN-Server weiter und muss natürlich die Ziel IP-Adresse auf 10.1.1.1 ändern.

Abb. 4

Das ist im Netzwerkmonitor sehr schön zu sehen. Das Bild zeigt das Paket, wie es auf dem VPN-Server ankommt:

Die Zieladresse im empfangenen IP-Header lautet 10.1.1.1, der Client hatte aber für den Tunnelaufbau notwendigerweise die 213.84.1.17 als Zieladresse in den IP-Header eingetragen gehabt.

Das Problem, dass sich daraus ergibt ist folgendes: Der VPN-Client bezieht  in der Berechnung des miteingekapselten Hashs, der vor dem Ändern der Daten unterwegs schützen soll, auch den IP-Header mit ein. Die Felder TOF (Type of Service) und TTL (Time To Live) werden nicht in die Berechnung mit einbezogen. Der VPN-Server berechnet beim Empfang selber den Hash und vergleicht ihn mit dem mitgelieferten Hash, um festzustellen, ob die Daten unterwegs manipuliert wurden. Solch eine Manipulation ist aus seiner Sicht passiert, denn die Ziel IP-Adresse ist eine andere, als diejenige, die der Client eingetragen hatte. Somit hat er ein ungültiges Paket erhalten.

Abb. 5

Der folgende Ausschnitt aus dem Oakley Log (s.a.  Teil 6 –Abschnitt G: Weitere Tools zum Troubleshooting) zeigt auch diesen "Fehler" auf:

Damit schlägt letztlich die Tunnelaushandlung fehl.

Der zugehörige Eintrag im Ereignisprotokoll sieht so aus (s.a.  Teil 6 –Abschnitt G: Weitere Tools zum Troubleshooting):

----------------------------------------------------------------------------

Ereignistyp: Erfolgsüberw.
Ereignisquelle: Security
Ereigniskategorie: An-/Abmeldung
Ereigniskennung: 547
Datum: 21.07.2004
Zeit: 10:29:55
Benutzer: NT-AUTORITÄTNETZWERKDIENST
Computer: VPN-SRV
 Beschreibung:
IKE-Sicherheitszuordnung konnte nicht ausgehandelt werden.
 Modus:
Datenschutzmodus (Schnellmodus)

 Filter:
Quell-IP-Adresse 213.84.1.17
Quell-IP-Adressmaske 255.255.255.255
Ziel-IP-Adresse 83.195.227.32
Ziel-IP-Adressmaske 255.255.255.255
Protokoll 17
Quellport 0
Zielport 1701
Lokale IKE-Adresse 10.1.1.1
Peer-IKE-Adresse 83.195.227.32
IKE-Quellport 500
IKE-Zielport 500
Private Peeradresse

----------------------------------------------------------------------------

Abb. 6

Im IPSicherheitsmonitor findet man schlicht das hier (s.a.  Teil 6 –Abschnitt G: Weitere Tools zum Troubleshooting):

Problemszenario: VPN-Server hinter NAT-Gerät

(die öffentlichen IP-Adressen im Szenario sind frei gewählt!)

Das zweite Szenario führt  im Prinzip auf dasselbe Problem als Ursache für einen Fehlschlag beim Tunnelaufbau. Der VPN-Client sitzt hinter einem NAT-Gerät, der VPN-Server ist direkt ans Internet angeschlossen.

Abb. 7
Abb. 8

Der Client stellt eine Verbindung zur Ziel IP-Adresse 194.1.23.18 her, und trägt im IP-Header als Absender IP-Adresse die 192.168.1.100 ein. Beide Werte gehen auch hier in den bereits beschriebenen, miteingekapselten  Hash ein.

Das Paket, das beim Server ankommt, sieht dann so aus.

Wiederum ist das Problem sehr schön zu sehen, die Absender IP-Adresse ist diejenige des NAT-Geräts am VPN-Client, und nicht mehr die vom VPN-Client selber. Der vom VPN-Server gegengerechnete Hash stimmt mit dem miteingekapselten Hash nicht überein, aus Sicht des VPN-Server ist das Paket unterwegs manipuliert worden, die Tunnelaushandlung schlägt fehl.

Abb. 9

Auch hier findet sich der entsprechende Hinweis im Oakley Log (s.a. Teil 6 –Abschnitt G: Weitere Tools zum Troubleshooting):

Und auch hier gibt es einen Fehlüberwachungs-Eintrag im Ereignisprotokoll (s.a.  Teil 6 –Abschnitt G: Weitere Tools zum Troubleshooting):

----------------------------------------------------------------------------

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: An-/Abmeldung
Ereigniskennung: 547
Datum: 21.07.2004
Zeit: 11:41:15
Benutzer: NT-AUTORITÄTNETZWERKDIENST
Computer: VPN-SRV
 Beschreibung:
KE-Sicherheitszuordnung konnte nicht ausgehandelt werden.
 Modus:
Datenschutzmodus (Schnellmodus)

 Filter:
Quell-IP-Adresse 194.1.23.18
Quell-IP-Adressmaske 255.255.255.255
Ziel-IP-Adresse 192.168.1.100
Ziel-IP-Adressmaske 255.255.255.255
Protokoll 17
Quellport 0
Zielport 1701
Lokale IKE-Adresse 194.1.23.18
Peer-IKE-Adresse 62.174.88.212
IKE-Quellport 500
IKE-Zielport 1025
Private Peeradresse

 Peeridentität:
Zertifikatbasierte Identität.
Peerantragsteller CN=VPN-Client
Peer-SHA-Fingerabdruck 47440f3c373ffaac656df97486fede4ffdb957f4
Peer, der die Zertifizierungsstelle ausstellt: CN=Grizzly's Root CA
Stammzertifizierungsstelle CN=Grizzly's Root CA
Eigener Antragsteller CN=VPN-Server
Eigener SHA-Fingerabdruck d63b93f370a1fe3b1fdb3565de20b070437e0cdb
Peer-IP-Adresse: 62.174.88.212

 Fehlerpunkt:
Benutzer

 Fehlerursache:
Keine Richtlinie konfiguriert.

Zusätzlicher Status:
Als drittes verarbeitete Nutzlast (ID)
Antwort. Wartezeit 0
0x0 0x0

----------------------------------------------------------------------------

Wenn sich beide Tunnelpartner hinter einem NAT-Gerät befinden, hat man logischerweise das gleiche Problem.

Die Lösung: NAT-T (NAT Traversal)

Das in den beiden Szenarien demonstrierte Problem ist kein Microsoft-spezifisches, sondern ein allgemeines, und betrifft alle Geräte aller Hersteller, die IPSec-Geräte sein können. Es ist ein "Problem" des Protokolls. Was eigentlich erwünscht ist, nämlich durch den miteingekapselten Hash die Integrität der Daten sicher zu stellen, wird bei NAT zum Hindernisgrund für einen Tunnelaufbau.

Deswegen hat die  IETF im RFC 3193 NAT-T oder  NAT Traversal spezifiziert.

Bei NAT-T stellen die Tunnelpartner fest, dass sich einer der beiden hinter einem NAT-Gerät befindet.

Ich will die Änderungen, die NAT-T an den IPSec-Paketen vornimmt, nicht ausführlich besprechen, das kann man auf Thomas Shinder's  Isaserver.org Seite gut nachlesen. In Kurzform: anstatt die Pakete als ungültig zu verwerfen, fügt der VPN-Client einen UDP-Header mit Zielport 4500 an. Der IP-Header wird nicht mehr in den Hash mit einbezogen und kann daher geändert werden, die Pakete werden als gültig angesehen.

Die meisten Hersteller von IPSec-fähigen Geräten haben auf NAT-T reagiert und Anpassungen ihrer Produkte vorgenommen, auch Microsoft. Es gibt ein Update für Windows 2000 und Windows XP SP1, den zugehörigen KB-Artikel findet man hier: support.microsoft.com/default.aspx

Allerdings erweitert  dieser Patch nur die VPN-Client Fähigkeiten hinsichtlich NAT-T, nicht die des VPN-Servers.

Serverseitig ist die Fähigkeit für NAT-T bereits implementiert, aber NUR für Windows Server 2003. Das bedeutet, ein Windows 2000 Server als VPN-Server mit L2TP/IPsec, bei dem sich mindestens einer der Computer hinter einem NAT-Gerät befindet, kann nicht verwendet werden, und es gibt zum Zeitpunkt der Erstellung dieses Artikels kein Update dafür.

Hinweis: Da der Patch kein Wichtiges Update ist, sondern nur ein Empfohlenes Update, wird er nicht vom SUS-Server heruntergeladen und verteilt. Es gibt ihn als manuellen Download auf der Windows Update-Katalog Seite.

Abb. 10

Wenn der Patch auf dem VPN-Client eingespielt und der Computer neu gestartet ist, sollte die Tunnelaushandlung erfolgreich verlaufen.

Im Netzwerkmonitor sieht das jetzt so aus:

Abb. 11

Die ESP-Pakete haben den zusätzlichen UDP-Header mit Zielport 4500:

Im Sicherheitsprotokoll der Ereignisanzeige findet man zwei Erfolgsüberwachungen für die Aushandlung der SA Aushandlung Phase I (Main Mode) …..:

----------------------------------------------------------------------------

Ereignistyp: Erfolgsüberw.
Ereignisquelle: Security
Ereigniskategorie: An-/Abmeldung
Ereigniskennung: 541
Datum: 21.07.2004
Zeit: 13:10:38
Benutzer: NT-AUTORITÄTNETZWERKDIENST
Computer: VPN-SRV
 Beschreibung:
IKE-Sicherheitszuordnung wurde hergestellt.
 Modus:
Schlüsselaustauschmodus (Hauptmodus)

 Peerkennung:
Zertifikatbasierte Identität.
Peerantragsteller CN=VPN-Client
Peer-SHA-Fingerabdruck 47440f3c373ffaac656df97486fede4ffdb957f4
Peer, der die Zertifizierungsstelle ausstellt: CN=Grizzly's Root CA
Stammzertifizierungsstelle CN=Grizzly's Root CA
Eigener Antragsteller CN=VPN-Server
Eigener SHA-Fingerabdruck d63b93f370a1fe3b1fdb3565de20b070437e0cdb
Peer-IP-Adresse: 62.174.88.212

 Filter:
Quell-IP-Adresse 194.1.23.18
Quell-IP-Adressmaske 255.255.255.255
Ziel-IP-Adresse 62.174.88.212
Ziel-IP-Adressmaske 255.255.255.255
Protokoll 0
Quellport 0
Zielport 0
Lokale IKE-Adresse 194.1.23.18
Peer-IKE-Adresse 62.174.88.212
IKE-Quellport 4500
IKE-Zielport 0
Private Peeradresse

 Parameter:
ESP-Algorithmus Dreifach-DES CBC
HMAC-Algorithmus SHA
Gültigkeitsdauer (Sek.) 28800
MM-Wartezeit (Sek.) 0

---------------------------------------------------------------------------

und der Phase II (Quick Mode):

----------------------------------------------------------------------------

Ereignistyp: Erfolgsüberw.
Ereignisquelle: Security
Ereigniskategorie: An-/Abmeldung
Ereigniskennung: 541
Datum: 21.07.2004
Zeit: 13:10:38
Benutzer: NT-AUTORITÄTNETZWERKDIENST
Computer: VPN-SRV
 Beschreibung:
IKE-Sicherheitszuordnung wurde hergestellt.
 Modus:
Datenschutzmodus (Schnellmodus)

 Peerkennung:
Zertifikatbasierte Identität.
Peerantragsteller CN=VPN-Client
Peer-SHA-Fingerabdruck 47440f3c373ffaac656df97486fede4ffdb957f4
Peer, der die Zertifizierungsstelle ausstellt: CN=Grizzly's Root CA
Stammzertifizierungsstelle CN=Grizzly's Root CA
Eigener Antragsteller CN=VPN-Server
Eigener SHA-Fingerabdruck d63b93f370a1fe3b1fdb3565de20b070437e0cdb
Peer-IP-Adresse: 62.174.88.212

 Filter:
Quell-IP-Adresse 194.1.23.18
Quell-IP-Adressmaske 255.255.255.255
Ziel-IP-Adresse 62.174.88.212
Ziel-IP-Adressmaske 255.255.255.255
Protokoll 17
Quellport 1701
Zielport 1701
Lokale IKE-Adresse 194.1.23.18
Peer-IKE-Adresse 62.174.88.212
IKE-Quellport 4500
IKE-Zielport 1028
Private Peeradresse 192.168.1.100

 Parameter:
ESP-Algorithmus Dreifach-DES CBC
HMAC-Algorithmus MD5
AH-Algorithmus Kein
Kapselung Transportmodus mit UDP-Kapselung

Eingehender SPI 1620567741 (0x6097e6bd)
Ausgehender SPI 2499692008 (0x94fe45e8)
Gültigkeitsdauer (Sek.) 3600
Gültigkeitsdauer (KB) 250000
QM-Wartezeit (Sek.) 0
Wartezeit insgesamt (Sek.) 0

----------------------------------------------------------------------------

Abb. 12

Im IPSicherheitsmonitor tauchen keine Aushandlungsfehler auf, dafür vorhandene Sicherheitszuordnungen im Hauptmodus und Schnellmodus.

Und auch das Oakley Log ist nun frei von Fehlern.

© MCSEboard.de, Claus Greck [MVP]

Teil 6 – Abschnitt G:  Weitere Tools zum TroubleshootingEinrichten einer L2TP/IPSec Verbindung mit Zertifikaten