locked
Zugriff über S2S-Tunnel auf HTTPS-GeräteWebseiten RRS feed

  • Frage

  • Wir haben diverse Geräte, deren Webseiten über HTTPS angesprochen werden müssen. Leider klappt das nur lokal, aber nicht über den S2S-Tunnel. Für den Anwender sieht es aus, als wäre die HTTPS-Inspection fehlgeschlagen ("Webseite kann nicht angezeigt werden").

    Die Richtlinie, die den Zugriff zwischen den Standorten gewährt, wurde so konfiguriert:

    - Zulassen
    - Gesamten ausgehenden Datenverkehr
    - Von Intern, Standort1
    - Nach Intern, Standort1

    Entsprechend Standort2 auf dem zweiten TMG. Trotzdem kann ich nicht auf HTTPS-Webseiten im lokalen Netz zugreifen.

    Fehlermeldungen (Client-IP = IP des zugreifenden Clients):

    Von <Client-IP> nach <Remote-IP> über 443 (HTTPS) Initiierte Verbindung 0x0 SUCCESS
    Von <Client-IP> nach <Remote-IP> über 443 (https-inspect) Fehlgeschlagener Verbindungsversuch 0x80090308
    Von <Client-IP> nach <Remote-IP> über 443 (HTTPS) Getrennte Verbindung 0x80074e24 FWX_E_CONNECTION_KILLED
    Von <Client-IP> nach <TMG-interne-IP> über 26262 Nicht identifizierter IP-Datenverkehr (TCP:26262) Verweigerte Verbindung 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED

    Hat jemand eine Idee, woran das liegt bzw. wie man den Zugriff einrichten kann?

    Mittwoch, 22. September 2010 13:35

Alle Antworten

  • Hi,

    wenn die Meldung wirklich von der HTTPS Inspection kommt, wuerde ich die betroffenen IP-Adressen der Geraete in den Source- oder Destination Exceptions eintragen.


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Mittwoch, 22. September 2010 13:45
  • IP-Adressen können nicht in die HTTPS-Zielausnahmenliste aufgenommen werden - oder täusche ich mich da?

    Ich habe mal einen betreffenden Adressbereich in die Quellausnahmenliste aufgenommen - aber leider ohne Erfolg. Ich erhalte weiterhin keinen Zugriff auf die Konfigurations-Webseiten.

    Update: Ich habe mal die HTTPS-Überprüfung deaktiviert. Ich kann immer noch nicht über den Tunnel auf die Webseiten zugreifen, erhalte aber leicht andere Meldungen:

    Von <Client-IP> nach <IP-DES-GERÄTES> über 443 BrancheCache - Ankündigung Initiierte Verbindung 0x0 SUCCESS
    Von <Client-IP> nach <IP-DES-GERÄTES> über 443 BrancheCache - Ankündigung Getrennte Verbindung 0x80074e21 FWX_E_ABORTIVE_SHUTDOWN

    Mittwoch, 22. September 2010 14:02
  • moin,

    mit einem trick kannst du auch ip's von der https-inspection ausschließen. marc hat das thema mal in einem projekt mit der krähe - äh elster gehabt:

    http://www.it-training-grote.de/download/HTTPS-Inspection-TMG-Elster.pdf


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Mittwoch, 22. September 2010 15:49
  • Hi,

    http://www.it-training-grote.de/blog/?p=2906


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Mittwoch, 22. September 2010 16:11
  • Hi,

    hast Du BranchCache aktiviert? Koennte dann an der Protokolldefinition liegen. Schau mal:
    http://www.it-training-grote.de/download/isaserver-TMG-BranchCache.pdf


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Mittwoch, 22. September 2010 16:12
  • holla - setzt das schon jemand ein? würde mich wirklich interessieren! bisher habe ich noch keinen kunden der branch-caching im produktiven einsatz hat...
    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Mittwoch, 22. September 2010 16:42
  • Hi, erstmal danke für die Antworten.

    Eintrag von IP-Adressen: Ich habe auch IP-Adressen in die HTTPS-Ausnahmenliste aufgenommen (allerdings mit einem anderen Trick, nämlich "<IP>/*"). Testweise werde ich natürlich auch den Weg von Alex11 versuchen, bin aber nicht sehr zuversichtlich. Ich werde über das Ergebnis berichten. Aber da ich auch nicht auf die Webseiten zugreifen kann, wenn die HTTPS-Überprüfung deaktiviert ist, nehme ich an, dass das Problem an einer anderen Stelle zu suchen ist, oder?

    BrancheCache: Nein, BrancheCache ist meines Wissens nirgends installiert/aktiviert - weder in den Gruppenrichtlinien noch auf einem Server. Vielleicht später mal...da wird mir das obige Dokument sicher hilfreich sein :)

    Mit unserer vorherigen Firewall- und VPN-Lösung war es kein Problem, auch auf interne HTTPS-Seiten am Remotestandort zuzugreifen. Irgendwo muss der TMG das sperren - ich habe aber leider noch nicht gefunden, wo?

    Donnerstag, 23. September 2010 06:58
  • So, ich habe nun auch die Version von Alex11 ausprobiert - leider ohne Erfolg. Mal ein paar Meldungen:

    Fehlgeschlagenerr Verbindungsversuch (rot)
    Protokolltyp: Webproxy
    Status: 0x80090308
    Regel: Zugriff zwischen Standort1 und Standort2 zulassen
    Quelle: Intern (IP-des-zugreifenden-Clients:54158)
    Ziel: STANDORT2 (IP-des-Remotegerätes:443)
    Anforderung: IP-des-Remotegerätes:443
    (Anm.: Wie hinter Ziel)
    Protokoll: https-inspect
    Benutzer: <Domain>\User
    Zusätzliche Informationen
    - Objektquelle: Internet (Quelle ist das Internet. Das Objekt wurde zum Cache hinzugefügt)
    <-?

    Sofort danach:

    Getrennte Verbindung
    Protokolltyp: Webproxy (Forward)
    ...

    Und danach:

    Verweigerte Verbindung (rot)
    Protokolltyp: Ein Nicht-SYN-Paket wurde verworfen, weil es von einer Quelle gesendet wurde, die über keine vorhandene Verbindung mit dem Forefront TMG-Computer verfügt.
    Regel: keine - siehe Ergebniscode
    Quelle: Intern (IP-des-zugreifenden-Clients:54157)
    Ziel: Lokaler Host (IP-des-TMG:29070)
    Protokoll: Nicht identifizierter IP-Datenverkehr (TCP:29070)
    ...

    Ich bin echt ratlos. Leider benötige ich diesen Zugriff nicht nur, um mir etwas anzuschauen - die Geräte werden auch über HTTPS aktualisiert. Was ich gar nicht verstehe ist, dass genau die Regel, die den Verkehr über den Tunnel erlaubt (und in der alles erlaubt ist) da etwas zu sperren scheint. Was vielleicht andere auch nachvollziehen können, weil es nicht so ungewöhnlich ist: Ich komme auch nicht auf die ILO-Boards meiner HP-Server.

    Montag, 27. September 2010 08:30
  • Ich habe zumindest schon einmal eine Teillösung für die ILO-Boards (HP-Server): Wenn ich nicht die HP-selbst-Zertifikate benutze, sondern Webzertifikate verwende, die von unser CA ausgestellt wurden, dann kann ich auch problemlos auf die HTTPS-Webseiten der ILO-Boards zugreifen.

    Anscheinend stört da die https-inspection, die leider nur systemweit zu gelten scheint, also nicht für eine Regel (z. B. für den Verkehr zwischen den Standorten) deaktiviert werden kann.

    Was die Telefone angeht: Ich suche gerade nach einer Lösung, diese auch mit von unserer CA ausgestellten Zertifikaten versehen zu können.

    Freitag, 8. Oktober 2010 07:01
  • Hi,

    ja, das kann gut sein! Du kannst aber Quell- und Zielausnahmen fuer die HTTPS-Inspection konfigurieren und die ILO IP Adressen ausschliessen


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Freitag, 8. Oktober 2010 07:26
  • hm - wieso "sieht" tmg hier überhaupt das ilo? ich kenne nur ilo-implementationen, wo das ilo-interface komplett unsichtbar für den darauf laufenden host ist!
    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 8. Oktober 2010 07:45