Die nicht ausreichende Anzahl von öffentlich gültigen IP-Adressen hat zur Entwicklung von Verfahren wie IP-Masquerading oder NAT (Network Address Translation) geführt, bei denen ein ganzes lokales Netzwerk hinter einer einzigen, öffentlich gültigen IP-Adresse maskiert wird. Auf diese Weise nutzen alle Clients in einem LAN die gleiche IP-Adresse beim Datenaustausch mit öffentlichen Netzwerken wie dem Internet. Die Zuordnung der ein- und ausgehenden Datenpakete zu den verschiedenen Teilnehmern im Netz wird dabei über eine Verbindung der internen IP-Adressen zu entsprechenden Port-Nummern gewährleistet.
Dieses Verfahren hat sich bewährt und ist mittlerweile Standard in nahezu allen Internet-Routern. Neue Schwierigkeiten in der Verarbeitung der maskierten Datenpakete treten jedoch bei der Verwendung von VPN auf. Da Datenverbindungen über VPN sehr stark gesichert sind, kommen Mechanismen wie Authentifizierung und Verschlüsselung hier hohe Bedeutung zu.
Die Umsetzung der internen IP-Adressen auf die zentrale, öffentlich gültige IP-Adresse des Gateways sowie die Umsetzung von Quell- und Zielports kann in manchen Anwendungen zu Problemen führen, weil dabei z. B. der üblicherweise während der IKE-Verhandlung verwendete UDP-Port 500 verändert wird und die IKE-Verhandlung somit nicht mehr erfolgreich abgeschlossen werden kann. Die Adressänderung über NAT wird also von einem VPN-Gateway als sicherheitskritische Veränderung der Datenpakete gewertet, die VPN-Verhandlung scheitert, es kommt keine Verbindung zustande. Konkret treten diese Probleme z. B. bei der Einwahl über manche Mobilfunknetze auf, bei denen die Server des Netzbetreibers die Adress-Umsetzung in Verbindung mit IPSec-basierten VPNs nicht unterstützen.
Um auch in diesen Fällen eine VPN-Verbindung erfolgreich aufbauen zu können, steht mit NAT-T (NAT Traversal) ein Verfahren bereit, die beschriebenen Probleme bei der Behandlung von Datenpaketen mit geänderten Adressen zu überwinden.
Setzt die VPN-Verbindung zur Authentifizierung AH ein, kann grundsätzlich keine Verbindung über Strecken mit Network Address Translation aufgebaut werden, da sich die AH-Hashwerte bei der Änderung der IP-Adressen ebenfalls ändern und der Empfänger die Datenpakete als nicht vertrauenswürdig einstufen würde.
Das Verfahren von NAT Traversal überwindet die Probleme beim VPN-Verbindungsaufbau an den Endpunkten der VPN-Tunnel. Folgende Szenarien lassen sich daher unterscheiden:
- Ein Aussendienstmitarbeiter wählt sich mit einem LANCOM
Advanced VPN-Client über einen Router ohne
"VPN-Pass-Through"-Unterstützung (d. h. IPSec-Maskierung), aber mit Network Address Translation in den VPN-Router
seiner Firma ein.
- Die beiden Tunnelendpunkte LANCOM Advanced VPN-Client 1 und VPN-Router 3 unterstützen das NAT-T-Verfahren und können so auch über den zwischengeschalteten Router eine VPN-Verbindung aufbauen.
- Der Router 2 macht als NAT-Gerät zwischen den VPN-Endpunkten eine reine Adress-Umsetzung. In diesem Router wird kein NAT-T benötigt, hier müssen jedoch die Ports 500 und 4500 in der Firewall freigeschaltet sein, um die NAT-T-Kommunikation der beiden Tunnelendpunkte zu ermöglichen.
- Im zweiten Anwendungsbeispiel wählt sich der Außendienstmitarbeiter von unterwegs über sein Notebook 1 und ein Mobiltelefon oder Modem 2 in das Netzwerk der Zentrale ein.
- Dabei steht in der Zentrale der VPN-Router 4 hinter einem Abschlussrouter 3, der nur den Internetzugang mit der Adressumsetzung bereitstellt.
- Die beiden Tunnelendpunkte LANCOM Advanced VPN-Client 1 und VPN-Router 4 können über das NAT-T-Verfahren wie im ersten Beispiel eine VPN-Verbindung aufbauen.
- Im Abschlussrouter 2 müssen jedoch die Ports 500 und 4500 in der Firewall freigeschaltet sein, zusätzlich muss das Port-Forwarding in diesem Router aktiviert werden.
- In der Kombination der beiden vorhergehenden Fälle stehen auf beiden Seiten der Verbindung reine NAT-Router 2 und 3. Die VPN-Strecke wird zwischen dem LANCOM Advanced VPN-Client 1 und VPN-Router 4 aufgebaut.
Um dieses Verfahren zu ermöglichen, müssen beide Seiten der VPN-Verbindung NAT-T beherrschen. Der Ablauf des VPN-Verbindungsaufbaus sieht (reduziert auf die NAT-T-relevanten Vorgänge) so aus:
- In einer frühen Phase der IKE-Verhandlung wird daher überprüft, ob die beiden Seiten der VPN-Verbindung NAT-T-fähig sind.
- Im zweiten Schritt wird dann geprüft, ob auf der Strecke zwischen den beiden Tunnelendpunkten eine Adressumsetzung nach NAT stattfindet und an welcher Stelle der Verbindung sich die NAT-Geräte befinden.
- Um die Probleme mit den möglicherweise veränderten Ports zu umgehen, werden anschließend alle Verhandlungs- und Datenpakete nur noch über den UDP-Port 4500 verschickt, sofern ein NAT-Gerät gefunden wurde. Wichtig: Achten Sie darauf, dass neben dem UDP-Port 500 auch der UDP-Port 4500 bei Verwendung von NAT-T in der Firewall freigeschaltet ist, wenn das Gerät als NAT-Router zwischen den VPN-Endpunkten fungiert! Bei Verwendung des Firewall-Assistenten in LANconfig wird dieser Port automatisch freigeschaltet.
Sofern die VPN-Verbindungen erstmals auf Geräten mit einer Firmware-Version 5.20 oder neuer mit dem VPN-Assistenten und anschließend dem Firewall-Assistenten von LANconfig angelegt werden, sind für die NAT-Router keine zusätzlichen Einstellungen an der Firewall erforderlich.
- Im folgenden werden die Datenpakete noch einmal in UDP-Pakete verpackt (UDP-Encapsulation) und ebenfalls über den Port 4500 versendet. Durch diese zusätzliche Kapselung ist die Veränderung der IP-Adressen für die VPN-Verhandlung nicht mehr relevant, der VPN-Tunnel kann ohne Probleme aufgebaut werden. Auf der Gegenseite der Verbindung werden die IP-Daten wieder vom zusätzlichen UDP-Header befreit und können ohne weiteres vom Router verarbeitet werden.
Zur Verwendung dieses Verfahrens müssen beide Seiten der VPN-Verbindung NAT-T verwenden.
Den Schalter zur Aktivierung von NAT-T finden Sie in LANconfig unter
.Unter Telnet oder SSH-Client finden Sie die Aktivierung von NAT-T unter
.