VPN 2003 Server mit IPSEC und L2TP
Hallo liebe Forenmitglieder,
ich habe da ein kleines Problem mit meinem VPN Server (Win2003 Server) zuhause der hinter einem Netgear DG834 Router steht.
Ich habe soweit alles eingerichtet die Zertifizierungsdienste etc. auch richtig konfiguiert (Meiner Meinung nach). Der Internet-Client nimmt auch das richtige Zertifikat aus seinem Speicher, allerdings dauert es am Internet-Client ewig bis die Fehlermeldung kommt das er keine Verbindung herstellen kann (Timeout). Von meiner Lokalen-Workstation aus kann ich mich mit IPSEC etc. ohne Probleme einwählen
Im Router sind alle nötigen Ports an den Server weitergeleitet (500, 1701 und 1723 UDP soweit ich weis). Der Hersteller meint laut seiner Website, dass dieser die VPN Pass-Through Technoligie besitzt. Nun bin ich allerdings stark am zweifeln ob das stimmt. Hat jemand ähnliche Erfahrung gemacht oder habe ich einen Port vergessen ? Im Ereignisprotokoll ist auch nix zu sehen das die Verbindung verweigert wird geschweige denn ein Eintrag diesbezüglich zu sehen ist sogar im Router nicht.
Kurzinfos:
- Die Einwählberechtigungen sind via RAS-Richtlinien gesetzt.
- Servername: 2003server.universum.local
- Zertifizierungsstelle xxxxxxx.homeip.net (DynDns auf win2003.Universum.local(server))
- Vom LAN aus "DFÜ"-VPN mit 192.168.0.xx erstellt (also nicht den server namen angegeben)
- Vom Internet-CLIENT aus die DynDns angegeben. (worauf auch das Zertifikat läuft für den Benutzer)
- Die Zertifikate an beiden Clients sind im Computerkonto installiert.
- Beide Rechner, der im LAN und im Internet, haben das gleiche Zertifikat installiert bekommen.
- IPSEC mit preshared Key keiner der beiden Clients war oder ist in der Domäne.
5h Googln hat mich leider auch nicht "heller" ;o) gemacht. Ich bin mit meinem Latein echt am Ende. Ich hoffe Ihr könnt mir weiterhelfen.
MFG
Nimda.E
ich habe da ein kleines Problem mit meinem VPN Server (Win2003 Server) zuhause der hinter einem Netgear DG834 Router steht.
Ich habe soweit alles eingerichtet die Zertifizierungsdienste etc. auch richtig konfiguiert (Meiner Meinung nach). Der Internet-Client nimmt auch das richtige Zertifikat aus seinem Speicher, allerdings dauert es am Internet-Client ewig bis die Fehlermeldung kommt das er keine Verbindung herstellen kann (Timeout). Von meiner Lokalen-Workstation aus kann ich mich mit IPSEC etc. ohne Probleme einwählen
Im Router sind alle nötigen Ports an den Server weitergeleitet (500, 1701 und 1723 UDP soweit ich weis). Der Hersteller meint laut seiner Website, dass dieser die VPN Pass-Through Technoligie besitzt. Nun bin ich allerdings stark am zweifeln ob das stimmt. Hat jemand ähnliche Erfahrung gemacht oder habe ich einen Port vergessen ? Im Ereignisprotokoll ist auch nix zu sehen das die Verbindung verweigert wird geschweige denn ein Eintrag diesbezüglich zu sehen ist sogar im Router nicht.
Kurzinfos:
- Die Einwählberechtigungen sind via RAS-Richtlinien gesetzt.
- Servername: 2003server.universum.local
- Zertifizierungsstelle xxxxxxx.homeip.net (DynDns auf win2003.Universum.local(server))
- Vom LAN aus "DFÜ"-VPN mit 192.168.0.xx erstellt (also nicht den server namen angegeben)
- Vom Internet-CLIENT aus die DynDns angegeben. (worauf auch das Zertifikat läuft für den Benutzer)
- Die Zertifikate an beiden Clients sind im Computerkonto installiert.
- Beide Rechner, der im LAN und im Internet, haben das gleiche Zertifikat installiert bekommen.
- IPSEC mit preshared Key keiner der beiden Clients war oder ist in der Domäne.
5h Googln hat mich leider auch nicht "heller" ;o) gemacht. Ich bin mit meinem Latein echt am Ende. Ich hoffe Ihr könnt mir weiterhelfen.
MFG
Nimda.E
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3739
Url: https://administrator.de/contentid/3739
Ausgedruckt am: 05.11.2024 um 21:11 Uhr
24 Kommentare
Neuester Kommentar
Hallo Nimda, ich bin heute zufällig über einen neuen Knowledgebaseartikel gestolpert, der von einer Änderung von IPSec bei Windows XP mit SP2 über NAT-T und Problemen damit berichtet... schau Dir das mal an
http://support.microsoft.com/default.aspx?scid=kb;en-us;885348
hältst Du mich über Deine Lösung am Laufenden? Mich interssiert das nämlich, danke.
Grüße
A.
http://support.microsoft.com/default.aspx?scid=kb;en-us;885348
hältst Du mich über Deine Lösung am Laufenden? Mich interssiert das nämlich, danke.
Grüße
A.
Hallo,
ich hatte dasselbe Problem. Das einwählen über das intern Interface klappte problemlos. Als es dann aber ums einwählen über Internet ging, klappte es nicht mehr. Auf dem Internet Interface waren nur die Ports 500, 1701 und 4500 geöffnet.
Danach hab ich im Netzwerkmonitor festgestellt, dass eine weiter Anfrage des Clients plötzlich mit Source Port 2296 und Destination 4500 kam. Diesen Filter hab ich dann auch beim Inbound hinzugefügt und danach klappte die VPN einwahl. Kann nun nicht bestätigen ob dieser Port dann bleibt, aber ich befürchte, dass dieser wechselt...
Ich hoffe das hilft weiter.
Gruss Martin
ich hatte dasselbe Problem. Das einwählen über das intern Interface klappte problemlos. Als es dann aber ums einwählen über Internet ging, klappte es nicht mehr. Auf dem Internet Interface waren nur die Ports 500, 1701 und 4500 geöffnet.
Danach hab ich im Netzwerkmonitor festgestellt, dass eine weiter Anfrage des Clients plötzlich mit Source Port 2296 und Destination 4500 kam. Diesen Filter hab ich dann auch beim Inbound hinzugefügt und danach klappte die VPN einwahl. Kann nun nicht bestätigen ob dieser Port dann bleibt, aber ich befürchte, dass dieser wechselt...
Ich hoffe das hilft weiter.
Gruss Martin
Sorry, ich meinte auf dem Win XP Client muss das SP2 oder der NAT-T Patch installiert sein. Und wie oben beschrieben muss nach der Installation von SP2 auf dem XP Client das NAT-T wieder aktiviert werden. Aber ich bin noch am googlen warum der port dann wechselt. Mein client sitz hinter einem NAT, aber dies sollte keine Rolle spielen.
Ich hatte auch Glück, zum testen, hab ich mal beim Server alles durchgelassen von den Filternregel her, und es passierte nix Als dann die Einwahl klappte, hab ich den Netzwerkmonitor zur Hand genommen.
Ich hatte auch Glück, zum testen, hab ich mal beim Server alles durchgelassen von den Filternregel her, und es passierte nix Als dann die Einwahl klappte, hab ich den Netzwerkmonitor zur Hand genommen.
das ist doch genau was ich Dir gesagt habe.... Lies den KB Artikel zum geänderten NAT-T bei SP2! Den Server kannst lassen, wo er ist, Deine erste Fehlermeldung kam vom SPI am Netgear, die zweite wegen SP2 am Client.
Tut mir leid, daß Du Dir den Blaster eingetreten hast, aber das war völlig unnötig.
Grüße
A.
Tut mir leid, daß Du Dir den Blaster eingetreten hast, aber das war völlig unnötig.
Grüße
A.
Ich frag mich ja, warum Microsoft plötzlich so dringend von so einer Konfiguration (L2TP/IPSec über T-NAT) abrät... (der VPN Server steht doch so gut wie immer hinter einem NAT-Router...)
Ich war vor ein paar Tagen bei den Microsoft BIG Days in der VPN Session, ich schau mal ob ich in den Unterlagen was finde...
Ich war vor ein paar Tagen bei den Microsoft BIG Days in der VPN Session, ich schau mal ob ich in den Unterlagen was finde...
Ich hab nun zum Test, obwohl es ja heisst, Wert 1 kommt dann zum Einsatz, wenn nur der Server hinter einem NAT ist, den Wert auf 1 gesetzt. Und es passiert dasselbe. Wenn ich den generierten Port freigebe, klappt das Login sogleich.
Also bei mir ist der Client hinter einem NAT und der RAS Server direkt am Internet.
Also bei mir ist der Client hinter einem NAT und der RAS Server direkt am Internet.
Hier noch eini Link
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/t ...
und nun will ich als nächstes mal hinter meinem NAT einen Win2003 Server installieren, und von diesem eine NAT-T Verbindung zum Server aufbauen.
Weil ich finde es kann kaum am Server liegen, wenn der Client mit merkwürdigen Portnummern anstatt 4500 Kommunizieren will.
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/t ...
und nun will ich als nächstes mal hinter meinem NAT einen Win2003 Server installieren, und von diesem eine NAT-T Verbindung zum Server aufbauen.
Weil ich finde es kann kaum am Server liegen, wenn der Client mit merkwürdigen Portnummern anstatt 4500 Kommunizieren will.
Hi
ich vermute ich habe das selbe Problem.
Habe ich euch richtig verstanden ich setze in der Registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec\AssumeUDPEncapsulationContextOnSendRule auf den Wert 2
am Server (Windows 2003 Server SP1) und am Client Windows XP SP 2
danach sollte es tun oder ?
und habe ich Nimda.E richtig verstanden ich kann das praktisch nicht aus dem lokalen netz testen weil genau das habe ich eben versucht.
ich vermute ich habe das selbe Problem.
Habe ich euch richtig verstanden ich setze in der Registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec\AssumeUDPEncapsulationContextOnSendRule auf den Wert 2
am Server (Windows 2003 Server SP1) und am Client Windows XP SP 2
danach sollte es tun oder ?
und habe ich Nimda.E richtig verstanden ich kann das praktisch nicht aus dem lokalen netz testen weil genau das habe ich eben versucht.
Hallo Kollegen,
ja jetzt gehts auch bei mir.
DANke, Danke
Gruß
RKO
http://support.microsoft.com/kb/818043/de
habs so eingestellt
IPsec NAT-T- und Firewall-Regeln
Da die Unterstützung für die IPsec NAT-T-Funktionalität auf IETF RFC 3193 und Version 2 der ursprünglichen IETF-NAT-T Internet Drafts basiert, müssen Sie in den Firewall-Regeln die folgenden Ports und Protokolle öffnen bzw. zulassen, damit diese Dienste durch eine Firewall ausgeführt werden können:
• Internet Key Exchange (IKE) – UDP-Port 500
• IPsec NAT-T – UDP-Port 4500
• Encapsulating Security Payload (ESP) – IP-Protokoll 50
und Wert 2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Gehen Sie folgendermaßen vor, um den Registrierungswert AssumeUDPEncapsulationContextOnSendRule zu erstellen und zu konfigurieren: 1. Klicken Sie auf Start und auf Ausführen, geben Sie regedit ein, und klicken Sie auf OK.
2. Klicken Sie auf den folgenden Unterschlüssel in der Registrierung:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec
3. Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie auf DWORD-Wert.
4. Geben Sie in das Feld Neuer Wert #1 den Namen AssumeUDPEncapsulationContextOnSendRule ein, und drücken Sie die [EINGABETASTE].
5. Klicken Sie mit der rechten Maustaste auf AssumeUDPEncapsulationContextOnSendRule, und klicken Sie auf Ändern.
6. Geben Sie in das Feld Wert einen der folgenden Werte ein: • 0 (Standard)
Mit dem Wert 0 (Null) wird Windows so konfiguriert, dass keine Sicherheitszuordnungen mit Servern eingerichtet werden können, die sich hinter NATs befinden.
• 1
Mit dem Wert 1 wird Windows so konfiguriert, dass Sicherheitszuordnungen mit Servern eingerichtet werden können, die sich hinter NATs befinden.
• 2
Mit dem Wert 2 wird Windows so konfiguriert, dass Sicherheitszuordnungen eingerichtet werden können, wenn sich sowohl der Server als auch der Windows XP SP2-Clientcomputer hinter NATs befinden.
7. Klicken Sie auf OK, und beenden Sie den Registrierungseditor.
8. Starten Sie den Computer neu.
ja jetzt gehts auch bei mir.
DANke, Danke
Gruß
RKO
http://support.microsoft.com/kb/818043/de
habs so eingestellt
IPsec NAT-T- und Firewall-Regeln
Da die Unterstützung für die IPsec NAT-T-Funktionalität auf IETF RFC 3193 und Version 2 der ursprünglichen IETF-NAT-T Internet Drafts basiert, müssen Sie in den Firewall-Regeln die folgenden Ports und Protokolle öffnen bzw. zulassen, damit diese Dienste durch eine Firewall ausgeführt werden können:
• Internet Key Exchange (IKE) – UDP-Port 500
• IPsec NAT-T – UDP-Port 4500
• Encapsulating Security Payload (ESP) – IP-Protokoll 50
und Wert 2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Gehen Sie folgendermaßen vor, um den Registrierungswert AssumeUDPEncapsulationContextOnSendRule zu erstellen und zu konfigurieren: 1. Klicken Sie auf Start und auf Ausführen, geben Sie regedit ein, und klicken Sie auf OK.
2. Klicken Sie auf den folgenden Unterschlüssel in der Registrierung:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec
3. Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie auf DWORD-Wert.
4. Geben Sie in das Feld Neuer Wert #1 den Namen AssumeUDPEncapsulationContextOnSendRule ein, und drücken Sie die [EINGABETASTE].
5. Klicken Sie mit der rechten Maustaste auf AssumeUDPEncapsulationContextOnSendRule, und klicken Sie auf Ändern.
6. Geben Sie in das Feld Wert einen der folgenden Werte ein: • 0 (Standard)
Mit dem Wert 0 (Null) wird Windows so konfiguriert, dass keine Sicherheitszuordnungen mit Servern eingerichtet werden können, die sich hinter NATs befinden.
• 1
Mit dem Wert 1 wird Windows so konfiguriert, dass Sicherheitszuordnungen mit Servern eingerichtet werden können, die sich hinter NATs befinden.
• 2
Mit dem Wert 2 wird Windows so konfiguriert, dass Sicherheitszuordnungen eingerichtet werden können, wenn sich sowohl der Server als auch der Windows XP SP2-Clientcomputer hinter NATs befinden.
7. Klicken Sie auf OK, und beenden Sie den Registrierungseditor.
8. Starten Sie den Computer neu.
Hallo zusammen,
ich habe die Einstellungen wie im Thread diskutiert vorgenommen. Habe die Regedit Einstellungen auf unserem SBS 2003 und den WindowsXP Workstations eingestellt (Wert 2).
Danach habe ich aus dem Firmennetzwerk die Verbindung erfolgreich testen können.
Soweit so gut. Nun habe ich aber mein Notebook mit genommen und versucht mich von zuhause einzuloggen.
Dabei bekomme ich leider die folgende Fehlermeldung:
Benutzername und Kennwort werden verifiziert...
Fehler 0x8009030C: Der Anmeldeversuch ist fehlgeschlagen
Kann mir da jemand weiter helfen? Hatte mich schon zu früh gefreut, das unser VPN Zugang funktioniert.
Dank,
Joergy
P.S.:
NACHTRAG:
Heute morgen habe ich einen direkten internen Zugriff auf den SBS 20003 probiert. Und dort habe ich die gleiche Fehlermeldung bekommen. Jetzt geht der Zugriff nicht mehr!? Diese hat aber definitiv noch letzte Woche geklappt.
Hier mal die Infos aus System-Ergebnisanzeige:
Quelle: RemoteAccess
Ergebniskennung: 20189
Beschreibung:
Der Benutzer "xxx@xxx.local", der eine Verbindung mit xxx.xxx.xxx.xxx hergestellt hat, hat sich aus folgendem Grund nicht authentifiziert: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.
Habe diesbezüglich auch schon ein wenig gegoogelt. Und die Einstellungen wie unter http://support.microsoft.com/?scid=kb%3Bde%3B266460&x=12&y=11 geändert. Also noch einen Haken bei Ethernet aktiviert. Hat leider nichts gebracht.
Kennt jemand dieses Problem bzw. hat jemand dafür eine Lösung.
Danke,
Joergy
ich habe die Einstellungen wie im Thread diskutiert vorgenommen. Habe die Regedit Einstellungen auf unserem SBS 2003 und den WindowsXP Workstations eingestellt (Wert 2).
Danach habe ich aus dem Firmennetzwerk die Verbindung erfolgreich testen können.
Soweit so gut. Nun habe ich aber mein Notebook mit genommen und versucht mich von zuhause einzuloggen.
Dabei bekomme ich leider die folgende Fehlermeldung:
Benutzername und Kennwort werden verifiziert...
Fehler 0x8009030C: Der Anmeldeversuch ist fehlgeschlagen
Kann mir da jemand weiter helfen? Hatte mich schon zu früh gefreut, das unser VPN Zugang funktioniert.
Dank,
Joergy
P.S.:
NACHTRAG:
Heute morgen habe ich einen direkten internen Zugriff auf den SBS 20003 probiert. Und dort habe ich die gleiche Fehlermeldung bekommen. Jetzt geht der Zugriff nicht mehr!? Diese hat aber definitiv noch letzte Woche geklappt.
Hier mal die Infos aus System-Ergebnisanzeige:
Quelle: RemoteAccess
Ergebniskennung: 20189
Beschreibung:
Der Benutzer "xxx@xxx.local", der eine Verbindung mit xxx.xxx.xxx.xxx hergestellt hat, hat sich aus folgendem Grund nicht authentifiziert: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.
Habe diesbezüglich auch schon ein wenig gegoogelt. Und die Einstellungen wie unter http://support.microsoft.com/?scid=kb%3Bde%3B266460&x=12&y=11 geändert. Also noch einen Haken bei Ethernet aktiviert. Hat leider nichts gebracht.
Kennt jemand dieses Problem bzw. hat jemand dafür eine Lösung.
Danke,
Joergy