Citrix disconnects => MTU probleem ?

[StarWing]

Opstelling:

-Hoofdkantoor: 3mbit/512K
-Branch office: 512K synchroon
Met elkaar verbonden dmv een VPN verbinding.
2 Citrix machines op hoofkantoor
Aantal citrix clienten op branch office, zowel thin clients als fat clients.

code:

citrix|--Firebox firewall/VPN--Cisco router---internet----firebox Soho Edge---Clients
      |
citrix|

Nu hebben wij het probleem dat de citrix op de branchoffice af en toe disconnect, soms meerdere malen per dag, soms een hele week niet. Deze komt vanzelf terug op. Soms is het op meerdere computers, soms op 1 enkele
De grootste verdachte in deze zaak waren/zijn imho de internetlijnen, maar ik kan niet echt een fout ontdekken. Pings zijn ea zijn goed. Het is zeer moeilijk om een oorzaak te vinden voor deze disconnects.

In mijn zoektocht naar iets anders, stoot ik op het volgende artikel op www.thomaskoetzing.de

I have connections or disconnection problems with a DSL/ADSL
--------------------------------------------------------------------------------
Most likely it is a problem with the MTU size of the Client. Default MTU size for ethernet is 1500 but for DSL it's 1492.
Change the MTU value to 1492 decimal in the registry key
HKLM\system\currentcontrolset\services\tcpip\parameters\interfaces\ID for Adapter

Met bijhorend artikel op de MS site:
http://support.microsoft....spx?scid=kb;en-us;q314825

Op dat moment ging bij mij een belletje rinkelen.. Hey ik ken dat van ergens. Zou dit probleem bij ons ook kunnen voorkomen.
Het probleem is dat mijn kennis van TCP/IP niet zo erg groot is. Misschien dat hier iemand kan helpen. Ik heb het artikel van MS meerdere malen gelezen, maar ik kom er niet echt op mijn eentje uit.
Ik heb alvast wat tests gelopen:
pingen naar het interne IP adres van de branch office:

code:

ping 192.168.111.1 -f -l 1372
Pingen naar 192.168.111.1 met 1372 byte gegevens:
Antwoord van 192.168.111.1: bytes=1372 tijd=148 ms TTL=63
Antwoord van 192.168.111.1: bytes=1372 tijd=148 ms TTL=63
Antwoord van 192.168.111.1: bytes=1372 tijd=161 ms TTL=63
Antwoord van 192.168.111.1: bytes=1372 tijd=151 ms TTL=63

Dit is de maximale packetsize die de verbinding aankan. Een MTU van 1400 als ik mij niet vergis dus.
Grotere waarde geeft deze melding:

code:

Pakket moet worden gefragmenteerd, maar DF is ingesteld.

Indien ik ping naar een citrix server hier lokaal, is de MTU waarde niet dezelfde als de MTU waarde aan de andere kant.

code:

ping 192.168.1.15 -f -l 1472
Pingen naar 192.168.1.15 met 1472 byte gegevens:
Antwoord van 192.168.1.15: bytes=1472 tijd=2 ms TTL=128
Antwoord van 192.168.1.15: bytes=1472 tijd=2 ms TTL=128
Antwoord van 192.168.1.15: bytes=1472 tijd=2 ms TTL=128
Antwoord van 192.168.1.15: bytes=1472 tijd=2 ms TTL=128

Dit is terug de maximale waarde. Grotere waarde geeft dezelfde error.

Zou dit _de_ oorzaak kunnen zijn van het disconnect probleem ?

Een ander probleem van deze opstelling is dat printjobs soms niet verwerk worden/doorkomen vanaf de branch office. Op de lokale site hebben wij met dezelfde clients geen probleem. Deze kunnen zonder enig probleem printen op de citrix server.

Dit zou kunnen verklaard worden om dat sommige paketten niet goed doorkomen en daardoor verloren gaan.
Indien dit het MTU probleem betreft, zou dit probleem dus ook van de baan kunnen zijn.

Mijn vraag nu:
-Hoe kan ik ontdekken of wij te maken hebben met dit probleem "black hole router"
of zijn er nog verdere test nodig om zeker te zijn ?
-Wat kan ik doen om dit te omzeilen, is het voldoende van de workaround te volgende op MS site ?

[Verwijderd]

Mijn eigen ervaring met MTU problemen zijn dat dan bv alleen ping wel werkt of tracert maar de rest niet.
Dus als jij zegt dat het soms wel werkt en soms niet lijk me geen MTU probleem.

[elevator]

Vermoedelijk inderdaad geen MTU probleem (aan de andere kant - je kan het gewoon proberen aan te passen natuurlijk)

Wat je denk ik in de gaten moet houden is of je VPN tunnel wel blijft staan of dat deze bijvoorbeeld niet rekeyed op momenten dat je sessies er uit vliegen.

Voor de disconnects zou je ook nog eens kunnen kijken naar http://support.microsoft.com/kb/q170359/ - door die enigszins op te hogen kan je soms wat stabiliteit winnen

[thamoosio]

wellicht dat het een TE simpele insteek is, maar ik neem aan dat de firebox een redelijke debuglog kan produceren (ken het product niet te best) Kan je daar niet wat wijzer uit worden?

[avon]

Dergelijk MTU probleem heb ik vorig jaar April met Solcon ondervonden.

Daarbij werd de MTU gewijzigt in connectie met AMS-IX - Solcon Dronten; de
achterliggende server was daarna moeilijk bereikbaar. Dit kwam overigens alleen op
Windows machines naar voren.

Staat onder je ICMP firewall rule "pakket fragmentatie toestaan" wel aan?

[ Voor 6% gewijzigd door avon op 28-03-2006 14:53 ]

[Grolsch]

ik heb ook een keer zo'n tering MTU probleem gehad, omdat Euronet spontaan besloot MTU waardes aan te passen op hun routers naar klanten toe.

pingen gaat wel goed, alle mail blijft in de queue staan, RD werkt wel, AD replicatie werkt niet.
Alle leveranciers schuiven de bal naar een ander, en uiteindelijk een case bij MS "gekocht", en die hadden het probleem binnen een dag gevonden.

Zelfs op GoT al een topic over gehad

Je zoekt je een ongeluk.

Wat je kunt doen is de logging level op je VPN tunnel / DSL verbinding op high zetten.

Kijken of er iets gerejected, of iets niet gesnapt wordt

[ Voor 19% gewijzigd door Grolsch op 28-03-2006 15:02 ]

[paulhekje]

Als je met allerlei settings wil gaan testen is iperf een perfecte tool: http://dast.nlanr.net/projects/iperf/iperf_faq.html

[alt-92]

Overigens heb je in DHCP management in Windows 2000 en 2003 de mogelijkheid om een MTU-gerelateerde optie mee te geven die een kleinere waarde opgeeft.
Kijk naar Scope option > 026 (MTU Option).

PS: de meningen over ignore DF bit op je firewalls zijn nogal verdeeld.
Hou in het achterhoofd dat er géén controle plaatsvind of het fragment wel "fris" is, want er is geen mechanisme voor dan alleen een frag sequence nummer.

Ooit wel eens gehoord van fragrouter?

[ Voor 3% gewijzigd door alt-92 op 28-03-2006 20:16 ]

[StarWing]

Alvast bedankt voor de antwoorden.

Dit was slechts een wilde gok van mij. Het was misschien mogelijk dat dit de oplossing was voor het probleem.

Het probleem treedt ook niet constant op, soms gaat het een tijdje goed (zoals nu)

Ik ga iig eens aan de slag met die tool.
Qua logging is de watchguard niet echt duidelijk. Ik heb de log al meermaals doorgespit, maar kan niets rellevants vinden.

[StarWing]

Daarnet telefoon gehad van een gebruiker in het andere kantoor.

Terwijl iedereen zat te werken zonder problemen, zat er 1 gebruiker met een reconnectie. Nu snap ik het helemaal niet meer.

Kan dit liggen aan een slechte switch? De switch die daar staat is door een lokaal bedrijf geinstalleerd. Is van het merk "Micronet". Missschien heeft die er iets mee te maken ?

[Verwijderd]

Als het een managed switch is, zou ik die user eens op een andere poort zetten.

[ShellGhost]

Zat diegene te werken toen de disconnect gebeurde?
Hoe zijn de timeouts gezet voor citrix?
Hoe zijn de timeouts gezet voor de vpn clients als die er op gezet zijn athans?
Zijn er timeouts op de vpn server gezet?

[StarWing]

Beide personen zaten gewoon te werken. Afaik zijn de timeouts gewoon standaart ingesteld. Citrix is geinstalleerd door een externe firma.

Het is helaas geen managed switch.

Waar kan ik de timeouts van citrix veranderen ? Wij draaien PS4.

VPN timeouts denk ik niet dat dat een probleem is aangezien de ene user er wel last van had en de andere niet. VPN wordt hardwarematig geregeld.

[ShellGhost]

Hoeveel current connections kan de vpn aan?
Kan het zijn dat iemand probeerd te connecten en er iemand uit gooid om zo toegang te krijgen?

[Verwijderd]

StarWing schreef op zaterdag 01 april 2006 @ 11:15:
Het is helaas geen managed switch.

Prik hem toch maar eens over voor de lol (als je nog een gaatje over hebt)

[StarWing]

Het is geen probleem van die ene user, soms is het user A, soms user B, soms user C. Het is echt volledig willekeurig.

VPN wordt hardwarematig opgezet. Dit is een permanente verbinding. De users maken zelf geen VPN aan.

Current connections => Dit weet ik niet. Aangezien er maximaal 5 verbindingen tegelijk actief zijn, denk ik niet dat dit een probleem is.