locked
Webserververöffentlichung - Ursprung der Anforderung ist der Client RRS feed

  • Frage

  • Hallo,

    ich verwende einen TMG 2010 und betreibe auf diesem einige Webserververöffentlichungen für MS Exchange 2010 und andere Produkte bei denen der Ursprung der Anforderung immer der TMG ist. Diese Regeln funktionieren auch super. Jetzt versuche ich eine Webserververöffentlichung einzurichten, bei dem der Ursprung der Anforderung der Client sein soll, damit ich die Systemintegrität des Clients prüfen kann. Ich erhalte immer den Fehler "Webproxy (Reverse) 10060 Timeout....". Auch der Zugriff auf eine interne Webseite endet mit dem identischen Fehler. Stelle ich den Ursprung der Anforderung auf TMG um ist sowohl der Webseiten Aufruf möglich und die Integrität wird überprüft, nur leider jedes mal vom TMG. Wie kann ich die Anforderung auf den Client umstellen. Ich habe zum Test auch andere Veröffentlichungsregeln umgestellt, sobald der Ursprung der Anforderung der Client ist funktioniert der Zugriff nicht mehr. Welche Regel muss ich erstellen damit dieses funktioniert. Zu meiner Konfiguration, ich betreibe den TMG in der DMZ mit einem Netzwerkadapter. Die Netze werden in einer Firewall geroutet.

    Für einen Tipp wäre ich sehr dankbar.

    Gruß Oliver

    Samstag, 14. Mai 2016 10:58

Alle Antworten

  • Moin Oliver,

    vermutlich hast Du es hier mit einem Rückrouten-Problem zu tun. Ist Dein TMG als Default Gateway am veröffentlichten Server eingetragen? Das ist die absolut notwendige Bedingung für die Beibehaltung der Source IP. Schau her:

    - Der TMG macht in diesem Szenario ja vermutlich NAT. Es gibt aber auf jeden Fall eine Route vom Webserver zum TMG, die über das Default Gateway des Webservers zu erreichen ist.

    - Du hast bei der Veröffentlichung die Option "IP beibehalten" gewählt. Client mit der Adresse XYZ baut nun eine Verbindung auf. Sie wird zum Webserver weitergereicht. Er bekommt also einen Request mit SourceIP=XYZ und TargetIP=Webserver_LAN (weil TMG das ja umgeschrieben hat)

    - Der Webserver antwortet. Und da er es nicht besser weiß, hatr das Paket SourceIP=Webserver_LAN und TargetIP=XYZ. Da XYZ weit weit weg ist, geht es an den Default GW. Ist das der TMG, hat er den ursprünglichen Request noch "im Kopf" und leitet die Antwort entsprechen weiter, nachdem er die SourceIP umgeschrieben hat.

    - Ist der Default GW des Webservers aber *nicht* der TMG, so leitet es das Paket entweder nicht weiter (die Kommunikation soll ja über den TMG gehen) oder es leitet das Paket zwar weiter, dort wird es aber mit diesen Daten nicht erwartet... Und der TMG wundert sich derweil, wo den die Antwort bleibt, und zeigt irgendwann einen Vogel, sprich: den Timeout.

    Will heißen: Du must Dein Konstrukt so umbauen, dass der TMG den Default Gateway bildet und auch tatsächlich ein Routing ins Internet ermöglicht. Da er aber in der DMZ steht, wird es mit dem Default GW vermutlich schwierig ;-)

    Gruß


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de

    my personal blog (mostly German) -> http://it-pro-berlin.de

    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de

    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com



    Samstag, 14. Mai 2016 13:24
  • Hallo  Evgenij,

    danke für Deine Antwort, diese hat mir wirklich weitergeholfen. Für einen Test habe ich den TMG als Gateway eingetragen und siehe da der Aufruf funktioniert. Was leider immer noch nicht funktioniert ist die Integritätsprüfung, ich erhalte immer die Meldung Client ist nicht NAP-Fähig. Zumindest steht im EventLog des RD-Gateways die IP-Adresse meines externen Clients. Somit wird jetzt das richtige System einer Prüfung unterzogen. Noch einmal herzlichen Dank....

    Gruß Oliver

    Samstag, 14. Mai 2016 16:07