locked
Lync Edge komplett hinter TMG RRS feed

  • Frage

  • Hallo zusammen,

    wir haben ganz neu den Lync Server bei uns installiert. Ich wollte folgende Konfiguration realisieren:
    Lync Edge hat 2 NICS
    Extern : 192.168.103.221, 222, 223
    Intern 192.168.103.10

    TMG 1.1.1.1, 1.1.1.2, 1.1.1.3

    Ich habe nach der Anleitung von http://msxfaq.de/lync/lyncedgetmg.htm den TMG eingerichtet.

    Leider geht es noch nicht deswegen frage ich nier nochmal.

    Die unklaren Fragen sind nun, welche IP Adressen muss ich in der Topology des Edge angeben?
    Die internen oder die externen?

    Ich habe, wie in der Beschreibung, natürlich die NAT extern des AV angegeben.

    Oder wo kann ich noch nachsehen?

    Der TMG bringt folgenden Fehler bei der Analyse:
    FWX_E_TCP_NO_SERVER_REPLY
    Getrennte Verbindung.

    Momentan habe ich in der Topology die internen IP Adressen angegeben.
    Vielleicht hat sonst noch jemand Rat diesbezüglich?

    Freitag, 21. Oktober 2011 10:40

Alle Antworten

  • Können Sie auf der Konsole des TMG die Poolserver und EDGE überhaupt erreichen - also FQDN anpingen? Also hat der Routen, die über das interne NIC führen in die Netze wo der Rest der Topologie steht eingetragen? ( >route print)
    Sonntag, 23. Oktober 2011 06:01
  • Ich habe mich vielleicht etwas unschön ausgedrückt und werde meine Topologie nochmal besser darstellen.

    Zunächst haben wir kein Perimeter Netzwerk, wir sind dafür noch zu klein.
    Mein TMG hat nur zwei Netzwerkkarten, eine externe und eine Interne.
    Der Lync Server ist im internen Netz. Der Edge Server hat auch zwei netzwerkkarten. Allerdings habe ich bei beiden IP Adressen des internen netzes angegeben, sind somit immer erreichbar von intern.

    Da ich das komplette interne Netz natürlich mit dem TMG erreichen kann, kann ich auch den Edge Server mit dem TMG erreichen. Über FQDN und IP Adressen.

    Wenn ich nun den Cient starte meldet er sich beim TMG an der externen Schnittstelle an und wird an den Edge weitergeleitet. Leider bekomme ich eben die Meldung, dass der Edge keine Antwort gibt und somit die Verbindung wieder getrennt wird.

    Ich habe nun auch mal beide Versionen ausprobiert:
    1. In der Topologie die internen Adressen mit den externen Namen gebunden
    2. In der Topologie die externen Adressen, die ja nun am TMG eingetragen sind, andie externen namen gebunden.

    Leider gehen beide Verisonen nicht, bringt bei beiden den gleichen Fehler.

    Sonntag, 23. Oktober 2011 09:24
  • Hallo Mark,

    also die beschriebene Konfiguration ist denkbar ungünstig.

    Um mit den bestehenden Mitteln eine funktionierende Lösung zu erhalten, würde ich folgendes machen.

    In den TMG MUSS noch eine Netzwerkkarte rein.

    Diese wird als DMZ (oder auch Perimeter) Schnittstelle deklariert. An diese schliesst Du die externe Schnittstelle direkt an.

    Die interne Schnittstelle des Edge hängst Du direkt ins interne Netzwerk.

    Das Routing auf dem TMG muss natürlich anders konfiguriert werden, damit der TMG die EXTERNEN Edge Adressen nach aussen Nated. Im Topologiebuilder wird die INTERNE Adresse des Edge veröffentlicht

    Versuchs mal so

     

    Gruß
    Falk

    Montag, 24. Oktober 2011 21:21
  • Vielen Dank für die Antwort.

    Ich habe diese Konfiguration mal probiert, geht ja recht schnell mit dem TMG. Leider bekomme ich ganz genau die gleiche Fehlermeldung wie ganz oben beschrieben.

    Aus lauter Verzweiflung habe ich nun folgendes gemacht und hoffe, dass dies nicht ein zu großes Sicherheitsrisiko darstellt.

    Ich habe die externe Schnittstelle des Edge Servers direkt ins Internet gehängt und die interne direkt ins LAN.
    Dann habe ich die lokale Firewall extrem restriktov eingestellt, dass lediglich die benötigten Dienste erlaubt sind. Ich dachte mir, dass der Edge selbst ja auch eine Firewall darstellt und das Risiko dadurch minimiert ist. So funktioniert es halt wenigstens...

    Was meint ihr bezüglich der Risiken dadurch? Noch ist es Testumgebung, aber ich habe langsam keine Ideen mehr wie ich das hinter die TMG bekomme.

    Ich hatte jetzt auch mal versucht, da der TMG ja nun eine Perimeterschnittstelle bekommen hat, die externe schnittstelle des Edges ins Internet zu hängen und die Interne dann an über die neue Perimeterschnittstelle laufen zu lassen. Aber auch dies misslingt leider.

    Dienstag, 25. Oktober 2011 08:01
  • Hi Mark,

    für den Testzweck ist es ja ganz gut, Produktiv würde ich das ganze so nicht laufen lassen.

    Zumindestens hast Du die Fehler quelle schon mal eingeschränkt.

    Der Fehler liegt also in der Konfiguration deines TMG. Die Kommunikation zwischen External und Edge Server wird nicht sauber durch den TMG geleitet.

    Wie sieht die Konfiguration aus ?

    Welche Listener gibt es, und welche Firewall Regeln ?

    Wie ist das Routing konfiguriert ?

    Nutzt Du NAT oder hast du Public IP's

    Mittwoch, 26. Oktober 2011 16:23
  • Ich versuche das ganze mal genau zu beschreiben. Dabei lasse ich die Simple URL´s weg, denn die gehen ohne Probleme über den TMG.

    Momentane Konfiguration im Testnetz welches funktioniert:
    1.1.1.2 / 30 <- externe Karte (Lync EDGE) interne Karte -> 192.168.103.10 / 24 GW: 192.168.103.6
    1.1.1.3 / 30
    1.1.1.4 / 30

    1.1.1.5 / 30 <- externe Karte (TMG) interne Karte -> 192.168.103.6 / 24

    Hier geht praktisch alles am TMG vorbei und der Edge ist lediglich als SecureNAT client auf der internen Schnittstelle konfiguriert.

     

    Diese Konfiguration will nicht gehen:

    1.1.1.2 / 30 <- externe Karte (TMG) interne Karte -> 192.168.103.6 / 24
    1.1.1.3 / 30
    1.1.1.4 / 30
    1.1.1.5 / 30

    192.168.103.111 / 24 <- externe Karte (EDGE) interne Karte -> 192.168.103.10 / 24 GW:192.168.103.6
    192.168.103.112 / 24 alle dieses GW: 192.168.103.6
    192.168.103.113 / 24

    In der Topologie ist folgendes eingetragen
    sip.domain.de -> 1.1.1.2, web.domain.de -> 1.1.1.3, av.domain.de -> 1.1.1.4
    Diese lasse ich also unberührt wie in der funktionierenden Konfiguration.

    Nun die Regeln:
    1. Protokoll SIPS von 192.168.103.111 intern nach extern (SIP ausgehend)
    2. Ports 3478, 443, 50000-59999 TCP eingehend und 3478, 50000-59999 UDP empfangen Senden von beliebig zu 192.168.103.113 (AV)
    3. Port 443 TCP eingehend von beliebig nach 192.168.103.112 (WebConf)
    4. Port 443, 5061 TCP eingehend von beliebig nach 192.168.103.111 (AccessSip)
    5. Ports 3478, 443, 50000-59999 TCP ausgehend und 3478, 50000-59999 UDP Senden Empfangen von 192.168.103.113 nach extern (AV Out)

    Dann die Netzwerkregeln:
    1. Quelle 192.168.103.113 -> Ziel Extern -> NAT auf 1.1.1.4 (AV)
    2. Quelle 192.168.103.112 -> Ziel Extern -> NAT auf 1.1.1.3 (WebConf)
    3. Quelle 192.168.103.111 -> Ziel Extern -> NAT auf 1.1.1.2 (SIP Access)

    Ich habe diese TMG konfiguration auch ausprobiert, wenn ich in der Topologie die internen Adressen angebe, aber das geht leider genausowenig.
    Also hatte ich dort dann mal versucht mit
    sip.domain.de -> 192.168.103.111 u.s.w.

    Vielleicht hast Du eine Idee? Auch mit einer Perimeter Konfiguration wollte es nicht klappen. Will ich auch ehrlich gesagt nicht unbedingt noch einführen wenn es so auch irgendwie gehen könnte.

     

    Donnerstag, 27. Oktober 2011 07:58