Zweigstellenrouting Server 2008 VPN via RRAS und NPS

[rt1970 10]

Hallo!

 

Ich habe ein seltsames Verhalten auf den Servern...

 

Ich richte auf 3 Servern an jeweils anderen Standorten Routing und Ras ein.

 

Die Standorte haben LAN-IP´s 192.168.2.0, 5.0 und 6.0 / 24

 

Diese werden mit PPTP verbunden.

Die Einwahl der Schnittstelle für wählen bei Bedarf funktioniert aber nur manchmal. Der Standort spielt hierbei keine Rolle. Mal hier, mal da.

Richte ich ganz normal eine VPN-Verbindung im Netzwerk- und Freigabecenter ein, funktioniert die Einwahl immer!

Auch von Clients außerhalb gibt es keine Probleme!

 

Er bleibt immer bei "Verbindungsherstellung" hängen.

 

Der Benutzer "SYSTEM" hat eine Verbindung mit dem Namen "Hauptstelle" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. ...Ursachencode:0

 

Quelle RasClient , ID 20277

 

Hat jemand hierzu eine Idee?

 

Kann es daran liegen, dass ich die WAN-Netzwerkkarte mit NAT betreibe? Hier kann ich das GRE-Protokoll nicht weiterleiten, sondern nur TCP 1723...

Konfiguration jeder Stelle: Internet -> Router mit NAT (QSC) -> Netzwerkkarte im Server 2008 "WAN" mit NAT und Portforwarding auf die IP der WAN-Schnittstelle...

bearbeitet 10. April 2014 von rt1970

[h-d.neuenfeldt 21]

eventuell ein Problem der Firewall :

 

hier am Beispiel von Win7 dargestellt :

http://www.chicagotech.net/VPN/win7vpn1.htm

[rt1970 10]

Was hat ICS mit seinem Fall zu tun gehabt? (Internet Connection Sharing oder?)

 

Was passiert, wenn ich auf dem Server im RRAS auf der WAN-Netzwerkkarte (an das Internet angeschlossene, öffentliche Schnittstelle) jetzt den Haken "NAT auf dieser Schnittstelle verwenden" raus nehme? Bleiben die Portweiterleitungen? Fliege ich aus dem Internet?

Frage deshalb, weil der Server ca. 50 km weit weg steht und ich mit Teamviewer arbeite...

[h-d.neuenfeldt 21]

ähmmm, ich würde niemals an der Leitung etwas testen, die ich benötige um den Server zu erreichen :nene: :nene: :nene:

 

Mach doch zum Testen dann ein zweites VPN, so dass deine bestehende Verbindung nicht gestört wird, man fährt so ungern 50 km um so etwas zu reparieren :D :D

[rt1970 10]

NAT ist ja nur auf der WAN-Schnittstelle aktiviert...

bringt mir also nichts, wenn ich eine neue VPN anlege :nene:

[h-d.neuenfeldt 21]

guck mal hier nach den Firewall Regeln, vielleicht erkennst du auch, dass du eine Weiterleitung vom Router auf deinen Server nicht eingerichtet hast :

http://blogs.technet.com/b/rrasblog/archive/2006/06/14/which-ports-to-unblock-for-vpn-traffic-to-pass-through.aspx

[rt1970 10]

Router soll korrekt eingerichtet sein sagt QSC

1723 -> IP WAN Server

GRE -> IP WAN Server

 

Im RRAS habe ich unter Dienste und Ports PPTP auf die IP WAN Server weitergeleitet. Auch IP LAN Server habe ich versucht. Hilft auch nicht.

[h-d.neuenfeldt 21]

nu bin ich am Ende ...

 

Vielleicht fällt den Anderen noch was ein ...

 

Warum machst du es nicht so :

Richte ich ganz normal eine VPN-Verbindung im Netzwerk- und Freigabecenter ein, funktioniert die Einwahl immer!

Auch von Clients außerhalb gibt es keine Probleme!

[rt1970 10]

Weil Routing und RAS auch funktionieren sollte -> sauberste Lösung wenn sie denn funktioniert ;-)

Habe eben noch was vom NAT-T gelesen und der Registry-Eintrag, der erstellt werden muss...

Mal sehen. Server startet grad durch.

[rt1970 10]

Hat nichts gebracht....

Das Routing und RAS des Server´s scheint auf "wackeligen Beinen" programmiert worden zu sein.

Die letzten Tage stand die Verbindung bis heute: Über RRAS keine Einwahl möglich: "Verbindung wird hergestellt" - und sonst nichts...

Irgendwann hatte ich eine Verbindung, aber kein Ping. Die Routingtabelle stimmte auch nicht. Daraufhin habe ich die Verbindung gelöscht und neu angelegt.

Ging immer noch nicht "Schnittstelle nicht verfügbar - Index 33" oder so ähnlich...

Die Routen waren immer noch auf eine Einwahlverbindung gebunden, die ich schon längst gelöscht hatte.

Das Ganze ging erst wieder nach einem Serverneustart. RRAS-Dienst neu starten reichte nicht!

 

Hat jemand ähnliche Erfahrungen?

Kann es mit "gebündelten Leitungen" zusammenhängen (2x 2MB SDSL)?

QSC meinte, dass die Ports korrekt weitergeleitet wurden:

ip nat static-napt tcp 192.168.0.1 1723 self 1723

Irgendwie fehlt mir aber das GRE-Protokoll und/oder PPTP Passtrough oder?

Wie sollte das auf dem Router eingetragen werden?

[pichocki 0]

Wir haben ein ähnliches Problem und finden bisher keine zufriedenstellende Lösung:

• Wir haben zwei Standorte mit drei VPN-Tunneln verbunden.
  Der eine ist "ständig" online, der andere erduldet täglich die Telekom-Zwangstrennung.
• Da wir L2TP verwenden, darf an keinem der Standorte der TMG über NAT erreichbar sein, d.h. er muss "direkt im Internet" hängen.
  Das haben wir sichergestellt, denn beide TMGs gehen über ein DSL-Modem direkt ins Netz.
• Von Zeit zu Zeit bricht mindestens einer dieser Tunnel zusammen (vermutlich alle drei bei Zwangstrennung),
  und dann kann mindestens einer davon nicht wieder aufgebaut werden.
• Es SCHEINT so, als versuche die Seite, die nicht getrennt wurde ("Standleitung"), sofort die Verbindung wieder herzustellen.
  Das klappt aber nicht, da sich die zwangsgetrennte Seite ja zunächst wieder "einwählen" muss.
  Hierbei scheint sie sich aufzuhängen: Sie steckt fest in der "Verbindungsherstellung";
  wenn man "Trennen" und danach "Verbinden" wählt, klappt das in aller Regel.

Ist es tatsächlich denkbar, dass das "Routing & RAS" das nicht von allein macht? Gibt es da einen "Deadlock".
Das fände ich allerdings sehr peinlich für Microsoft... und ärgerlich für uns Anwender!

 

Aber viel wichtiger: Was kann man dagegen tun?

Es gibt ja nur die EInstellung "Wählen bei Bedarf"; ich kann nicht einmal "Persistente Verbindung" auswählen, weil der TMG dies sofort zurückstellt.

Und eine Einstellung für eine regelmäßige Trennung (wie es die Fritzbox bot), um der Zwangstrennung zuvorzukommen, kennt der TMG auch nicht...

 

Weiß jemand Rat? Dann schon jetzt ein dickes Danke!

bearbeitet 4. Juni 2014 von pichocki

[Daniel -MSFT- 129]

Hast Du mal überlegt, das per Kommandozeile zu automatisieren? Per Aufgabenplanung könnte man da sicher was machen. Bin nur gerade nicht am Rechner, um da Details nachzuschlagen. Schau doch mal in die Richtung.

[pichocki 0]

Hi, Daniel.

 

Danke für den Tipp, und: Ja, das wäre eventuell eine Möglichkeit, zumindest was das RRAS angeht. Aber das Problem, das ich dabei sehe, ist die Tatsache, dass das RRAS nicht mehr "allein steht", sobald es mit dem TMG zusammen arbeiten muss. Der merkt sich ja alle Einstellungen in seiner "Konfiguration", und sobald ich "von außen", also direkt in der RRAS-Konsole, eine Änderung vornehme, macht der TMG diese rückgängig nach dem Motto: "Nur ICH habe hier noch das Sagen"... also ist alles, was nicht im TMG einzustellen ist, nun gar nicht mehr einzustellen. Oder siehst Du das anders?

[Daniel -MSFT- 129]

Ich meinte nicht, dass Du etwas an der Konfiguration extern änderst, sondern z.B. das rasdial-Utility nutzt, um die Verbindung per Batch zu trennen und neu zu verbinden. So kannst Du der Zwangstrennung per Aufgabenplanung zuvorkommen und zu uterschiedlichen Zeiten die drei Leitungen umstellen. Kann man auch z.B. mit einem ping-Test auf die jeweils andere Seite kombinieren und automatisieren.

 

Ich habe jetzt TMG seit drei Jahren nicht mehr in der Hand gehabt, deswegen kann ich leider nicht mehr soviel zu der Konfiguration von RRAS und VPN sagen. 

 

@rt1970: Die Serverpublizierungsregeln habt ihr auch mal gecheckt? Niht das sowas hier bei Euch zutrifft: http://blogs.technet.com/b/isablog/archive/2009/12/08/rras-ports-are-not-created-after-enabling-vpn-on-isa-server-2006.aspx

bearbeitet 4. Juni 2014 von Daniel -MSFT-