Probleem met alle vormen van remote support

[YellowOnline]

Ik heb zo'n wazig probleem dat ik het eens met Tweakers wil delen zodat er meegedacht kan worden.

We hebben een nieuwe klant en on-site hebben zowel zij als wij een Sophos UTM. Tussen beide sites is er een ipsec tunnel. Deze constructie hebben we voor tientallen andere klanten en werkt.

Maar.

Bij deze klant is remote support onmogelijk langzaam. File transfers etc. zijn geen probleem, maar RDP, Dameware, Teamviewer etc. gaan voor geen meter vooruit. Het is een tenenkrullende slow-motion. In één richting trouwens: als we bij de klant on-site zijn en naar onze site remoten, dan is er geen probleem.

Als test heb ik op een nieuwe server een Teamviewer Quicksupport module geïnstalleerd.Vanuit het netwerk van mijn werk gaat dit heel traag, maar van bij mij thuis gaat het normaal. Met andere woorden: het probleem ligt niet aan de UTM bij de klant maar aan de onze.

Vraag is: wat kan het zijn dat enkel op deze klant effect heeft behalve de VPN die nochtans identiek geïnstalleerd is als voor andere klanten? In de firewall is ook niets te zien - geen wonder, aangezien ik bij wijze van test (het is allemaal nog gloednieuw en ongebruikt) de firewall de facto opengegooid heb (10.0.0.0/8 --- Any ---> 0.0.0.0).

Wat ik nog het minste snap is de Teamviewer test, aangezien TV tot zover ik weet langs de WAN-zijde gaat en niet via de VPN, tenzij dat programma tegenwoordig zo intelligent is te zien dat er ook een interne route is en het geen intermediate server meer gebruikt.

Goeie ideeën zijn welkom, want ik moet binnenkort Exchange 2016 installeren en heb geen zin dat in slow-motion te doen

Edit
Wacht eens, met alles zo op een rijtje te zetten, ik moet misschien in onze firewall kijken ipv. in die aan de andere kant. Hmz, daar zie ik ipsec traffic dat gedropped wordt van ons richting hun oude appliance. Nochtans is de VPN zeker en vast op de nieuwe ingesteld.

code:

21:11:44    Default DROP    UDP 89.xxx.xxx.130:54579 -> 87.xxx.xxx.220:500  len=28  ttl=56  tos=0x00
21:11:59    Default DROP    UDP 89.xxx.xxx.130:45382 -> 87.xxx.xxx.220:500  len=28  ttl=56  tos=0x00

Misschien heeft het er niets mee te maken maar ik vind het toch vermeldenswaardig.

[ Voor 15% gewijzigd door YellowOnline op 10-05-2017 21:19 ]

[Thralas]

Misschien kun je met Wireshark achterhalen *waarom* het traag is, om zo wat dichter bij de oorzaak te komen?

[YellowOnline]

Thralas schreef op woensdag 10 mei 2017 @ 21:29:
Misschien kun je met Wireshark achterhalen *waarom* het traag is, om zo wat dichter bij de oorzaak te komen?

Dat heb ik net gedaan en 't enige dat ik zie is een hele hoop dit in beide richtingen:

code:

GVSP    70  Unknown Format (0x1a) [Block ID: 7388158586631621632 Packet ID: 100680576] Unknown Payload Type (0x0)

Interpreteren is een andere zaak. Ik zal daar eens op googlen.

Edit
Hmz, GVSP staat voor GigE Vision Streaming Protocol

Runs on the UDP protocol. Covers the definition of data types and the ways images can be transferred via GigE.

Ik kan niet zeggen dat ik mij in bekend gebied begeef - ik ben Mark Russinovich niet. Maar dat lijkt niet te kloppen. 't Is nogal onwaarschijnlijk dat RDP een protocol voor industriële camera's gebruikt.

[ Voor 37% gewijzigd door YellowOnline op 10-05-2017 21:57 ]

[Thralas]

Dat lijkt me een overduidelijke foute dissect. GVSP is GigE Vision over UDP. Gewoon laten dissecten als 'udp' dus.

How does Team Viewer establish a Remote Desktop Connection?

Als dat nog recent is, dan is het primaire transportprotocol van Teamviewer UDP. Je zou in ieder geval moeten kunnen zien of dat verkeer direct tussen de client/server loopt, zonder IPsec..

IPsec zou je dan misschien zelfs helemaal kunnen disablen? Dat zou immers geen factor moeten zijn, want dat het allemaal via WAN zou moeten lopen onderschrijf ik..

Daarna zit er vrees ik niets anders op dan te controleren of alles dat aan de ene zijde verstuurd wordt ook aan de andere kant weer aankomt. Misschien twee pcap'jes naast elkaar leggen?

[LodanMax]

Wat ik nog het minste snap is de Teamviewer test, aangezien TV tot zover ik weet langs de WAN-zijde gaat en niet via de VPN, tenzij dat programma tegenwoordig zo intelligent is te zien dat er ook een interne route is en het geen intermediate server meer gebruikt.

Check in dat geval wel even de Teamviewer settings, want hij kan bij verkeerde configuratie inderdaad de LAN pakken in plaats van WAN.

[Will_M]

IPV6 vs. IPV4?

[YellowOnline]

LodanMax schreef op woensdag 10 mei 2017 @ 22:23:
[...]


Check in dat geval wel even de Teamviewer settings, want hij kan bij verkeerde configuratie inderdaad de LAN pakken in plaats van WAN.
[afbeelding]

Dit scenario is voor als je TV via IP in het LAN gebruiken wil en kan je sowieso niet instellen op een TVQS module, dus "per ongeluk". Dat heeft hier niets mee te maken dus. Vraag is of TV altijd via WAN gaat of via LAN wanneer hij merkt dat die host wo sneller bereikbaar is. Dat is geen oplossing, maar het zou verklaren waarom het probleem niet enkel met RDP en Dameware is.

wimmel_1 schreef op woensdag 10 mei 2017 @ 22:31:
IPV6 vs. IPV4?

Hmz, kan je wat uitbreiden hierover?

Thralas schreef op woensdag 10 mei 2017 @ 22:04:
[...]

IPsec zou je dan misschien zelfs helemaal kunnen disablen? Dat zou immers geen factor moeten zijn, want dat het allemaal via WAN zou moeten lopen onderschrijf ik..

Dat moet ik morgen bespreken alvorens te doen, aangezien de VPN verbreken misschien al impact kan hebben in dit stadium (misschien wordt er vannacht data overgepompt of zo).

Daarna zit er vrees ik niets anders op dan te controleren of alles dat aan de ene zijde verstuurd wordt ook aan de andere kant weer aankomt. Misschien twee pcap'jes naast elkaar leggen?

Dat hoop ik te vermijden.

[ Voor 38% gewijzigd door YellowOnline op 10-05-2017 22:45 ]

[Will_M]

YellowOnline schreef op woensdag 10 mei 2017 @ 22:40:
[...]


Hmz, kan je wat uitbreiden hierover?

Je kunt niet alles zomaar "tunnelen" over een HTTPS verbinding. Terredo (IPV6) tunneling kán een mooi protocol zijn maar 't kan zo maar eens niet mogelijk zijn waardoor je verbinding dus over andere routes gaat lopen en je dus eigenlijk nog steeds niet weet of 't wel écht veilig is.

[ik222]

Wat voor internetverbinding heeft de klant? Is het mogelijk dat die een net wat kleinere MTU heeft dan andere klanten? Dat kan bijvoorbeeld al omdat het een PPPoE verbinding betreft.

Daarnaast sowieso ook controleren of de lijn echt stabiel is. Bijvoorbeeld met een flink aantal pings. Packetloss kan best juist bij dit soort UDP based streaming protocollen voor meer issues zorgen.

[ Voor 35% gewijzigd door ik222 op 10-05-2017 23:06 ]

[Asteroid9]

Packetloss of latency zijn makkelijk aantoonbaar, dit soort vage problemen hebben meestal een andre oorzaak. Bijvoorbeeld fragmentatie waar ik222 ook op doelt, dus MTU/MSS controleren.
Andere optie is asynchrone routering, te controleren met traceroutes in beide richtingen.

Intelligente FW opties zoals IPS en anti-spoofing kunnen roet in het eten gooien, maar dat zou snel uit de logging naar voren moeten komen.

Zelf zou ik met 90% zekerheid gokken op MSS, gelet op de symptomen.

[Gomez12]

Wellicht een stompzinnige gedachte, maar aangezien die sophos ook content-scanning doet blijkbaar heeft het bedrijf niet bijv een default rule dat al het uitgaande verkeer maar max 20kb/s mag pakken oid. En daarbovenop dan allerlei uitzonderingen voor http/ftp etc zodat je file-transfers wel goed gaan.

En ik zou idd ipv6/ipv4 even nakijken want het kan best zijn jullie of de klant ook over ipv6 proberen te communiceren en dat hij dan een totaal andere route pakt (oftewel niet via de tunnel).

Btw, je zegt dat het allemaal gloednieuw is. Is het ook bij jullie in-house geconfigureerd? Is er dan niet ergens een cache oid die is blijven hangen op een interne netwerk-setting bij jullie in-house....

[YellowOnline]

@ allen hierboven: tegen 10:00 komt mijn cellega die beter is met netwerken als ik. Ik bespreek jullie suggesties dan met hem.

Gomez12 schreef op donderdag 11 mei 2017 @ 09:28:
Wellicht een stompzinnige gedachte, maar aangezien die sophos ook content-scanning doet blijkbaar heeft het bedrijf niet bijv een default rule dat al het uitgaande verkeer maar max 20kb/s mag pakken oid. En daarbovenop dan allerlei uitzonderingen voor http/ftp etc zodat je file-transfers wel goed gaan.

Dat zou niet verklaren waarom het van een ander netwerk wél goed gaat. Vandaar het vermoeden dat het probleem eerder aan onze kant ligt dan aan de andere kant.

En ik zou idd ipv6/ipv4 even nakijken want het kan best zijn jullie of de klant ook over ipv6 proberen te communiceren en dat hij dan een totaal andere route pakt (oftewel niet via de tunnel).

Dat ga ik inderdaad nu eens controleren.

Btw, je zegt dat het allemaal gloednieuw is. Is het ook bij jullie in-house geconfigureerd? Is er dan niet ergens een cache oid die is blijven hangen op een interne netwerk-setting bij jullie in-house....

Bij ons ziet het er op het eerste zich identiek geconfigureerd uit als bij andere klanten. Maar: ik heb wel gezien dat deze VPN via een nieuwe appliance loopt en niet via dezelfde als de anderen.

[YellowOnline]

Ja hoor. Door de MTU te veranderen werkt alles nu naar behoren. Pfff, daar kan je lang op zoeken. Ik had gedacht dat zo'n probleem zich ook elders zou uiten (bv. downloads). Dankuwel iedereen voor jullie suggesties!