none
Site-2-Site Konfig geht nicht mehr nach Migration ISA 2004 nach TMG RRS feed

  • Frage

  • Hallo zusammen,

    eine Site-2-Site Konfiguration auf Basis von IP-Sec bekomme ich nach der Migration von ISA Server 2004 nach TMG nicht mehr ans fliegen.

    Das Gegenstück ist ein Astaro Router. An dem ist aber nichts verändert.

    Das Logging sagt, dass die Site-2-Site Verbindung 'UP' ist. Das sagt auch der Astaro Router.

    Eigentlich ist's ja ganz einfach aber es geht nicht.

    Ja, das externe Bein des Astaro Routers ist in der Menge der IP Adressen des Ziel VPN Netzwerks.

    Wo soll man suchen? Weder PING, noch Tracert noch sonstwas geht...

    Help is needed...

    Gruß Gernot

    Sonntag, 10. Oktober 2010 13:47

Antworten

  • Hallo,

    das Problem ist gelöst - Ursache ist der TMG, es muss TMG update 1RU3 (gibts offiziell noch nicht, KB: 2498770) + ein nicht dokumentierter netsh Befehl (netsh tmg set global name=DontDropIPSECDetunneledTrafficToLocalhost value=1 persistent )eingespielt werden.
    (Der TMG akzeptiert per default keine Pakete welche vom remotenetz auf das interne Interface gerichtet werden)

    Vielen Dank an den MS support!

    UPDATE: TMG SP1 RU3 soll in den nächsten 2-3 Tagen veröffentlicht werden, der Artikel dazu ist nur noch nicht ganz fertig.


    Viele Grüße,
    Christian

    Donnerstag, 10. Februar 2011 08:20
  • Hi,

    so sitze dank Verspaetung in Berlin am Hauptbahnhof und konnte eine Test TMG Maschine hochfahren. Ich habe den Befehl 1:1 in die Zwischenablage kopiert und am TMG ausgefuehrt. Keine Fehlermeldung.

    Du hast folgenden Befehl eingegeben? netsh tmg set global name=DontDropIPSECDetunneledTrafficToLocalhost value=1 persistent und nicht innerhalb von Netsh sondern direkt com Command Prompt? Du fuehrt die CMD mit erhoehten Rechten aus? (UAC)


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 5. Juni 2011 16:17
    Moderator

Alle Antworten

  • Hi,

    also die TMG Seite sagt Du haettest ein S2S VPN? Verwendest Du PSK oder Zertifikate?
    So als ersten Anlaufpunkt solltest Du verwenden:
    http://technet.microsoft.com/en-us/library/bb794765.aspx
    In der TMG Konsole nichts auffaelliges im Dashboard?
    Wenn das S2S VPN steht und nix geht, vermute ich mal ein Routingproblem. Also bitte nochmal die ganzen Routen checken und Tracert verwenden und im TMG Realtime Logging gucken ob was  geblockt wird


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 10. Oktober 2010 14:44
    Moderator
  • Hi,

    das wundert mich auch. Es gibt KEINE Routen auf dem TMG Server Richtung S2S Network. Route Print lässt dieses Netzwerk aus (macht der alte ISA aber auch!).

    Es wird nichts geblockt durch irgendwelche Access Rules. Das habe ich gecheckt.

    Gruß

    Gernot

    Sonntag, 10. Oktober 2010 15:04
  • Hi,

    in TMG werden jetzt Network Topology Routen in der TMG Konsole verwendet. Route Add per CLI hat ausgedient. Hat auch den Vorteil dass die Routen in dem TMG Konfigurationsspeicher gespeichert werden und einen Export- Import ueberleben!


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 10. Oktober 2010 15:07
    Moderator
  • Wenn ich eine S2SD Verbindung mache, wird aber nicht automatisch eine Network Topologie Route erzeugt!

    Wenn ich das per Hand mache: Muss als Gateway mein externes Bein Richtung S2S rein oder das externe Bein der Gegenstelle (Astaro)?

    Gruß

    Gernot

    Sonntag, 10. Oktober 2010 15:25
  • Was ich nicht verstehe:

    Routable Local IP Addresses:Remote Network IP Subnets:
        Subnet: 192.168.2.0/255.255.255.0
        Subnet: X.Y.Z.A/255.255.255.255

    Local Network 'Internal' IP Subnets:
        Subnet: 10.0.0.0/255.255.255.0
        Subnet: 10.0.2.0/255.255.255.0
        Subnet: 10.0.4.0/255.255.255.0

    Routable Local IP Addresses:
        Subnet: 10.0.0.0/255.255.255.0
        Subnet: 10.0.2.0/255.255.255.0
        Subnet: 10.0.4.0/255.255.255.0
        Subnet: 192.168.2.0/255.255.255.0
        Subnet: X.Y.Z.A/255.255.255.255

    Wieso ist in den Routable Local IP-Adressen die der externen VPN Site vorhanden?

    Das bekomme ich aber auch nicht weg.

     

    Sonntag, 10. Oktober 2010 16:33
  • Hi,

    das externe Bein der Gegenstelle!


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 10. Oktober 2010 16:46
    Moderator
  • Danke!

    und der TMG macht das nicht von allein?

    Sonntag, 10. Oktober 2010 17:19
  • Hi,

    eigfentlich schon. Musste bisher nicht Hand anlegen :-)
    Funzt es denn jetzt?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 10. Oktober 2010 17:21
    Moderator
  • Hi,

    nein! Es läuft leider nicht. Ich habe auch diverse neue Site-2-Sites angelegt. Es wird niemals eine Route angelegt...

    Gruß

    Gernot

     

    Sonntag, 10. Oktober 2010 17:40
  • nabend,

    strange gernot - ich kenne das auch nur so das wenn du einen s2s anlegst eine netzwerkregel (route) und auf wunsch sogar passendes firewallregelwerk angelegt wird!


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Sonntag, 10. Oktober 2010 19:25
  • Hallo die Herren,

    vielleicht nochmal ein Detail zum besten (Nach einer Mütze Schlaf): In der alten ISA Konfig stand im Netzwerk Internal folgendes:

    10.0.0.0 - 10.0.0.255
    10.0.2.0 - 10.0.2.255
    10.0.3.0 - 10.0.3.255
    10.0.4.0 - 10.0.4.255
    10.255.255.255-10.255.255.255  <<<<<<<<!!!!*

    Auffällig ist doch dabei der letzte Eintrag. Dazu habe ich zwei Ideen: Wir haben hier im LAN das 10.0.0.0 mit der Subnetzmaske 255.255.255.0. Also haben wir doch hier klassenloses IP, da wir keine Subnetzmaske mit 255.0.0.0 einsetzen. Dieses klassenlose IP ist ja flexibel, aber ich könnte mir vorstellen das der gute alte TCPIP Stack und auch das Routing da zwar mitspielen, aber nur mit besonderer Konfiguration. Am Ende geht es doch um Nullen und Einsen.... Oder es werden durch diesen Eintrag die Entscheidungskriterien für das Routing beeinflusst. Da nun der Tunnel und auch die eigentliche Site2Site Verbindung auf beiden Seiten gut aussehen, ist ein Routing Problem sehr wahrscheinlich. Da kommt nun dieser obige Eintrag * ins Spiel. Vielleicht hilft er dem Routing ein wenig auf die Sprünge. Könnte es sein, daß wir diesen auch auf dem TMG konfihgurieren müssen? Wo sind die Routing Gurus....;-)

    Der TMG Wizard funktioniert bestimmt gut, wenn man zum 10ner Netz auch eine A class Subnetzmaske einsetzt. Oder?

    Gruß
    Frank

     

    Montag, 11. Oktober 2010 07:10
  • Hi Gernot und Frank :-)

    hattest Du nach der Muetze Schlaf einen Persoenlichkeitswechsel :-)

    Die 10.255.255.255 ist die Broadcastadresse fuer das Klasse A Netzwerk. Das hat der ISA Assistent automatisch aus der Routingtabelle des Netzwerkadapters ausgelesen. Ich denke nicht, dass die Probleme darin begruendet sind. Was sagt denn die TMG Konfiguration bei den IP-Adressen im Knoten Vernetzung fuer das Netzwerk Intern, wenn Du auf "Adapter hinzufuegen" klickst? Bekommst Du im TMG Dashboard die Meldung: TMG hat Routen ueber den Adapter ... festgestellt usw.? 


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 11. Oktober 2010 08:11
    Moderator
  • Hi Marc,

    naja war vielleicht doch zu früh. Klar Broadcast. Aber es könnte die TMG in irgendeiner Weise trotzdem beeinflussen. Schaun wir mal..Außerdem sind auch manche Querschüße anregend...Oder? Das das der Wizard ausgelesenhat, kommt mir komisch vor...

    Also wenn ich jetzt einfach nochmal den NIC internal hinzufüge passiert nichts im Dashboard. Also Oben rechts unter Error oder network Status sehe ich nichts. Sollte ich das Internel Network erst leeren?

    Musste ja die eigentliche IP wieder zurücknehmen, da wir den ISA wieder im Betrieb haben. Könnte sein das jetzt nicht alles so funktioniert, da die anderen NICs nur auf einen Switch gesteckt sind. Aber aktiv sind sie.

    Gruß

    Frank

    Montag, 11. Oktober 2010 08:36
  • Hi Frank,

    Querschuesse sind immer anregend - EDV = Ewig Drohendes Versagen oder Ende Der Vernunft. Ja, kannst Du mal leeren und dann die IP-Adressen nochmal neu aus der Routingtabelle einlesen.

    Hattest Du jetzt schon mal mit Tracert geschaut, welchen Weg die Pakete nehmen?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 11. Oktober 2010 08:56
    Moderator
  • Hi Marc,

    die kannte ich noch nicht, obwohl schon 20 Jahre dabei. Nett *Schmunzel*  ....ist da doch ein Mensch am anderen Ende...;-)

    also habe nochmal das interne Netzwerk geleert und dann die NIC internal hinzugefügt. Sieht dann so Aus:

    10.0.0.0 - 10.0.0.255
    10.0.2.0 - 10.0.2.255
    10.0.3.0 - 10.0.3.255
    10.0.4.0 - 10.0.4.255

    Aber keine Meldung im Log oder Dashboard wegen neuer route. Die Routen für diese Netze haben wir doch zum Anfang per CMD permanent rein getragen. Sollte man dies lieber nicht tun und dem TMG dies überlassen?

    Dank & Gruß
    Frank

    PS: Bekommt man hier auch Bilder rein....ist vielleiht einfacher???

     

    Montag, 11. Oktober 2010 09:25
  • Hi Frank,

    ich wuerde die Routen per CMD loeschen und dann per Network Topology Route am TMG direkt eintragen.
    Die Netzwerkbereiche sehen doch OK aus.


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 11. Oktober 2010 09:37
    Moderator
  • Hi Marc,

    okay mache ich.

    Das Update1 habe ich auch noch nicht. Kommt das nicht über Windows Update? Oder dauert es immer ein bißchen...?

    Bekommt man hier auch Bilder rein....ist vielleiht einfacher???

    Frank

    Montag, 11. Oktober 2010 09:43
  • Hi nochmal,

    müßte man für das site2site VPN dann auch so eine Network Topology Route anlegen?

    Ich sehe keine route für das entfernte Netzwerk (192.168.2.0) im Routing TAB des TMG.

    Der VPN Wizard macht dies nicht...glaube ich...oder?

    Frank

    Montag, 11. Oktober 2010 09:54
  • Hi,

    Update 1 ist noch nicht in Deutsch verfuegbar. Soll aber die Tage kommen!


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 11. Oktober 2010 11:03
    Moderator
  • Hi,

    wir haben TMG us. Habe es eingespielt. Startet besser.

    Frank

    Montag, 11. Oktober 2010 11:12
  • Hi Frank,

    nein, das macht der Assistent selber. Du kannst aber mal eine erstellen und gucken ob es dann funzt!


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 11. Oktober 2010 11:28
    Moderator
  • Hi Marc,

    ich habe nochmal alles langsam durch mit dem Wizard. Keine Route ist erstellt worden. Ist denn da nicht schon ein Problem, wenn Du es so fest behauptest...?

    Kann ich Dir mal meine Screenshots zu mailen? Bilder sagen mehr....

    Gruß

    Frank

    Montag, 11. Oktober 2010 12:14
  • Hallo zusammen,

    habe nochmal nachgedacht:

    Bei einem anderen Kunden hatten wir den Fall, dass die Masken der jeweiligen Remotestandorte beim TMG exakt übereinstimmen mussten. Das war beim ISa Server nicht so.

    Das Remotenetzwerk muss also jeweil exakt dem entsprechen, wie es auf der Gegenseite eingerichtet ist.

    Also die Konfiguration

    10.0.0.0/24 (local net A) <-> A.B.C.D (externes BEIN TMG) <-> Internet <-> W.X.Y.Z (Astaro extern) <-> 192.168.2.0/24 (local net B)

    muss auf beiden Seiten EXAKT stimmen. Ist das so?

    Gruß

    Gernot

    Montag, 11. Oktober 2010 15:07
  • Hi, ja, die Remote Netzwerkbereiche muessen genau gleich sein fuer die Netze welche durch das S2S remote erreichbar sein sollen. ist mir bei ISA 200x noch gar nicht aufgefallen das das so ging, bzw. habe ich es nie probiert
    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 11. Oktober 2010 16:20
    Moderator
  • tmg sp1 software update 1 ist lokalisiert:

    http://www.microsoft.com/downloads/details.aspx?FamilyID=695d0709-0d8b-45ee-afdb-727c4428ca4d&displayLang=de


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Montag, 11. Oktober 2010 17:07
  • Hi Marc,

    vielleicht geht es auch nicht offiziel so. Aber der Eintrag 10.255.255.255-10.255.255.255 in einem einem Netzwekdefinitionsobjekt ist schon schrill. Aber vielleicht auch ein dirty Trick, der aber  - vor meiner Zeit, daher keine Idee - geholfen hat.

    Wir testen nochmal....

    Gruß

    Frank

    Dienstag, 12. Oktober 2010 12:48
  • Hallo zusammen,

    mal zur Info: Wir haben einen Call bei Microsoft aufgemacht. Dort kann man das nachvollziehen. Astaro geNATet Site-2-Site geht aktuell nicht!

    Grüße

    Gernot

    Freitag, 15. Oktober 2010 15:41
  • Hallo Zusammen,

    zwischen ISA 2004/2006 und TMG haben sich die standard IPSec-Einstellungen geändert. Dort wird jetzt AES verwendet. Dann kann man aber wieder auf DES zurückstellen. Auf alle Fälle müssen die Parameter für Phase 1 und Phase 2 identisch sein.

     

    Viele Grüße
    Carsten

    Mittwoch, 20. Oktober 2010 18:03
  • also identisch auf beiden VPN-Endgeräten meine ich natürlich ...
    Mittwoch, 20. Oktober 2010 18:03
  • Guten Morgen Marc,

    leider funktioniert unser VPN mit der Astaro immer noch nicht. Ich bekam den Tipp diesen Hotfix auf der TMG einzuspielen:

    http://support.microsoft.com/kb/2028625

    Die Astaro liegt ja auch hinter einem Router, der die öffentliche IP zum Astaro Router mit NAT weiterletet.

    Kann es da mit der TMG Probleme geben?

    Macht es hier wirklich Sinn für unser Problem?

    Gruß

    Frank

    Mittwoch, 8. Dezember 2010 07:58
  • Hi, schaden kann es nicht, ob es auf Eurer Problem zutrifft kann ich schwer sagen, da es ueber ein Forum ja schwer ist solche Probleme anzugehen. Evtl. auch sowas: http://blogs.technet.com/b/isablog/archive/2010/12/07/tmg2010-site-to-site-vpn-fails-to-dial-with-error-913-a-remove-access-client-attempted-to-connect-over-a-port-that-was-reserved-for-routers-only.aspx
    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Mittwoch, 8. Dezember 2010 08:03
    Moderator
  • Hi,

    klar ist es schwer. Sonst wären hier ja auch nicht so viele Beiträge.

    Aber...wie so oft im Leben...helfen kleine Schritte bzw. Tipps weiter...

    In diesem Sinne erstmal DANKE

    Frank

    Mittwoch, 8. Dezember 2010 08:07
  • Hi,

    hast Du mal daran gedacht, einen Call bei MS aufzumachen? Kostet einmalig um die 350 EUR meine ich und MS loest das Problem dann fuer Dich, dann ersparst Du Dir die viele Arbeit. Dein Problem existiert ja seit dem 10.10.2010?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Mittwoch, 8. Dezember 2010 08:13
    Moderator
  • Hi,

    der war jetzt gut....Haben wir doch schon...;-)...seit .12.10.2010...Siehe Oben am 15.12.2010

    Antwort von MS: Ja Fehler können wir bestätigen; Lösung haben wir nicht....
    Den Tipp mit dem Hotfix kam auch nicht; Kam von einer TMG Applaince Firma.
    Wollte schon ein neues Remote Gateway besorgen...Bin in allen Richtungen aktiv...auch nicht technisch...;-)

    Frank

    Mittwoch, 8. Dezember 2010 08:20
  • Hallo,

    eventuell bringt es auch schon was am TMG folgende Registrykeys zu setzen:

    http://support.microsoft.com/kb/926179/

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Mittwoch, 8. Dezember 2010 08:24
    Moderator
  • Hallo,

    habe hier mehr oder weniger dasselbe Problem. Habt Ihr schon eine Lösung dazu gefunden?

    Auf der einen Seite steht ein Forefront TMG 2010 im Netz 192.168.2.0/24 mit der IP .253
    Auf der anderen Seite ein ASG im Netz 192.168.0.0/24 mit der IP .253

    Aus dem Netz 192.168.0.0 sind alle Hosts im Netz 192.168.2.0 erreichbar bis auf die IP des TMG 192.168.2.253

    Aus dem Netz 192.168.2.0 sind sämtliche Hosts im Nachbarnetz erreichbar, auch die 192.168.0.253

    An den Firewallregeln sollte es nicht liegen, hier sind keinerlei Fehler ersichtlich. Im Logging ist auch kein blocking zu finden.

    Irgendwas scheint hier faul zu sein. Habe den TMG im verdacht. Mit nem ISA 2004 hat vorher alles einwandfrei geklappt.

     

    Viele Grüße,

    Chrstian

    Donnerstag, 20. Januar 2011 21:01
  • welches problem hast du genau christian?

    falls deine s2s-tunnel immer disco's haben, dann wie oben erwähnt die aktuellen tmg-patches einspielen und es sollte ruhe einkehren!


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Donnerstag, 20. Januar 2011 21:12
  • Hallo Jens,

    ich habe keinerlei disconnects. Ich kann lediglich von Remotestandort aus den TMG am Ende des Tunnels nicht erreichen.

    Der TMG soll als proxy bei den Clients am Remotestandort eingetragen werden.

    Patches sind alle eingespielt, incl. des hier im Thread genannten.

     

    Viele Grüße,

    Christian

    Donnerstag, 20. Januar 2011 21:29
  • Hi,

    also Tunnel steht, die Subnetze auf den jeweiligen Gegenseiten koennen erreicht werden, nur der TMG direkt nicht? Sieht dann nach einer Firewallregel aus?! Was sagt denn das TMG Logging wenn Du aus dem Remotenetz den TMG erreichen willst?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Freitag, 21. Januar 2011 02:10
    Moderator
  • Hi,

    richtig, nur der TMG ist nicht erreichbar.

    An den Regeln sollte es nicht liegen, habe eine Regel welche sämtlichen traffic vom Remotenetz ins interne zulässt. Zusätzlich habe ich testweise auch noch mal eine Regel eingerichtet welche auch sämtlichen traffic von beiden externen adressen bzw. "lokaler host" zulässt.

    Weder im logging des TMG noch im Astaro ist traffic oder gar ein blocking ersichtlich, es kommt nichts an.

    Die Verbindungseinstellungen habe ich 1:1 vom alten ISA 2004 übernommen, an der Astaro wurde gar nichts geändert.

    Viele Grüße,

    Christian

    Freitag, 21. Januar 2011 08:47
  • moin christian,

    wenn du durch den tunnel mal den internen socket des tmg (ip:8080) telnettest, hebt dieser dann ab?

    alternativ könntest du ausprobieren eine regel zu erstellen, die dem remotenetz erlaubt nach extern zuzugreifen.


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 21. Januar 2011 10:09
  • Hi,

    Ein telnet auf den int. Socket hebt nicht ab. Ebenso bringt ne´ extra Regel für den Zugriff keine Besserung.

    Den TMG sehe ich übrigens in nem trace vom remotenetz auf einen beliebigen host nicht:

    tracert 192.168.2.1

    Tracing route to [192.168.2.1]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  [192.168.0.253]
      2     *        *        *     Request timed out.
      3     8 ms     7 ms     7 ms [192.168.2.1]

    Trace complete.

    Habe zudem mal ne´ andere Astaro (V8, Benutzen am Remotestandort noch die V7) mit dem TMG verbunden: gleiches Phänomen.

    Viele Grüße,

    Christian

    Freitag, 21. Januar 2011 11:08
  • Hallo,

    bin der Sache etwas näher gekommen:

    Nachdem ich das Ipsec logging eingeschalten habe finde ich folgenden Eintrag im security log des TMG sobald ich vom remotestandort auf den TMG pinge:

    Von IPsec wurde ein eingehendes Klartextpaket verworfen, das geschützt hätte sein sollen. Ist für den Computer eine Richtlinie zum Anfordern von IPsec für ausgehende Daten konfiguriert, ist diese Meldung wahrscheinlich harmlos und war zu erwarten. Die Meldung kann auch darauf zurückzuführen sein, dass die IPsec-Richtlinie des Remotecomputers geändert wurde, ohne diesen Computer zu informieren. Es kann auch auf einen versuchten Spoofingangriff hindeuten.

    Remotenetzwerkadresse: 192.168.0.253

    SPI der eingehenden Sicherheitszuordnung: 0

    Event ID 4963 / IPSEC Treiber

    Hat jemand ne´ Idee dazu? Google spuckt dazu recht wenig aus.

     

    Viele Grüße,

    Christian

    Montag, 24. Januar 2011 14:23
  • Hallo,

    update hierzu:

    Habe am Remotestandort einen ISA2004 / Win2k3R2 installiert. Gleiches Problem, kann den TMG nicht anpingen. Im Eventlog erscheint wieder das 4963 Event. Der TMG scheint wohl ein Problem zu haben.

     

    VIele Grüße,

    Christian

    Donnerstag, 27. Januar 2011 09:08
  • Hallo Christian,

    wir sind auch noch dran. Warum hast Du nicht TMG am Remotestandort installiert?

    Wir nehmen jetzt mal eine TMG applainces zum Testen.

    Wenn Du magst können wir uns tel. mal kurzschliessen. Manchmal hilft es ja ...;-)

    Frank

    Donnerstag, 27. Januar 2011 09:12
  • Hi,

    wir haben keine zweite TMG Lizenz - daher habe ich die vorhandene bzw übrige ISA Lizenz einfach mal "drüben" installiert.

    Habt Ihr die int. IP Adresse des TMG mal geändert? Bei uns hatte der TMG vor dem Switch die IP .130 bis ich diese auf die .253 geändert habe.

    In der registry des TMG finde ich nämlich Verweise auf die "alte" IP => Habe diese Verdachtshalber mal auf die neue IP geändert - hat aber nichts geholfen.

     

    Viele Grüße,

    Christian

    Donnerstag, 27. Januar 2011 10:09
  • Hallo,

    das Problem ist gelöst - Ursache ist der TMG, es muss TMG update 1RU3 (gibts offiziell noch nicht, KB: 2498770) + ein nicht dokumentierter netsh Befehl (netsh tmg set global name=DontDropIPSECDetunneledTrafficToLocalhost value=1 persistent )eingespielt werden.
    (Der TMG akzeptiert per default keine Pakete welche vom remotenetz auf das interne Interface gerichtet werden)

    Vielen Dank an den MS support!

    UPDATE: TMG SP1 RU3 soll in den nächsten 2-3 Tagen veröffentlicht werden, der Artikel dazu ist nur noch nicht ganz fertig.


    Viele Grüße,
    Christian

    Donnerstag, 10. Februar 2011 08:20
  • Hallo Christian,

    kannst Du uns den Patch und Befehl zukommen lassen?

    Wäre echt nett.

    Gruß

    Frank

    Donnerstag, 10. Februar 2011 08:27
  • Hallo zusammen,

    auch hier mal ein Update. Auch dieser Patch hat letztlich leider nicht geholfen.
    Inzwischen glaube ich, dass das einfach nicht geht. Wir üben das inzwischen mit TMG<->TMG.

    Auch das geht NICHT, wenn einer der 2 TMGs sich hinter einer statischen NAT-T IP Adresse versteckt.

    Grüße

    Gernot

    Dienstag, 22. März 2011 11:12
  • Hallo,

    das Problem ist gelöst - Ursache ist der TMG, es muss TMG update 1RU3 (gibts offiziell noch nicht, KB: 2498770) + ein nicht dokumentierter netsh Befehl (netsh tmg set global name=DontDropIPSECDetunneledTrafficToLocalhost value=1 persistent )eingespielt werden.
    (Der TMG akzeptiert per default keine Pakete welche vom remotenetz auf das interne Interface gerichtet werden)

    Vielen Dank an den MS support!

    UPDATE: TMG SP1 RU3 soll in den nächsten 2-3 Tagen veröffentlicht werden, der Artikel dazu ist nur noch nicht ganz fertig.


    Viele Grüße,
    Christian

     

     

    Hallo ich brauche auch ganz dringend den Befehl. Könnte den mir einer schicken?

    Sonntag, 5. Juni 2011 11:57
  • Hi,
    welcher Befehl? Hat Gernot den nicht schon geschrieben in seinem Posting? TMG SP1 RU3 ist ja auch schon laenger verfuegbar. Hast Du es schon probiert und es funktioniert trotzdem nicht?
    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 5. Juni 2011 12:28
    Moderator
  • Hi, ich meine den hier "netsh tmg set global name=DontDropIPSECDetunneledTrafficToLocalhost value=1 persistent"

    Weiß nicht was ich da eingeben soll :-(

    Sonntag, 5. Juni 2011 13:55
  • HI,

    genauso wie es da steht oder klappt das nicht. Kann das gerade nicht nachstellen, sitze im Zug und der haelt gleich. Damit wird verhindert, das die lokale Maschine IPSEC Pakete verwirft, wenn diese Tunnelendpunkt ist und den Tunnel terminiert


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 5. Juni 2011 15:22
    Moderator
  • Werde es nochmal versuchen meine aber wenn ich den im CMD eingebe habe kommt "Befehl wurde nicht gefunden".

    Schönen Sonntag noch!

    Sonntag, 5. Juni 2011 15:44
  • Hi,

    so sitze dank Verspaetung in Berlin am Hauptbahnhof und konnte eine Test TMG Maschine hochfahren. Ich habe den Befehl 1:1 in die Zwischenablage kopiert und am TMG ausgefuehrt. Keine Fehlermeldung.

    Du hast folgenden Befehl eingegeben? netsh tmg set global name=DontDropIPSECDetunneledTrafficToLocalhost value=1 persistent und nicht innerhalb von Netsh sondern direkt com Command Prompt? Du fuehrt die CMD mit erhoehten Rechten aus? (UAC)


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 5. Juni 2011 16:17
    Moderator
  • Hi,
    hattest Recht, waren die Rechte!
    Hat geklappt, thx.
    Dienstag, 7. Juni 2011 06:19
  • Hi Marc,

    das Problem besteht immer noch. Denn bei der Ausgangssituation war ja mit NAT dabei.

    Oder ist es noch zu früh...;-)))...was übersehen....?

    Es scheint als ob man die VPN-ID auf der TMG Seite setzen müsste. Leider kann ich keine Konfigurationsmöglichkeit finden.

    Dort müsste die IP adresse des Transfernetzes rein.

    Noch eine Idee?

     

    Gruß

    Frank

    Dienstag, 7. Juni 2011 07:03
  • So. Nach einem Jahr gibt es einen Hotfix!!!

    "KB 2523881           You cannot establish an IPsec tunnel to a computer that is running Windows 7 or Windows Server 2008 R2 through a NAT device"

    Problem gelöst. Dann klappt's auch mit dem NAT-T Device.

    Gruß

    Gernot

     


    Greetings/Grüße Gernot
    Dienstag, 18. Oktober 2011 14:38