Windows Server 2003 IPSec-Tunnel verbunden, funktioniert aber nicht (möglicherweise im Zusammenhang mit NAT/RRAS)

Question

Aufbau

Ich habe einen "rohen" IPSec-Tunnel zwischen einem Windows Server 2003 (SBS)-Rechner und einem Netgear FVG318 gemäß den Anweisungen in MicrosoftKB816514Die Konfiguration ist wie folgt (unter Verwendung der gleichen Konventionen wie im Artikel):

NetA         | SBS2003   | FVG318   | NetB
10.0.0.0/24  | 216.x.x.x | 69.y.y.y | 10.0.254.0/24

Sowohl die Hauptmodus- als auch die Schnellmodus-Sicherheitszuordnungen werden erfolgreich abgeschlossen und erscheinen im IP-Sicherheitsmonitor. Ich kann den SBS2003-Server auch von jedem Computer im NetB aus an seine private Adresse anpingen.

Das Problem

Jeglicher Datenverkehr von einem Computer auf NetA zu NetB oder von SBS2003 zu NetB (ausgenommen ICMP-Ping)Antworten), wird über die öffentliche Netzwerkschnittstelle außerhalb des IPSec-Tunnels gesendet (keine Verschlüsselung oder Header-Authentifizierung, als ob der Tunnel nicht vorhanden wäre).

Von einem Computer auf NetB an einen Computer auf NetA gesendete Pings erreichen die Computer auf NetA erfolgreich, die Antworten werden von SBS2003 jedoch stillschweigend verworfen (sie werden nicht im Klartext übermittelt und erzeugen keinen verschlüsselten Datenverkehr).

Mögliche Lösungen

Falsche Konfiguration

Ich könnte irgendwo einen Tippfehler gemacht haben, oder KB816514 könnte irgendwie falsch sein. Ich habe mir große Mühe gegeben, die erste Option auszuschließen. Ich habe die Konfiguration mehrmals neu erstellt und versucht, alle möglichen Einstellungen zu optimieren und anzupassen, ohne Erfolg (die meisten verhindern die Einrichtung der SA).

NAT/RRAS

Ich habe an anderer Stelle mehrere Beiträge gesehen, die darauf hindeuten, dass dies an einer Interaktion zwischen NAT und den IPSec-Filtern liegen könnte. Möglicherweise werden die privaten NetA-Adressen vor dem Vergleich mit den Quick Mode IPSec-Filtern auf 216.xxx umgeschrieben und aufgrund der Nichtübereinstimmung nicht getunnelt. Tatsächlich legt der Artikel „TCP/IP Packet Processing Paths“ von The Cable Guy vom Juni 2005 nahe, dass dies der Fall ist (siehe Schritt 2 und 4 des Transit Traffic-Pfads). Wenn dies der Fall ist, gibt es dann eine Möglichkeit, NetA->NetB-Verkehr von NAT auszuschließen?

Alle Gedanken, Ideen, Vorschläge und/oder Kommentare sind willkommen.

Aktualisierung (26.06.2011)

Nachdem ich das Problem nicht lösen konnte, habe ich den kostenpflichtigen Microsoft-Support in Anspruch genommen. Sie konnten das Problem nicht lösen. Seitdem habe ich eine auf Linux basierende Lösung implementiert, die recht gut funktioniert. Ich werde versuchen, alle vorgeschlagenen Antworten so gut wie möglich zu bewerten, aber die aktuellen Konfigurationen und Zeitbeschränkungen werden dies verlangsamen ...

Answer 1

Überprüfen Sie Ihre Bindungsreihenfolge. Netzwerkeigenschaften > Erweitert > Erweiterte Einstellungen. Verschieben Sie die Option, über die das Routing erfolgen soll, nach oben.