none
IP v6 on TMG für Direct Access RRS feed

  • Frage

  • Hallo zusammen,

    ich komme einfach nicht bei meiner Konfiguration des TMG (standard 2010 SP1 deutsch) in Zusammenhang mit Direct Access weiter (beides auf Windows Server 2008 R2).

    Die Konfiguration der Infrastruktur habe ich soweit durchgeführt und im LAN kann ich auf IP V6 Basis erfolgreich pingen.

    Allerdings lässt das TMG den DA Client scheinbar auf Grund von IP V6 Supportproblemen nicht in das Netzwerk verbinden.Ebenfalls schlagen V6 Pings (Ping -6) aus dem LAN auf das TMG und umgekehrt fehl, wobei IP V4 Pings funktionieren.

    In der Protokollierung des TMG sehe ich bei allen V6 Zugriffsversuchen/Pings immer folgende FM bzgl. der abgewiesenen V6 Datenpakete:

    0xc0040041  FWX_E_UNSUPPORTED_IPV6_DROPPED (In den Details steht: "Ein Paket wurde verworfen, weil das IP v6 Protokoll nicht unterstützt wird)".

    Wichtig:
    - Ich habe zunächst DA installiert
    - Dann habe ich per Regedit den Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\ISACTRL] "CTRL_SKIP_DISABLE_IPV6_PROTOCOLS"=dword:00000001 gesetzt (<- Hier vermute ich den Fehler, dass dieser Schlüssel etvtl. nicht übernommen wurde, da das LOG vom TMG "V6 als nicht unterstützt" beschreibt!).
    - Dann TMG installiert
    - Dann das Skript von MS bzgl. der neuen Systemrichtlinien für DA durchgeführt und diese in den Systemríchtlinien konfiguriert.

    Habt ihr noch eine Idee??

     

     

    Donnerstag, 18. November 2010 20:17

Antworten

Alle Antworten

  • Hi,

    hat denn DA nach der Konfiguration und vor der TMG Installation funktioniert? Also auch echte DA Zugriffe von Extern oder Intern nur ISATAP verwendet?
    Der Regkey sollte richtig sein, habe das neulich auch mal zusammengefasst:
    http://www.it-training-grote.de/blog/?p=4077
    An der Reihenfolge sonst sehe ich auch kein Problem, habe ich in meiner Umgebung auch so gemacht, die war allerdings Englisch (2x).
    Also ist nur eine Vermutung von mir, dass es am deutschen Windows/TMG liegt. Das hat sich in der Vergangenheit schon einige Male gezeigt, doch besser ein englisches System zu nehmen. Koenntest Du das mal testen?
    Sonst kannst Du auch mal mit Regmon etc. schauen, ob der TMG den Key beim Starten der Dienste ueberhaupt anspricht

     


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Donnerstag, 18. November 2010 23:25
    Moderator
  • Hi Marc,

    danke für deine Tipps:

    - DA Funktionstest habe ich vor der TMG Installation nicht durchgeführt, wobei ich noch garnicht am Problem "Remote Zugang DA" arbeite, sondern bereits der V6 Ping im Netzwerk zu TMG oder umgekehrt nicht funktioniert (Meldung, wie berichtet "V6 is unsupported").

    - Der TMG Prozess liest meinen Regschlüssel lt. Regmon ein! Inwiefern er die Einstellung dann auch intern verarbeitet kann icht icht sagen.

    Aufgefallen ist mir noch Folgendes: In den Systemrichtlinien des TMG unter "Verschiedene" gib es den Punkt "IP V6 Infrastruktur", diesen habe ich in keinem HowTo berücksichtigt gefunden . Ist dieser Punkt evtl. der Ersatz für den Regschlüssel?  -> Diesen habe ich aktiviert, jedoch auch keine Änderung.

    Hast du sonst noch eine gute Idee? Wie gesagt, erstes Ziel wäre Ping von und zu TMG im LAN zuzulassen.. Dann wäre ich schon weiter.

    Freitag, 19. November 2010 12:31
  • moin paul,

    die regel die du erwähnst ist die systemrichtlinie 48. hier ist icmpv6-traffic von allen v6-clients zu tmg-localhost erlaubt - könnte dir also wenn ich das richtig gelesen habe helfen.

    wäre sicherlich reizvoll da mal mit tmg hinzubekommen - habe mich da selber noch nicht rann getraut. wie schauts mit uag aus - ist das keine option für dich?


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 19. November 2010 16:24
  • ergänzung: der für den regkey ist die systemrichtlinie imho kein ersatz, aber für dein ziel was das pingen angeht!
    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 19. November 2010 16:27
  • Hi Jens,

    der Regkey baut nicht die Systemrichtlinien, das macht das Skript, der Regkey soll nur vor TMG Installation verhindern, dass TMG beim Setup den IPV6 Support komplett deaktiviert!


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Samstag, 20. November 2010 07:21
    Moderator
  • Hallo zusammen, zunächst vielen Dank für die Hilfe.

    Grundsätzlich funktioniert DA jetzt auf dem TMG!

    Die Clients können sich via Teredo verbinden!

    Es war tatsächlich ein REG-Key (welcher genau kann ich nochmal schauen, jedoch nicht unterhalb  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\ISACTRL] ), welcher beim erneuten Ausführen des VB-Skripts für DA/TMG (s. DA-Teamblog) dann korrekt gesetzt wurde.

    Ich habe noch ein paar weitere Fragen, evtl. können Sie mir hier noch ein Feedback geben, dafür wäre ich sehr dankbar.

    Als vorab Rahmeninformation, evtl. resultieren ja hieraus meine Fehler:

    Ich habe 2 DHCP Server im Netz, die unter IPv6 lediglich Serveroptionen verteilen.

    Neben dem korrekten Option „Domänensuchliste“ sind bei beiden DHCPs unterschiedliche Werte in der Option: „IPV6-Adressliste für DNS-Server für rekursive Namen“ konfiguriert:

     

    DHCP1: fe80::ad01:44ea:fcbb:63f6

    DHCP2: "::1","fec0:0:0:ffff::1"


    Ich habe hier manuell nichts eingestellt und bin unsicher ob diese Konfiguration Problem emit sich bringt.

    Was mir ansonsten aufgefallen ist und damit zusammenhängend die Fragen ob dies korrekt ist, oder ich einen Fehler habe:

    1.       Die verbindungslokale IPv6 Adresse lautet auf den internen Servern im Netz: fe80::b0d1:f71f:17c4:db97%20 (bei einem Beispielserver).

    Ist dies in Ordnung? Ich habe keinen IP6 DHCP Scope vergeben und auch keine manuelle V6 Konfiguration der Schnittstellen vorgenommen.

    2.       Unter Tunneladapter (ISATAP) bekommt jeder Server komischer Weise 2 Adressen im Format:

    2002:bc6f:d4a:1:0:5efe:192.168.115.25
    2002:bc6f:7122:1:0:5efe:192.168.115.25

    Wieso erhält jeder ISATAP-Adapter 2 Adressen? Ist das normal?

    3.       Im DNS registriert wiederum wird für unseren Beispielserver folgende Adresse:

    2002:bc6f:7122:0001:0000:5efe:c0a8:7319
    2002:bc6f:0d4a:0001:0000:5efe:c0a8:7319

    Beim Ping auf den Beispiel-Server antwortet dann wieder die ISATAP Adresse des Adapters (s.o.) und nicht die Adresse im DNS! Und bei NSLOOKUP antwortet der DNS Server ebenfallsmit den 2 Adressen der ISATAP Schnittstelle.
    Sind die DNS –Einträge und die ISATAP-Adressen der Schnittstelle evtl. die Gleichen, nur in anderer Darstellungsweise?

    4.       Ist es normal, dass ich den NLS nicht von einem Direct Access Client aus ansprechen kann, jedoch vom LAN aus?

     

    5.       Derzeit habe ich keine Zertifikatssperrlisten zum Internet hin veröffentlicht. Dies kann ich tun. Würden Sie anraten, dass die Zertifikatssperrlisten per HTTP für jedermann im Internet einsehbar veröffentlicht werden oder gibt es hier eine Möglichkeit den Zugriff zu sichern. Oder sehen Sie es als unbedenklich?

     

    6.       Ca. 50% meiner Server registrieren sich nicht mit V6 Adresse (bzw. der ISATAP Adresse) im DNS Server und sind somit nicht per DA erreichbar. Die Server sind fast alle VMs und unterscheiden sich vom Schnittstellentyp/Konfiguration nicht von Servern die korrekt registriert wurden. Auch haben sie, wie die im DNS registrierten Server, jeweils 2 ISATAP Adressen erhalten. Ein ipconfig/registerdns bringt weder Ergebnis noch Fehler. Haben Sie hier einen Debug-Ansatz?

     

    7.       Leider funktioniert der DA-Zugriff bisher nur per Teredo. Sobald UDP 1433 gesperrt ist, versucht der Client scheinbar eine Verbindung per SSL aufzubauen, scheitert jedoch, ohne dass ich den Grund kenne. Der TMG meldet die eingehende SSL Verbindung und akzeptiert diese auch, sagt jedoch nach Verbindungaufbau direkt, dass diese ordnungsgemäß durch ein FIN-Paket beendet wurde. Hier muss ich nochmal debuggen, oder haben Sie eine spontane Idee?

     

    8.       In der DA-Konsole erhalte ich folgenden Hinweis:

     

    „Der für die Teredokonnektivität erforderliche Netzwerkdatenverkehr wird durch die Windows-Firewall blockiert. Stellen Sie sicher, dass der folgende Netzwerkdatenverkehr zulässig ist: (ECHO-Anforderung - ICMPv6 – eingehend)“. Trotzdem habe ich keine Funktionseinschränkungen. Müssen hier spezielle Firewalleinstellungen getätigt werden (der TMG hat eigentlich alles, was mit DA zu tun hat aktiviert!)

     

    Dienstag, 23. November 2010 21:54
  • Hi,

    zu DHCP1: Wenn der noch die FE80 Adresse hat, wuerde ich mal schauen, ob der sein ISATAP Interface nicht korrekt aktiviert hat (NETSH INT IPV6 ISATAP). Da ggfs. noch mal gucken, das die "korrekte" FEC0 registriert wird. ISATAP ist bei beiden in der globalen Verweigerungsliste entfernt worden?
    1) Ja, ist OK, die FE80 ist quais das APIPA des IPv6 Protokolls
    2) hmm, bei mir haben die ISATAP Tunneladapter auf jedem Server nur eine IPv6 Adresse. Schau mal bei der Suchmaschine Deiner Wahl nach John Craddocks Vortrag zur Teched 2010: "WSV402 DirectAccess with UAG – Under the hood! John Craddock ... ". Die PPT gibt einen guten Ueberblick
    3) die gleichen Adressen sind das nicht, das nur die ISATAP Adresse antwortet ist AFAIK aber so bei Design. Dein Netz verwendet, wenn ISATAP aktiviert ist intern immer die ISATAP Adresse und nicht die "echte" IPv6 Adresse, welche Du per DHCP bekommen hast und vom DHCP Server/Client im DNS registriert wird. Wuerdest Du ISATAP im LAN ausschalten, haettest Du die IPv6 Adresse vom DHCP/DNS
    4) Ja, weil der von der NRPT ausgeschlossen wird. Du musst als NLS also eine Maschine nehmen, die nicht von DA Clients verwendet werden soll
    5) Unbedenklich. Sperrlisten werden ja auch bei kommerziellen CAs im Internet veroeffentlicht. Du koenntest die Sperrliste mit ISA/TMG publishen oder wenn Du ganz sicher sein willst, koenntest Du mit einer Automatik die Sperrliste in regelmaessigen Abstaenden von Deiner CA exportieren und dann auf einem Webserver importieren, welcher dann fuer die DA Clients erreichbar ist. Das ist aber IMHO recht aufwaendig. Publishen musst Du die Sperrliste, weil DA wegen des IP-HTTPS Tunnels (als Fallback wenn Teredo und 6to4 nicht geht) auf IP-HTTPS springt
    6) http://technet.microsoft.com/en-us/library/ee624056(WS.10).aspx
    7) Port 1433? Ist das nicht SQL? Teredo verwendet Port 3544. Ja, er scheitert wegen der Sperrliste. Der DA Client versucht erst 6to4, dann Teredo, dann IP-HTTPS udn dafuer muss die Sperrliste (CRL) erreichbar sein
    8) Ich denke, dass ist dem Konstrukt TMG und DA geschuldet, dass Du mit dem Script dem TMG ueberhaupt IPV6 "beibringen" musstest und die DA Konsole das nicht erkennt. Das VB Script sollte ja eigentlich die drei Systemrichtlinien aktivieren, welche ausreichend sind. Seit TMG wird die darunterliegende Windows Firewall auch von TMG ueber WPF ueberwacht. Ich denke, es handelt sich um ein Anzeigeproblem. Du solltest aber mal in der Windows Firewall preufen, ob die ICMP Echoanforderungen in einer Regel erlaubt sind.

     


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Mittwoch, 24. November 2010 05:51
    Moderator
  • Hi,

    danke für die Tipps,
    bin grade dabei das durchzuarbeiten.

    Eine frage bleibt:

    - Trotz CRL kann ich IP-HTTPs nicht ans laufen bringen.. ich stehe hier im Wald.

    Eine weitere Problematik stellt sich beim Veröffentlichen weiterer HTTPs Server nach Extern (z.B. OWA).

    Wie kann ich meinen Exchange (OWA) über das TMG veröffentlichen, denn die Systemrichtlinie, welche IPv6 Übergangstechnologien
    zulässt (die ja IP HTTPs inkludieren) ist auf "lokaler Host" geschlüsselt. Somit lauscht diese Regel auto. auf alle Anfragen auf Port 443 über sämtliche Netzwerkschnittstellen. Ich benötige aber ein Interface, welches für meine OWA-Veröffentlichung lauscht.. Hast du hier eine Idee?

    Samstag, 27. November 2010 18:38
  • Hi,

    die CRL ist denn sauber erreichbar? Kannst Du die CRL im Browser downloaden? Keine Zertifikatfehlermeldung?
    OWA wird weiterhin ganz normal veroeffentlicht. Die Regel laesst ja nur HTTPS Traffic zu und erstellt keinen Listener der auf HTTPS lauscht. Von daher kannst Du problemlos eine OWA Veroeffentlichung erstellen!


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Samstag, 27. November 2010 21:06
    Moderator
  • Hi Marc,

     

    ja die CRL erreiche ich im Browser (sind glaube 3 Dateien..).

    Wenn ich im TMG Log schaue, dann wendet er die "IPv6 Übergangstechnologie" Systemrichtlinie an, wenn ich meinen OWA ansprechen möchte. In irgendeiner Form muss doch das DA auf HTTPs Traffic lauschen und somit die Ports blockieren oder wie kann ich mir das vorstellen ?

    Samstag, 27. November 2010 21:17
  • Hi,

    dann liegt es bestimmt am Listener das IP-HTTPS auf alles lauscht. Du kannst das mit folgendem Befehl aendern (netsh http add iplisten ipaddress=1.2.3.4)


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 28. November 2010 07:51
    Moderator
  • Hallo Marc,

    habe jetzt mit dem Befehl die 1. der beiden Public DA Adressen angegeben.


    Resultat:
    IP HTTPs läuft immer noch nicht (wo habe ich einen Debbuging Ansatz bei dieser Technologie?)

    OWA: Wenn ich meine OWA-Veröffentlichung (deren Client HTTPs Anfrage über eine andere Öffentliche IP rein kommt als die beiden DA Adressen) vom Client teste, schlägt lt. Firewalllog noch immer die Systemrichtlinie des TMG (IPv6 Übergangstechnologien zulassen..) an,
    jedoch bekommt der Client nicht mal mehr (wie vor der Änderung) das Zertifikat des TMG angezeigt.

    Ich denke das liegt daran, dass zwar lt. Firewallsicht noch immer die DA Richtlinie angewendet wird, jedoch das Infertface nun nicht mehr
    auf meine Public-OWA-IP lauscht.

    Irgendwas müssen wir am TMG noch machen, damit er bei der Übergangsrichtlinie meine OWA-IP nicht einbezieht.
    Hilft es evtl. aus den DA SystemRichtlinien normale Firewallrichtlinien zu machen, die eben nur auf die gewünschten LocalHost IPs des TMG zeigen und dann die Systemrichtlinien deaktivieren, welche für die DA Übergangstechnologien zuständig sind, oder haben Systemrichtlinien eine andere/tiefere technische Bedeutung, als das lediglich Ziel bzw. Quelle immer der komplette Localhost mit all seinen IPs ist ?

     

    Sonntag, 28. November 2010 17:08
  • Hi,

    DA Troubleshooting ist echt tricky:
    http://technet.microsoft.com/en-us/library/ee624056(WS.10).aspx

    Wenn Du mit dem NETSH Befehl den Listener veraendert hast, dass nicht mehr auf alle IP Adressen das HTTPS gebunden ist, sollte das eingentlich funktionieren. Was sagt denn NETSTAT -AN |more?
    Klar kannst Du die Systemrichtlinienregeln ausschalten und diese statt dessen mit normalen Firewallrichtlinien abbilden. Waere mal einen Test wert.


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Sonntag, 28. November 2010 17:40
    Moderator
  • Hallo Marc,


    ich war letztendlich erfolgreich. Evtl. interessiert dich die Lösung:

    - OWA konnte ich nun wie angedacht veröffentlichen, indem ich die DA-Übergangstechnologien nicht als System- sondern Firewallrichtlinie gesetzt habe und genau definiert habe auf welche Interfaces d. Localhost gelauscht werden soll. Somit waren die anderen Adapter wieder zugänglich für HTTPs Verkehr.

    - IPHTTPs habe ich nach viel Troubleshotting ebenfalls lösen können. Trotz korrekter Einstellung in der DA Gui war auf das IPHTTPS Interface noch ein altes Computerzertifikat und nicht mein DA-Webserverzertifikat verbunden. Letztendlich steht die Lösung hier: http://itbloggen.se/cs/blogs/hasain/archive/2010/09/15/changing-the-iphttps-tunnel-certificate-in-directaccess.aspx

    Jetzt habe ich nur noch das Problem, dass manche Server Ihre ISATAP Adresse nicht ins DNS schreiben und ich sie somit nich per DA erreiche. Hier noch eine IDee ?

    Mittwoch, 1. Dezember 2010 21:55
  • moin paul,

    hast du mal den iphelper neu gestartet? ist die dyn-dns-registratur vlt. auf den adaptern ausgeschaltet?


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Mittwoch, 1. Dezember 2010 22:28
  • Hi,

    coole Sache. Gute Idee mit den Firewall- statt Systemrichtlinien. Auch wenn es haette so funzen muessen :-)

    Hmm, bei den Rechnern ISATAP Interface reseten, IP Stack reseten, IP Helper Dienst neu starten, mit Netsh diagnostizieren etc. Das kann alles moegliche sein :-(


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Mittwoch, 1. Dezember 2010 22:31
    Moderator
  • Ich werde mich nochmal reinhängen und dir feedback geben. das werden wir doch auch noch hinbekommen :) vG
    Donnerstag, 2. Dezember 2010 19:38
  • Hallo Marc,

    also das V6 DNS Problem lies sich letztendlich lösen in dem ich die V4 Host-A Einträge aus dem DNS entfernt hatte.

    Daraufhin registrierten die betroffenen Server ebenfalls ihre ISATAP Adressen korrekt. Hatte tausende Dinge getestet, aber am Ende war es so einfach :)

    Habe noch eine Frage zu DA an sich:

    - Ich habe erfolgreich aus allen möglichen WLANs und auch mit meiner UMTS Vodafone Flat getestet. Mein Client verwendet immer Teredo und wenn z.B. die Firewall ausgehend UDP xxx blockt, wird ja nun erfolgreich das IPHTTPS interface genutzt.

    Jetzt teste ich aber gerade mit der Kunden-UMTS Karte (kleinerer UMTS Volumentarif als meine Karte, die ich zum testen genutzt habe, aber ebenfalls Vodafone) und das System erhält sowohl eine Teredo Adresse (2001:0..) als auch eine Adresse auf dem Microsoft 6 to4 Interface (2002:..). In den Sicherheitszuordnungen auf dem DA Server sehe ich im Hauptmodus die Zuordnung der Teredo Adresse der Clients.

    Dennoch ist vom Client keine Verbindung gegeben. Hast du eine Idee ? Bisher hatte ich noch keinen Client gesehen, der das 6to4 Interface verbinden konnte.. Lt. TMG Richtlinien ist 6to4 aber frei! Irgendeinen Ansatz ? Kann ich 6to4 zur Not unterdrücken ?

    Samstag, 4. Dezember 2010 12:50
  • moin paul,

    was meinst du mit "unterdrücken"? du kannst die jeweiligen tunnel manuell beenden, z.b.:

    Abschalten: netsh int 6to4 set state disabled

    Einschalten: netsh int 6to4 set state default (oder enabled)

    ist dir damit geholfen?


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Samstag, 4. Dezember 2010 14:18
  • Hi,

    mit DA und UMTS hatte ich auch schon Fun. Evtl. ist da was fuer Dich dabei:
    http://www.it-training-grote.de/blog/?p=3536
    http://www.it-training-grote.de/blog/?p=3546
    Die Reihenfolge wie sich ein DA Client verbindet ist 1) 6to4. Geht 1) nicht, wird 2) Teredo verwendet, geht 2) nicht wird 3) IP-HTTPS verwendet und das sollte immer funzen, auch wenn die Performance dann nicht so gut ist, weil das ISPEC nochmal in HTTPS gekapselt wird


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Samstag, 4. Dezember 2010 14:23
    Moderator
  • und an stelle 0 müsste ipv6 nativ stehen?

    ;-)


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Samstag, 4. Dezember 2010 16:15
  • Hi,

    noch ne Anmerkung: Die IPv4 Eintraege aus dem DNS zu loesen fuer die betroffenen Server kann eine schlechte Idee sein, wenn es Applikationen gibt, die nicht native IPv6 koennen und irgendwelche Funktionen des Servers benoetigen wo nur IPv6 aktiv ist. Da gibt es einige, wo Probleme auftreten koennen!


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Samstag, 4. Dezember 2010 19:30
    Moderator
  • Danke Marc für den Hinweis.

    Ich habe die v4-Adressen aus dem DNS gelöscht, woraufhin dann ordnungsgemäß sowohl V6 als auch V4 eingetragen wurden :)

    Aber interessantes Thema: Ich habe Lync2010 in Betrieb genommen, jedoch weigert sich der Lync-Client den funktionierenden
    DA-Tunnel zu nehmen.

    Im Netzwerkmonitor auf dem Client sehe ich, dass er versucht den Lync-Sever per V4-Adresse zu erreichen, was natürlich nicht funktioniert.

    Wie bringe ich einer Applikation bei nicht V4 zu nutzen ? Ich dachte dies wäre OS-Angelegenheit!?

    VG.

    Montag, 13. Dezember 2010 20:52
  • Hi,

    na ja nicht immer ist es Sache des OS Stacks. Kommt ja immer darauf an, welche API die jeweilige Anwendung kontaktiert (Dual Layer / Dual Stack usw.). Wenn die Applikation die API Aufrufe dann nicht an den IPv6 Stack sendet, sieht es schlecht aus, so auch bei Lync:
    http://social.technet.microsoft.com/Forums/en/ocsplanningdeployment/thread/06fec504-569d-4dd1-a4f0-c29e1dbcb822
    Ich habe zum Beispiel einen Kunden, der hat ein bekanntes MIS System im Einsatz, das funzt auch nicht mit DA und die Entwickler haben keine Loesung dafuer


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 13. Dezember 2010 21:05
    Moderator
  • Danke,

    hmm dann muss ich mal schauen, wie ich Lync am sinnvollsten im TMG veröffentliche.

    Dies scheint gar nicht so einfach.. Hast du hier bereits Erfahrungen ?

    Montag, 13. Dezember 2010 21:14
  • Hi,

    nein, leider null Erfahrung. Habe auch noch nie nen Lync Server aufgesetzt und auch meine OCS Kenntnisse sind bescheiden, ich darf aber diese Woche einen Lync Server aufsetzen, aber nicht durch TMG veroeffentlichen, soll nur intern verwendet werden.
    Ich denke mal Lync und TMG koennte trotz des SIP Filters von TMG problematisch werden, so sich das nicht gegenueber OCS geaendert hat, wird zumindets SIP schwer


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 13. Dezember 2010 21:20
    Moderator
  • Hallo Marc,

     

    zunächst ein frohes neues Jahr.

    Eine Frage: Ich kann meine DirectAccess Clients nicht anpingen bzw. eine RDP Verbindung zu diesen von den internen Servern aufbauen.
    Entsprechend kann ich auch keine Software o.ä. verteilen.

    Von den Clients aus erreiche ich die Server (also unidirektional geht alles).

    Kennst du hierzu eine Lösung? Muss ich ggf. in der DA-Console unterhalb von "Infrastrukturservern" die "Verwaltungsserver" definieren oder ist das eine andere Baustelle ?

    Danke und Gruß

    Paul

    Montag, 3. Januar 2011 16:26
  • Hi,

    die Infrastrukturserver sind eine andere Baustelle!
    Schau mal hier: http://blogs.technet.com/b/tomshinder/archive/2010/10/29/test-lab-guide-demonstrate-uag-sp1-rc-directaccess-remote-management-blog-version.aspx Gilt zwar fuer UAG aber die Basic Troubleshooting Steps sind die selben.
    Wie versuchst Du denn Deine DA Clients zu erreichen? Welche IP-Adressen verwendest Du?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 3. Januar 2011 17:02
    Moderator
  • Hallo zusammen

    zusätzlich unbedingt beachten:

    Wenn ich von außen komme (Home-Netz) am MS DA Gateway des Unternehmens spielt der Router möglicherweise eine Rolle.

    Die AVM Fritzboxen sind seit Sommer 2010 auf IPv6 vorprogrammiert und deswegen erfolgt bereits (irrtümlich, übertrieben) schon heute einbe für einen Router unübliche Protokollspere in beiden Richtungen, die ich nicht mehr ohne AVM-Support aufheben kann.

    AVM FritzBox blockiert mindestens die Protokolle

    - Teredo

    - NetBIOS

    Grüße  Stefan L. Kohn

     


    Stefan L. Kohn Wolfsburg, Germany
    Samstag, 26. März 2011 16:33
  • Hallo Stefan

    "Stefan L. Kohn" schrieb im Newsbeitrag news:be3d0c8e-34fe-4f3c-a960-e1a9dd828808@social.technet.microsoft.com/Forums...

    Hallo zusammen

    zusätzlich unbedingt beachten:

    Wenn ich von außen komme (Home-Netz) am MS DA Gateway des Unternehmens spielt der Router möglicherweise eine Rolle.

    Die AVM Fritzboxen sind seit Sommer 2010 auf IPv6 vorprogrammiert und deswegen erfolgt bereits (irrtümlich, übertrieben) schon heute einbe für einen Router unübliche Protokollspere in beiden Richtungen, die ich nicht mehr ohne AVM-Support aufheben kann.

    AVM Fritz box im Unternehmen Einsatz.????

    Gruß
    Uwe

    Sonntag, 27. März 2011 14:48