Sommige sites weigeren (volledig) te laden (unifi)

[hobielasseel]

Mijn installatie bestaat uit volgende

1 usg die op WAN1 verbonden is met b-box3 van proximus, rechtstreekse verbinding met PPPoe Login (geen VLAN ID meegegeven)
De lanpoort van de USG gaat naar een 24P POE switch van UBI, daar zitten 3 AP's op (2 x LR en 1 x NanoHD) 3 x unifi camera, 1 x cloudkey Gen2 Plus. en dan nog wat gebruikelijke kantoor apparatuur.

Sinds het begin van de installatie (juni 2020) waren er her en der klachten van mijn collega's dat sommige sites niet of niet volledig werkten.
Na testen komt dit zowel voor via de wi-fi als via bekabelde verbinding. bv. onze bankapplicatie heeft hier last van, ander vb. depositphotos.com, paypal

alles is reeds gecheckt, ips ligt af, firewall staat op (1 allow regel na) alles default.
De usg is al eens volledig vergeten en daarna weer geadopteerd.
Aan proximus kan het ook niet liggen want pppoe op b-box zelf is nog actief en als ik via bbox surf werkt het perfect.
Ik heb ook al eens op lan2 een 2de lan gemaakt, in die lan blijft het probleem ook bestaan.
Idem als ik mijn wan op deze poort aansluit.

Heeft er iemand soms een idee wat ik nog over het hoofd zie of zeker ook moet checken ?

Alvast bedankt voor jullie input

[selder]

Hangt er vanaf wat het probleem exact is: TCP connectie, DNS, bandbreedte...

[CCatalyst]

Sommige sites werken niet, anderen wel, altijd dezelfde sites, is doorgaans het gevolg van een MTU die te hoog ingesteld staat.

[hobielasseel]

bandbreedte is het niet, snelheidstest geeft normale snelheden aan. (74 down, 22up), dns vermoed ik ook niet (als ik manueel dns instell werkt het ook niet) ...

[hobielasseel]

Sommige sites werken niet, anderen wel, altijd dezelfde sites, is doorgaans het gevolg van een MTU die te hoog ingesteld staat.

die staat momenteel op auto, als ik die manueel instel staat die op 1452 wat naar mijn idee de correcte waarde is voor proximus, of ben ik mis ?

[Data technicus]

Kan zijn dat u alleen ipv6 sites kunt laden en de ipv4 sites niet. Heb dit ook al mee gemaakt.

[hobielasseel]

Kan zijn dat u alleen ipv6 sites kunt laden en de ipv4 sites niet. Heb dit ook al mee gemaakt.

usg deelt ipv4 adressen uit, ipv6 staat niet ingesteld

[hobielasseel]

Kan zijn dat u alleen ipv6 sites kunt laden en de ipv4 sites niet. Heb dit ook al mee gemaakt.

usg deelt ipv4 adressen uit, ipv6 staat niet ingesteld, websites die problemen geven hebben allen ipv4 adressen

[CCatalyst]

die staat momenteel op auto, als ik die manueel instel staat die op 1452 wat naar mijn idee de correcte waarde is voor proximus, of ben ik mis ?

Dat weet ik niet, hangt af van de concrete situatie. Als er bv nog een apparaat tussen de USG en de aansluiting zit, of als je bv nog een tunnel hebt (VPN) dan gaat er nog wat vanaf, afh van de implementatie. Met ICMP echo (ping) kan je MTU proefondervindelijk vaststellen door de DF Don't Fragment bit zetten en dan de packet size arbitrair verhogen tot je een ICMP foutmelding "Fragmentation required" terug krijgt omdat het pakket te groot is. Dat is dan je MTU, enfin, de MTU is dan [de laagste waarde waarop die foutmelding komt - 1]. De foutmelding kan ook gewoon "Destination unreachable" afh van de ping implementatie.

MTU is m.i. wel het probleem maar het veranderen van de setting zal mogelijks weinig helpen. Beter is zowel MTU als TCP MSS Clamping aan te passen, normaliter (maar hangt ook weer af van de situatie) is je huidige MSS clamping dan 1412 (1452-40). Probeer eens 1446 (1406) en 1440 (1400) enz en zie of dat helpt. Gezien de meeste sites blijkbaar wel laden zal je MTU/MSS momenteel niet erg afwijken en zou een kleine correctie naar beneden moeten volstaan. Het zou kunnen dat de USG automatisch de TCP MSS setting mee aanpast als je de MTU verandert.

[StarWing]

Welke dns servers gebruik je ?
Toch nergens een Pi-Hole of aanverwanten geïnstalleerd die aan adblocking doet ?

[DarkV]

Sinds het begin van de installatie (juni 2020) waren er her en der klachten van mijn collega's dat sommige sites niet of niet volledig werkten.

Over welke sites gaat het dan... geef eens enkele voorbeelden.

Trouwens welke firmware/controller versies draai je op je Unifi toestellen ?

[CCatalyst]

Over welke sites gaat het dan... geef eens enkele voorbeelden.

Hij heeft er gegeven in de openingspost. PayPal is een typische site waarop problemen met MTU zich vertonen.

[DarkV]

Oeps... had ik overgelezen... enfin, hier totaal geen probleem met beide websites (op een UDM Pro).

[hobielasseel]

die staat momenteel op auto, als ik die manueel instel staat die op 1452 wat naar mijn idee de correcte waarde is voor proximus, of ben ik mis ?

Dat weet ik niet, hangt af van de concrete situatie. Als er bv nog een apparaat tussen de USG en de aansluiting zit, of als je bv nog een tunnel hebt (VPN) dan gaat er nog wat vanaf, afh van de implementatie. Met ICMP echo (ping) kan je MTU proefondervindelijk vaststellen door de DF Don't Fragment bit zetten en dan de packet size arbitrair verhogen tot je een ICMP foutmelding "Fragmentation required" terug krijgt omdat het pakket te groot is. Dat is dan je MTU, enfin, de MTU is dan [de laagste waarde waarop die foutmelding komt - 1]. De foutmelding kan ook gewoon "Destination unreachable" afh van de ping implementatie.

MTU is m.i. wel het probleem maar het veranderen van de setting zal mogelijks weinig helpen. Beter is zowel MTU als TCP MSS Clamping aan te passen, normaliter (maar hangt ook weer af van de situatie) is je huidige MSS clamping dan 1412 (1452-40). Probeer eens 1446 (1406) en 1440 (1400) enz en zie of dat helpt. Gezien de meeste sites blijkbaar wel laden zal je MTU/MSS momenteel niet erg afwijken en zou een kleine correctie naar beneden moeten volstaan. Het zou kunnen dat de USG automatisch de TCP MSS setting mee aanpast als je de MTU verandert.

Dank je heb hier net een aantal zaken getest en mijn maximum packet size is 1452 (vastgesteld via cmd), heb nu al geprobeerd op 1452 en 1412, ook al kleinere waarden geprobeerd en probleem blijft.

Waar nu echter mijn aandacht plots door getrokken wordt zijn onderstaande meldingen

3
Afwijkingen op 2 apparaten

16:00
Hoge TCP latency voor Client xxx

16:00
Client xxx
heeft problemen met het resolven van een domeinnaam naar een IP adres (DNS timeout).
16:00
Client xxx
heeft problemen met het resolven van een domeinnaam naar een IP adres (DNS timeout).

Dns staat aan wan-side op google dns, lan side- staat automatisch

Ook hier alweer verschillende keren geprobeerd alles op auto te zetten, ook geprobeerd met cloudflare dns. Niks dat helpt.

Any Ideas ?

Ps. Mijn excuses voor late antwoord

[DarkV]

Welke firmware/controller versies draai je ?

[hobielasseel]

Welke firmware/controller versies draai je ?

V6.0.41

Echter probleem is al van begin installatie aanwezig, echter nu pas tijd gevonden om er mij diepgaander mee bezig te houden. Er zijn intussen al wel wat updates geweest. Alle apparaten (usg, switch en AP'S) hebben ook de recentste firmwares.

[redman]

Die 'meldingen' die je krijgt van TCP latency krijg ik ook.
Die zijn eerder het gevolg van Controller versie 6.
Bij mij werkt nochtans alles perfect.

[hobielasseel]

Die 'meldingen' die je krijgt van TCP latency krijg ik ook.
Die zijn eerder het gevolg van Controller versie 6.
Bij mij werkt nochtans alles perfect.

Ja had dit ook al gelezen, ik probeer momenteel gewoon alles uit te sluiten.

De piste van MTU size heb ik uitgebreid bekeken, zowel mtu size als tcp mss clamping heb ik gewijzigd maar niks dat helpt.

[DarkV]

V6.0.41

En welke firmwares ? (dus op je AP's)

De piste van MTU size heb ik uitgebreid bekeken, zowel mtu size als tcp mss clamping heb ik gewijzigd maar niks dat helpt.

Heeft er ook niets mee te maken... dan zou het een algemeen probleem zijn.

[murdock447]

Ik heb tot hier toe nog niet gereageerd maar het topic wel gevolgd en kan alleen maar beamen dat ik een vergelijkbaar probleem kan vaststellen maar tot nu enkel maar op 1 specifieke site opvallend last van gehad. Ik beschik over een uitgebreid unifi gebaseerd netwerk en kan volgende opmerkingen maken:
- al die “foutmeldigen” ivm. Latency en dergelijke zijn inderdaad begonnen met versie 6 maar zijn volgens mij “vals” daar ik geen enkel probleem ondervind....sinds de laatste update zijn ze wel geminderd in aantal maar nog steeds van dezelfde aard
- het niet willen laden van een site heb ik af en toe met hln.be ....raar is dat ik tegelijkertijd op meerdere toestellen zowel ipad als pc en android gsm naar die site ga en het dan op sommige toestellen wel gaat en andere helemaal niet!
- ook al vanalles uitgetest maar vind geen oplossing buiten het vermoeden dat het dus een samenloop van verschillende oorzaken moet zijn en niet 1 unieke oorzaak....want waarom op dezelfde moment niet werkend bvb. op mijn ipad terwijl mijn vrouw op dezelfde moment er wel aan kan met haar ipad(zelfde generatie ipad).

Het netwerk in zijn geheel heeft geen problemen, ik draai meerdere gameservers voor simracing tegelijkertijd zelf aan het simracen en mijn vrouw netflix kijken geen probleem ook de vpn naar een tweede locatie voor het bekijken van ipcamera’s blijft perfect werken.

Maw. tot nu toe geen verklaring te vinden....alle netwerktoestellen zijn voorzien van de meest recente firmware(geen beta) en er zijn continu een veertigtal clients ter plaatse en dan nog een tiental via de vpn naar de tweede locatie.
Ik gebruik 2 vdsl lijnen (proximus) in load balancing op usg pro 4 van daar naar 24 poorts switch(via fiber) en vanuit deze laatse naar een 5 tal kleinere switchen met daaraan een aantal ip cameras en 3 tal ap’s.
Tweede locatie is de standaard usg met daaraan 2 ap’s en een vijftal ip camera’s en enkele occasionele andere “clients”.

[hobielasseel]

V6.0.41

En welke firmwares ? (dus op je AP's)

De piste van MTU size heb ik uitgebreid bekeken, zowel mtu size als tcp mss clamping heb ik gewijzigd maar niks dat helpt.

Heeft er ook niets mee te maken... dan zou het een algemeen probleem zijn.

De LR ap's draaien op 4.3.24.11355
De AC PRO op 4.3.24.11355
DE NANO HD op 5.43.19.12493

Wat misschien ook interessant is om te vermelden: als ik via vpn verbind van op een andere locatie dan heb ik via de vpn verbinding geen problemen.

Ook interressant om te vermelden: probleem stelt zich op alle clients zowel wired als wireless

[DarkV]

Waarom draai je sommige AP's op de 4.x en andere op de 5.x firmware ?

Nu ja, als ook je wired clients er last van hebben dan kan dat moeilijk de oorzaak zijn.

Heb je trouwens IDS/IPS aanstaan ?

[devilkin]

De 5.x firmware is nog niet beschikbaar voor die specifieke AP's.

[DarkV]

Is inderdaad nog beta... https://community.ui.com/releases/UAP-F ... ca1080a0de

[blaatpraat]

Doe eens een nslookup vanop een client naar een niet werkende site.
En doe dit met zowel de default DNS, als die met de WAN DNS, als met een externe (bijvoorbeeld Google).