locked
Ein nicht SYN-Paket wurde verworfen? RRS feed

  • Frage

  • Guten Morgen,

    bei mir treten seit dem Aufbau des TMG NLB Clusters merkwürdige Phänomene auf. Hier kurz was zur Situation. Es gibt ein Hauptstandort mit dem TMG und 4 Standorte sind über Telekom MPLS verbunden und sollen über den TMG mittels Webproxy ins Internet gehen. Alle Standorte sind dabei im internen Netzwerk zugeordnet. Nun zum eigentlichen Problem, bei 3 Standorten ist der Zugriff über Webproxy kein Thema. Bei einem Standort gibt es ein Problem, dass die eine hälfte der Mitarbeiter zugriff ins Internet erhalten und die andere hälte bekommen nach 2-3 Seitenaufrufe folgende Meldung:

    Protokolltyp: Firewalldienst 
    Status: 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. 
    

    Die Mitarbeiter sind alle im gleichen Adressbereich. Ich kann mir da keinen Reim darauf machen.

    Hoffe mal jemand von Euch hat eine Idee woran dies liegen kann?

     

    Grüße an alle hier

    speerle

     

    Mittwoch, 25. August 2010 05:36

Antworten

  • Hallo, so, nach langer Zeit wiedermal ein Update und ein gutes dazu :) Das Problem hat sich inzwischen gelöst. Es lag ein Problem mit unserem MPLS Provider zusammen. Der Standort der nicht funktionierte war mit 3x 155MBit Glas angebunden. Irgendwie gab es Probleme mit dem Etherchannel. Was genau sagen die Jungs leider auch nicht. Jedenfalls seit der Provider Änderungen vorgenommen hat läuft es wie geschmiert. Herausfinden konnte ich dies über einen mehrtägigen Live-Mitschnitt über Wireshark und 2 Tage Analyse der Netzwerkdaten. Vielen Dank an alle helfenden Köpfe :) Speerle
    Montag, 22. November 2010 14:24

Alle Antworten

  • Hi,

    schon sehr merkwuerdig. Ich kann mir nur vorstellen, dass es was mit der NLB Konfiguration und der NLB Affinitaet zu tun hat, dass Antwortpakete von der Haelfte der Nutzer ueber den einen TMG node gehen, die Rueckantwort aber nicht ueber den gleichen TMG geht, sondern ueber den anderen und dann die Meldung kommt, das SYN-Pakete verworfen werden. Iich wuerde mir also mal die NLB Konfiguration ansehen!
    NLB ist ueber das in TMG integrierte NLB aktiviert? Hast Du das fuer das externe und interne Interface aktiviert? Vor dem TMG Array steht ein Router etc.?
    Taucht das Problem bei den Usern schon immer auf seit Besetehen des Cluster?
    Unicast oder Multicast Modus? An den Switchen ist entsprechend alles konform konfiguriert? ARP Eintraege, IGMP Multicastgruppen konfiguriert etc.?
    Was zum Lesen:
    http://technet.microsoft.com/en-us/library/ff849728.aspx

     


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Mittwoch, 25. August 2010 06:20
  • Hallo Marc,

    das Problem besteht seit Verwendung des TMG. Mit der Firebox früher hatten wir nie Probleme.

    Sowohl das interne als auch externe Netzwerk sind geclustert. Im moment müssen wir noch Unicast verwenden. Wir werden aber aufgrund der neuen Telefonanlage im Laufe dieses Jahres noch auf Multicast wechseln. Die Switchports sehen gut, keine Drops, CRC oder sonstige Fehler. Werde am Wochenende das Netzwerkrouting von OSPF auf statische routen runterbrechen um dort einen Fehler einzugrenzen. Das Netz ist folgendermaßen aufgebaut: Standortrouter - MPLS Router (Telekom) - MPLS Router (Telekom) Hauptstandortswitch (Layer 4) - TMG - Layer 2 Switch (non managed) - Router (Provider).

    Bei zwei Mitarbeitern am gleichen Standort tritt folgendes auf:

    1. Mitarbeiter: Aufruf einer Kundenseite über den Proxy und kommt am zweiten TMG Knoten rein. Seite wird dargestellt.

    2. Mitarbeiter: Aufruf der gleichen Kundenseite über den gleichen TMG Knoten, die Seite wird nicht dargestellt und es kommt obige Fehlermeldung.

     

    Wenn der zweite Mitarbeiter nun als Proxy Server direkt den 2. Knoten einträgt kann er für 3-4 Minuten normal Webseiten aufrufen. Danach kommt wieder obige Meldung.

    Schau mir erstmals den von dir geposteten Technet  Artikel an. Was mir noch einfällt, könnte dies mit dem aktivierten CARP zusammenhängen damit sich die Knoten untereinander den Cache austauschen können?

    Nun ist erstmal lesen angesagt und die Installation den SP1 doch auf heute abend verlegen :)

     

    Danke

    speerle

    Mittwoch, 25. August 2010 07:15
  • Hi,

    hoert sich recht schwierig an, dass in diesem Forum zu loesen. IMHO handelt es sich bei solchen Problemen "immer" um Probleme auf den unteren Netzwerklayern, welchem Du mit Windows und TMG Monitoring nicht beikommen wirst. Ich denke, Du musst da auf Netzwerkebene ansetzen und ggfs. den Netzwerktraffic sniffen. Umstellung von OSPF auf statische Routen waere schon mal ne Option. Unicast NLB kann auch je nach Switchkonfiguration durch das Switch Flooding zu merkwuerdigen Symtomen fuehren.
    Das CARP daran Schuld ist, kann ich mir nicht vorstellen, da der Cache ja nur auf die Knoten verteilt wird und es nicht zu den SYN Meldungen kommen sollte, welche ja eher daraufhin deuten, dass beim 3Way Handshake was nicht passt. Zum testen koenntest Du aber trotzdem mal besagte Webseite vom Caching ausschliessen.
    Kannst Du auch mal das Ergebnis von NETSH TMG SHOW NLBHOOKRULES und SHOW CONNECTIONS sowie SHOW CREATIONS posten?


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Mittwoch, 25. August 2010 08:15
  • Guten Morgen,

    nachdem ich gestern das Netzwerk auseinadergenommen habe und dort keinen Fehler im Routing noch verworfene Packete finden konnte, war heute morgen der NLB dran. Nach dem öffnen des Netzwerkausgleichsmanager staunte ich allerdings nicht schlecht. Dort sind einige Fehler drin die für jedes Netzwerk, bis auf die IP, wie folgt lauten:

    Der RPC-Server ist auf dem angegebenen Computer nicht verfügbar. Fehler bei der Verbindungsherstellung mit Cluster2.FIRMA.td

    Konfigurationsinformationen von Host "Cluster1.FIRMA.td" für Cluster "10.100.0.2" werden geladen

    Konfigurationsinformationen von Host "Cluster2.FIRMA.td" für Cluster "10.100.0.3" werden geladen

     

    Diese Meldung taucht für alle virtuellen Netzwerke auf. Mist, wie lässt sich das beheben?

     

    Donnerstag, 26. August 2010 07:52
  • Hi,

    das ist normal. TMG blockt die RPC Kommunikation zwischen den beiden TMG Servern, wenn Du den NLB Manager direkt auf dem TMG aufrufst.


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Donnerstag, 26. August 2010 08:13
  • Hallo,

    danke für die Antwort. Mist, dachte schon das wärs gewesen... :-(

    Mir ist noch was weiteres aufgefallen. Auf dem zweiten Knoten, normalerweise gehe ich immer über den ersten, kommt alle paar Minuten folgende Fehlermeldung:

    Auf diesem Computer wird nun die angegebene Verzeichnisinstanz gehostet, doch konnte diese von Active Directory-Webdiensten nicht bedient werden. Von Active Directory-Webdiensten wird in regelmäßigen Abständen erneut versucht, den Vorgang auszuführen.

     

    Verzeichnisinstanz: ADAM_ISASTGCTRL

    LDAP-Port der Verzeichnisinstanz: 2171

    SSL-Port der Verzeichnisinstanz: 2172

     

    Den Einträgen im Ereignislog zu folge treten diese Fehler seit 2 Wochen auf. Die beiden 2 Wochen zuvor war diesen Meldungen nicht da. Der Dienst ISASTGCTRL steht auf dekativiert und auf dem ersten Knoten auf aktiviert. Kann man irgendwo sehen auf welchen AD Webdiensten er sich verbinden will?

    Donnerstag, 26. August 2010 08:28
  • Hi,

    man kann aber Firewall Policies bauen, damit die Nodes ueber den NLB Manager kommunizieren koennen. Muesste die Ports mal raussuchen wenn Du das brauchst.
    Zu dem ISASTGCTRL Dienst. De rist normalerweise auf jedem TMG aktiv und steuert die Kommunikation zwischen AD-LDS und der lokalen Registry, wo der TMG seine Konfig lokal speichert. Wenn man den TMG in ein EMS Array haengt, wird der Dienst deaktiviert.
    http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-Storage-101.html
    Gehe ich recht der Annahme Du hast ein Standalone Array? Dann ist der ISASTGCTRL Dienst nur auf dem aktuellen Node (Array Manager) aktiv und auf dem Passive Node nicht.
    Das mit den AD Webdiensten kannst Du auch ignorieren. Windows 2008 R2 installiert die AD Webdienste mit, die normalerweise zur Verwaltung von AD-DS und AD-LDS gelten. Die Meldung kannst Du IMHO ignorieren.
    http://blogs.msdn.com/b/adpowershell/archive/2009/04/06/active-directory-web-services-overview.aspx


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Donnerstag, 26. August 2010 08:59
  • Hallo,

    wir haben nur 2 TMG Server. Für EMS würde doch ein dritter Server ohne TMG Installation benötigt werden, oder?

    Werde das Problem erstmal bis Samstag ruhen lassen. Wenn laufend das Telefon klingelt kann man sich schlecht auf andere Dinge konzentrieren :-)

    Donnerstag, 26. August 2010 09:30
  • Hi,

    ja, ein dritter Server als EMS, aber so als Standalone Array ist auch OK und erklaert, warum der ISASTGCTRL nur auf einer Maschine (dem Array Manager) gestartet ist


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Donnerstag, 26. August 2010 09:31
  • Hallo,

    jetzt ist mir noch was aufgefallen. Unter dem Punkt Vernetzung -> Netzwerke -> Intern gibt es den Punkt neue Netzwerkbereiche hinzuzufügen. Wenn nun eine neue Adresse mittels Adapter hinzufügen klicken, kommen auf beiden Knoten die Netzwerke zum Vorschein. Bei mir heissen die auf beiden Knoten gleich.

    Doch der Unterschied des internen Netzes ist beim Cluster 1 gibt es ca. 50 interne Adressbereiche mehr als beim zweiten Knoten. Bei den anderen Netzwerken stimmen diese 1:1 überein. Nur, wie krieg ich jetzt Knoten 1 dazu diese Adressbereiche auf Knoten 2 zu replizieren?

    Donnerstag, 26. August 2010 10:42
  • Hi,

    wenn Du da unterschiedliche Ergebnisse siehst beim Hinzufuegen des Adapters, dann vermute ich mal, dass die Routingtabellen / Netzwerkeinstellungen auf den beiden Nodes unterschiedlich sind. Hast Du die IP-Einstellungen / Routing schon mal auf beiden Knoten verglichen?


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Donnerstag, 26. August 2010 11:21
  • Hallo Zusammen,

    ich bin mal so frei und hänge mich hier dran.

    Nachdem ich nun mehrere Tage vermeintlichen Fehlern hinterhergestiegen bin, habe ich Gott sei Dank diesen Beitrag hier gefunden.

    Nachdem die geblockte RPC Kommunikation, der gestoppte ISASTGCTRL, sowie die Fehler der AD Webdienste nicht wirklich relavant sind - wieso dauert dann das Starten der TMGs bei mir so lange?

    Wenn ich zum Beispiel den zweiten TMG neustarte, braucht er bestimmt 5 Minuten bis ich mich wieder anmelden kann. Was macht die Kiste nur so lange. In den Logs kann ich nichts aufregendes mehr entdecken. 

    Hat jemand einen Tipp für mich?

    Viele Grüße,

    Martin

    PS:

    >>man kann aber Firewall Policies bauen, damit die Nodes ueber den NLB Manager kommunizieren koennen. >>Muesste die Ports mal raussuchen wenn Du das brauchst.

    Kann mir jemand die nötigen Ports nennen? Ist ja wohl nur optischer Natur aber ...

    --------------------------------

    Nachtrag: Standalone Array aus zwei TMG auf Win 2008 R2, NLB nur auf Extern

    Dienstag, 14. September 2010 11:44
  • Vielen Dank!!

    MaK

    Mittwoch, 15. September 2010 19:58
  • Hallo,

    so, nach langer Zeit kann ich wieder etwas schreiben. Das Problem besteht weiterhin und ich konnte es nicht weiter eingrenzen.

    Mein Ansatz ist nun, die freigegebenen Adressbereiche auf dem internen Netzwerkadapter auf 10.0.0.0-10.255.255.255 umzustellen. Ändert sich bei dieser Vorgehensweise auch etwas am Routing? Nun müssten alle 10.0.0.0/8 Adressbereiche auf den internen Gateway zeigen. Muss ich manuell auf den statischen Routen noch etwas machen? Die würde ich bei dieser Gelegenheit über route delete entsorgen oder macht dies der TMG selbst?

    Da ich mich über ein TSG auf einen Server einwähle und anschließend zum TMG verbinde, stelle ich mir damit selbst ein Bein?

    Teste übers Wochenende mal und berichte ob es was gebracht hat :)

    Freitag, 17. September 2010 11:58
  • Hi,

    ja, Du musst das Routing ueber die TMG Konsole entsprechend anpassen (neue Topologieroute) im Knoten Vernetzung. Mit Route Add per CLI macht man das seit TMG nicht mehr.


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Freitag, 17. September 2010 12:22
  • Hallo,

    heute gab es eine Interessante Neuerung.

    Um der Sache auf den Grund zu gehen erfolgte eine Wireshark installation auf dem Client. Nach wenigen Minuten des surfens folgte die leere Seite im IE. Als Wireshark gestoppt und nachgesehen. Komischerweise waren dort überhaupt keine Fehlermeldungen zu sehen. Ganz im Gegenteil, laut Wireshark wurden Daten, in Form von .gifs, an den Browser übertragen. Dieser zeigte diese nur nicht an. Der nächste Punkt ist, die Seite wird zwar nicht dargestellt, läuft aber nicht in einen Timeout. So zeigte sich der IE ca. 5 Minuten mit einer weißen Bildschirmseite.

    Das werde ich morgen genauer untersuchen den inzwischen glaube ich, dass ein anderes Programm dazwischen funkt und den IE irgendwie beeinflusst. Morgen geht es weiter und ich berichte Euch morgen Abend :-)

     

    Speerle

    Montag, 20. September 2010 18:18
  • Hallo,

    leider nichts neues von der TMG Front.

    Würde es denn etwas bringen den 2. Knoten aus dem Array zu entfernen bzw. wo macht man dies überhaupt im dt. TMG?

    Mittwoch, 22. September 2010 15:34
  • Hi,

    ob das was bringt? Keine Ahnung, ich vermute so aus der Ferne eher nicht!
    TMG aus dem Array entfernen wie hinzufuegen:
    http://www.isaserver.org/tutorials/Configure-Forefront-TMG-integrate-TMG-Array.html


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

    zum Testen deaktivere ich den zweiten Firewall-Clusterknoten. Somit kann ich mit Bestimmtheit sagen, dass es nicht an der NLB Konfiguration liegen kann.

    Mal noch eine ganz andere Frage. Könnte dieses Problem evtl. sogar mit dem externen Netzwerk zusammen hängen? Zeitgleich mit dem TMG erhielten wir auch einen neuen ISP Provider.

    Die Routing Tabellen sind bei beiden Knoten gleich, die Netzwerkeinstellungen ebenso und auch die Konfiguration. Ansonsten bleibt mir nur noch die beiden Kosten platt machen, neu installieren und hoffen das es klappt. Bin ziemlich ratlos und langsam hängen die Chefs im Nacken... :-(

    Habt ihr noch einen Tip was man prüfen könnte, evtl. auch auf dem Client?

     

    speerle

    Mittwoch, 22. September 2010 17:59
  • Hi,

    die NLB Konfig bleibt aber trotzdem aktiv, wenn Du einen Knoten deaktivierst. Deaktiviere lieber das NLB und gib dem einen Knoten dann die VIP-Adressen. Eine weitere Idee habe ich auch nicht und ich befuerchte, Du wirst da einen PSS Call aufmachen muessen.


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

    hätte dazu eine Frage und keine Testmaschine. Bei klick auf Netzwerklastenausgleich-Integration deaktivieren bietet er nun an.

    ja: die NLB Integration zu deaktivieren und die Einstellungen zu verwerfen.

    nein: die NLB Integration zu deaktivieren und die Einstellungen beizubehalten.

     

    Was bedeutet dies den genau?

    Donnerstag, 23. September 2010 03:04
  • Hi,

    NLB deaktivieren behaelt die NLB Einstellungen wie VIP etc. bei, deaktiviert aber NLB, die andere Option deaktiviert NLB und loescht auch die NLB Einstellungen. "Ja" entspricht also dem NLBClear aus dem NLBCLEAR Tool von ISA 2006.


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Donnerstag, 23. September 2010 03:52
  • Hallo Marc,

    leider brachte das deaktivieren des LNB nichts. Problem besteht weiterhin :(

    Was mich bei der Meldung etwas irritiert ist:  "die über keine vorhandene Verbindung mit dem Forefront TMG-Computer verfügt".

    Der TMG kann also die Anfrage nicht bearbeiten da er das Netz nicht kennt oder interpretiere ich das nun falsch? Daher würde ich folgendes einmal testen. Der Standort verfügt neben der MPLS auch eine SDSL Leitung. Daher wäre es möglich diesen Standort über VPN am ISA und einer Cisco ASA zu verbinden und somit das MPLS zu umgehen. Dadurch vereinfache ich das Routing ungemein und bekomme quasi eine 1:1 Verbindung.

    Dazu noch eine Frage, kann der ISA bei einer S2S Verbindung das vorhandene "Externe" Netzwerk verwenden oder muss es eine separate Netzwerkkarte sein?

     

    speerle

    Sonntag, 26. September 2010 09:47
  • Hi,

    Extern ist am TMG alles, was nicht in anderren Netzwerken / IP Adressbereichen am TMG eingerichtet ist, also brauchst Du dafuer nicht zwingend eine weitere Netzwerkkarte. Das Routing entscheidet dann was Extern ist.


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

    habe endlich die Regel gefunden, welche Du brauchst, um den DCOM Traffic vom NLB Manager zu erlauben:
    Port 10.000 - 11.000 TCP outbound zwischen den TMG Servern.


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 4. Oktober 2010 05:02
  • Guten Morgen,

    diese Woche ist etwas interessantes passiert. Ein kleiner Standort mit 6 Mitarbeitern ist über VPN am Hauptstandort verbunden. Der Zugriff ins interne Netz ist möglich. Doch hatten diese die gleichen Probleme mit dem Internetzugang. Seit Montag dieser Woche existieren die Probleme bei allen Mitarbeitern nicht mehr! ABER das Surfen über HTTP mit Proxy  ist jederzeit möglich und läuft stabil und schnell. Das interessante dabei ist, der Zugriff auf verschlüsselte Webseiten ist nicht möglich. Im TMG Log sieht man kurz die Überprüfung des Traffic und sofort danach kommt die Meldung das ein RST Paket die Verbindung trennte. Die genaue Fehlermeldung kann ich erst am Montag nachliefern. Die Webeite als Direktzugriff einzutragen brachte keine Änderung.

    Sind die voreingestellten Werte für Cache und Proxyeinstellung gut oder gibt es hier Optimierungsbedarf bzw. was sind erprobte Erfahrungswerte?

     

    speerle

     

    P.S. @Marc, danke für die Ports und die Hilfe :)

     

    Samstag, 9. Oktober 2010 08:00
  • Hi,

    welche Werte fuer den Proxy Cache genommen werden ist individuell und von Firma zu Firma abhaengig von Userverhalten, Bandbreite und vielen anderen Faktoren. Du kannst die Cache Effizienz nur selbst mit dem Perfmon monitoren und feinjustieren. Sag mal: Habt Ihr im MPLS Netzwerk noch eine gehostete Security Loesung durch die der Traffic geht? Schon merkwuerdig diese Probleme


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Samstag, 9. Oktober 2010 12:21
  • Hallo, so, nach langer Zeit wiedermal ein Update und ein gutes dazu :) Das Problem hat sich inzwischen gelöst. Es lag ein Problem mit unserem MPLS Provider zusammen. Der Standort der nicht funktionierte war mit 3x 155MBit Glas angebunden. Irgendwie gab es Probleme mit dem Etherchannel. Was genau sagen die Jungs leider auch nicht. Jedenfalls seit der Provider Änderungen vorgenommen hat läuft es wie geschmiert. Herausfinden konnte ich dies über einen mehrtägigen Live-Mitschnitt über Wireshark und 2 Tage Analyse der Netzwerkdaten. Vielen Dank an alle helfenden Köpfe :) Speerle
    Montag, 22. November 2010 14:24