ISA Server FAQ Home | ISA 2000 | ISA 2004 | ISA 2006 | TMG | Verschiedenes | Tools | Downloads | Links | Das Buch! | Bücher | User Group | Events | Blog | About | Sitemap | Suche

Kapitel höher
Zweites Gateway
SafeSearch
Account Lockout Prevention

 

Forefront TMG 2010 neben einem weiteren Gateway


Die Informationen in diesem Artikel beziehen sich auf:

  • Microsoft Forefront TMG 2010

 

Nicht gerade unüblich ist es neben Forefront TMG 2010, welcher das Standardgateway für Clients und Server ist, ein weiteres Gateway im Netzwerk zu haben, welches z.B. über einen VPN-Tunnel oder einen Etherconnect die Verbindung in eine Außenstelle herstellt. Problematisch wird es hierbei seit ISA Server 2004, in welchem erstmalig die Stateful Paket Inspection (SPI) eingeführt wurde. Die SPI macht vereinfacht ausgedrückt nichts anderes als ankommende Pakete nur zu erlauben, sofern bereits eine erfolgreiche Verbindung dafür bekannt ist und besteht. Ist dies nicht der Fall, so wird das Paket durch die SPI verworfen. Wie Sie die dennoch ein weiteres Gateway neben Forefront TMG 2010 betreiben können wird in diesem Artikel näher behandelt.
 

1. Netzwerkaufbau

Folgendes Bild zeigt den Netzwerkaufbau des Beispielszenarios


Das Szenario könnte wie folgt sein:

Am Hauptstandort (Subnetz 192.168.1.0/24) befindet sich ein Server mit den Remotedesktopdiensten von Windows Server 2008R2. Die Clients der Außenstelle (Subnetz 192.168.2.0/24) sind mit Thin-Clients ausgestattet und arbeiten somit remote auf dem Remotedesktopserver am Hauptstandort. Die Verbindung zwischen Hauptstandort und Außenstelle wird über eine Standleitung einer Telekommunikationsgesellschaft durch eigene Router hergestellt. Die Clients und Server am Hauptstandort haben als Standardgateway die interne IP-Adresse von Forefront TMG 2010 (192.168.1.1) eingetragen, damit z.B. der interne Exchange Server über Forefront TMG 2010 E-Mails senden und empfangen kann. Somit werden alle Anfragen an entfernte Subnetze zunächst an Forefront TMG 2010 gesendet.

Dadurch kommt es allerdings bedingt durch SPI zu einem Problem!
 

2. Das Problem

Stellen Sie sich vor, dass ein Thin-Client aus dem Netzwerk 192.168.2.0/24 versucht die Verbindung mit dem Remotedesktopserver (192.168.1.10) am Hauptstandort herzustellen. Dabei sendet dieser die Anfrage an sein Standardgateway (192.168.2.1), dem Standleitungs-Router der Außenstelle. Dieser kennt eine Route in das Netzwerk 192.168.1.0/24 und leitet die Anfrage über die Standleitung an den Router der Hauptstelle (192.168.1.2) weiter. Von hier aus befindet sich das Paket quasi schon im Netzwerk der Hauptstelle und da der Router mit einem Bein im LAN (192.168.1.0/24) steht kann dieser das Paket an den Remotedesktopserver mit der IP-Adresse 192.168.1.10 direkt weiterleiten. Soweit so gut. Bis hierher ist auch noch alles in Ordnung.

Bei einer TCP-Sitzung ist es für einen erfolgreichen Verbindungsaufbau erforderlich, dass vom Empfänger der Empfang der Pakete bestätigt wird. Der Remotedesktopserver muss dem Thin-Client also antworten, dass er das Paket erhalten hat und bereit für den Empfang weiterer Pakete ist. Somit sendet der Remotedesktopserver die Antwort an den entfernten Thin-Client mit der IP-Adresse 192.168.2.11. Da sich dieser nicht im LAN der Hauptstelle befindet, leitet der Server die Anfrage an sein Standardgateway, dem Server mit Forefront TMG 2010 weiter. Dieser erkennt durch SPI, dass es sich um ein Antwortpaket handelt, auf welches er keine Anfrage kennt und verwirft das Paket. Der Thin-Client wartet somit vergeblich auf eine Antwort und die Verbindung kann dadurch nicht hergestellt werden.

Folgendes Bild zeigt den Kommunikationsablauf:



Man könnte jetzt denken, dass sich das Problem lösen lässt, indem man in Forefront TMG 2010 eine Route erstellt, die die Pakete in das Netzwerk 192.168.2.0/24 über das Gateway 192.168.1.2 weiterleitet und zudem eine Firewallrichtlinie erstellt die diesen Datenverkehr erlaubt. In ISA Server 2000 ging dies noch so, da dieser keine SPI auf allen Netzwerkkarten aktiviert hatte. Man muss also an anderer Stelle schrauben, damit die Kommunikation mit dem Remotedesktopserver sichergestellt werden kann.

Dafür gibt es zwei Lösungsansätze.
 

3. Die Lösung

Folgende Lösungsansätze können verwendet werden, damit die Antwortpakete nicht über das Standardgateway gesendet werden.

3.1 NAT am Router der Hauptstelle

Eine Möglichkeit wäre die Pakete über den Router der Hauptstelle nicht zu routen, sondern eine Netzwerkadressübersetzung (NAT) anzuwenden. Dabei wird die ursprüngliche IP-Adresse des Clients 192.168.2.11 durch die interne IP-Adresse des Routers 192.168.1.2 im TCP-Header ersetzt. Der Server empfängt somit ein Paket das von der IP-Adresse 192.168.1.2 gesendet wurde und kann somit auch wieder direkt darauf antworten, da sich die IP-Adresse 192.168.1.2 in seinem Subnetz befindet.



Durch die Netzwerkadressübersetzung am Router der Hauptstelle werden die Antwortpakete direkt an den Router zurückgesendet und somit bleibt Forefromt TMG 2010 dabei aus dem Spiel. Problematisch wird diese Methode allerdings, sobald komplexere Zugriffe wie z.B. DCOM benötigt werden, die nicht über NAT hinweg funktionieren. Ebenso problematisch wird es, wenn Clients am Hauptstandort versuchen die Kommunikation mit einem Server der Außenstelle herzustellen. Dadurch, dass NAT angewendet wird, müssten hierfür Portweiterleitungen eingerichtet werden, was in größeren Umgebungen nicht realisierbar ist.

3.2 Setzen von Routen an Clients und Servern

Die weitaus bessere Methode ist an Clients und Servern statische Routen zu setzen, durch die die Antwortpakete ebenfalls nicht über Forefront TMG 2010 gesendet werden. Hierbei leiten (routen) beide Router die Pakete nur weiter, d.h. die Original-IP-Adresse bleibt im TCP-Header bestehen. Dadruch, dass am Client/Server der Hauptstelle eine statische Route existiert, die explizit anweist die Antwortpakete in das Netzwerk 192.168.2.0/24 nicht über das Standardgateway zu senden, werden die Pakete an den Router mit der IP-Adresse 192.168.1.2 gesendet.




Damit Clients und Server die statische Route in das Netzwerk 192.168.2.0/24 erhalten gibt es zwei Möglichkeiten, die folgend beschrieben werden.

3.2.1 Manuelle Routen setzen

Auf jedem Windows-Client/Server haben Sie über den Befehl route die Möglichkeit dem Client per Hand routen einzutragen. Sie müssen dazu als Administrator eine Eingabeaufforderung öffnen und für das Beispielszenario folgenden Befehl ausführen.



Über diesen Befehl teilen Sie dem Client/Server mit, dass er der Routingtabelle eine neue Route hinzufügen (add) soll, die in das Netzwerk 192.168.2.0 mit der Subnetzmaske 255.255.255.0 über das Gateway mit der IP-Adresse 192.168.1.2 führt. Der Parameter -p bewirkt, dass die statische Route auch nach einem Neustart auf dem Client/Server erhalten bleibt.

Für wenige Clients/Server ist diese Methode noch durchführbar. Jedoch bei mehreren Clients/Servern wird es problematisch die statischen Routen per Hand zu pflegen. Besser ist hier die Verteilung der Routen über den DHCP-Server.
 

3.2.2 Verteilen der Routen über den DHCP-Server

Die Verteilung der Routen über einen DHCP-Server bietet wesentlich mehr Flexibilität gegenüber Änderungen und bereitet weniger Aufwand bei mehreren Clients/Servern. Für die Verteilung der Routen über einen DHCP-Server gibt es die Option 121 Statische Routen ohne Klassen, bzw. die Option 249 bei Windows Server 2003, über die Sie dies ganz einfach konfigurieren können.

Öffnen Sie hierzu die Verwaltungskonsole des DHCP-Servers und navigieren Sie unterhalb des entsprechenden Bereichs zum Knoten Bereichsoptionen. Klicken Sie mit der rechten Maustaste auf den Knoten Bereichsoptionen und wählen Sie aus dem Kontextmenü den Eintrag Optionen konfigurieren aus. Dadruch öffnet sich ein weiteres Fenster in dem Sie sämtliche Optionen konfigurieren können. Suchen Sie darin die Option 121 Statische Routen ohne Klassen und setzen Sie einen Haken im davorstehenden Kontrollkästchen. Dadruch wird der untere Teil der Option konfigurierbar. Klicken Sie zum Erstellen einer neuen Route auf die Schaltfläche Route hinzufügen.



Tragen Sie Im Feld Ziel die Netzwerkadresse 192.168.2.0 und im Feld Netzwerkmaske die Subnetzmaske 255.255.255.0 des Netzwerks der Außenstelle ein. Im Feld Router muss die interne IP-Adresse des Routers am Hauptstandort hinterlegt werden. Dies ist die IP-Adresse 192.168.1.2. Fügen Sie anschließend die Route über die Schaltfläche OK hinzu und schließend Sie das Fenster über die Schaltfläche OK.

In der Übersicht sehen Sie nun, dass für die Option 121 Statische Routen ohne Klassen eine Route in das Netzwerk 192.168.2.0 hinterlegt ist. Clients die ihre IP-Adresse über den DHCP-Server erhalten bekommen automatisch diese Route zugewiesen und die Kommunikation in das Netzwerk 192.168.2.0 wird nicht über das Standardgateway gesendet.

Einzig die Server/Clients, die Sie mit einer statischen IP-Adresse konfiguriert haben, können logischer Weise die Routen nicht über den DHCP-Server erhalten. Diese müssen die Routen manuell gesetzt bekommen.

 

Stand: Thursday, 07. April 2011/CG


Home | ISA 2000 | ISA 2004 | ISA 2006 | TMG | Verschiedenes | Tools | Downloads | Links | Das Buch! | Bücher | User Group | Events | Blog | About | Sitemap | Suche

Fragen oder Probleme in Zusammenhang mit dieser Website richten Sie bitte an den Webmaster. Bitte inhaltliche oder technische Fragen ausschließlich in der deutschen ISA Server Newsgroup stellen.
Verbesserungsvorschläge, Anregungen oder Fremdartikel sind jederzeit willkommen! Copyright 2001-2011. Alle Rechte vorbehalten. msisafaq.de steht in keiner Beziehung zur Microsoft Corp.
Stand: Monday, 18. March 2013 / Dieter Rauscher