Rest van het netwerk traag door bittorrent verkeer

[tMb]

Mijn vraag

Een van de laptops op mijn lokale netwerk draait een bittorrent client. Via een VPN client op de laptop maakt de laptop verbinding met internet. Zodra bittorrent download/upload heeft dat merkbare invloed op de rest van het netwerk.

• Hoe zou ik het beste kunnen onderzoeken hoe het komt dat een kleine bittorrent download/upload (max 1mbps) het hele netwerk naar benenden haalt?
• Hoe zou ik dit kunnen verhelpen?

Relevante software en hardware die ik gebruik

M'n netwerk heeft de volgende setup:
- Windows 10 client
- Unifi Access Point (UAP-IW-HD)
- Unifi Switch (US-8-60W)
- PfSense router/firewall
- Ziggo modem (in bridge mode)

Wat ik al gevonden of geprobeerd heb

Bittorrent client
Ongeveer 50 peers verbonden (max. ingesteld is 200).

VPN client
Bittorrent verkeer gaat van de client over VPN naar buiten via openVPN UDP.

Firewall
Bottleneck lijkt niet bij de firewall te liggen. CPU load is gemiddeld 4%, mem usage 19% en state table bevat ~200 states (van de 96.000)

Internetverbinding
Download verkeer gemiddeld 500kbps met pieken naar 1 mbps.
Upload verkeer gemiddeld 50kbps met pieken naar 100kbps

Switch
CPU 60%, memory 30%
Er is geen ander zwaar verkeer op de switch zichtbaar.

Access point
CPU 1,5%, memory 45%

Ik heb op dit moment geen traffic shaping (QoS). Zou ik dat moeten instellen? Lijkt me voor zo'n lage load niet nodig? Misschien een onzichtbare broadcast storm?

Ik zit een beetje vast

[Voor 3% gewijzigd door tMb op 12-02-2021 11:37. Reden: vraag verduidelijkt]

[Kasper1985]

Kan je de client niet limiteren naar een max snelheid?

Zo doe ik het als er via automation een linux iso begint te downloaden tijdens de werkdag. Je kan zelfs de snelheid limiteren tijdens bepaalde tijden in de meeste clients.

[tMb]

Ja zou ik kunnen doen, al lijkt de capaciteit die de client nu vraagt van m'n internetverbinding maar 1 mbps.

Ik heb bittorrent uitgezet op de client, VPN aan laten staan en verkeer gegenereerd over de VPN (een speedtest gedaan). Tijdens die test performen de andere clients op m'n netwerk wel goed. Het lijk dus door bittorrent te komen.

[Hackus]

Zodra bittorrent download/upload heeft dat merkbare invloed op de rest van het netwerk.

Dit is de oorzaak

[Kasper1985]

Ja bittorrent heeft merkbare invloed op de rest van het netwerk. Heeft als ik het goed heb met het aantal connections te maken.

Althans dit was in de tijd dat ik bij een ISP werkte. Zyxel modem/routers en experiaboxen liepen compleet vol als dit verkeerd stond ingesteld in de bittorrent client.

Verbaasd me wel dat je er last van hebt met jouw setup.

[tMb]

@Hackus Ik heb de vraag verduidelijkt:

Hoe zou ik het beste kunnen onderzoeken hoe het komt dat een kleine bittorrent download/upload (max 1mbps) het hele netwerk naar benenden haalt?

[Voor 68% gewijzigd door tMb op 12-02-2021 11:38]

[Kasper1985]

https://www.overclockers....network-so-much.18108264/

Hier staat het uitgelegd. Een oude post maar blijkbaar nog steeds van toepassing.

[Orion84]

Normaal is dat inderdaad vaak een probleem van een router die over z'n nek gaat van het aantal (half) open connecties. Maar als dit daadwerkelijk via een VPN tunnel loopt (waardoor het lokale netwerk dus überhaupt die connecties niet ziet), het aantal connecties al gelimiteerd is en hij ook ziet op zijn firewall dat dat binnen de perken blijft, dan lijkt me dat hier niet het probleem?

Wellicht eens testen zonder VPN? Wellicht dat de overdaad aan UDP verkeer op een of andere manier problemen veroorzaakt?

[Voor 7% gewijzigd door Orion84 op 12-02-2021 12:04]

[EricJH]

Begrens het aantal gelijktijdige verbindingen voor je torrent client tot een conservatieve waarde van 50 en begrens de uploadsnelheid tot maximaal 2/3 van de verbindingssnelheid van je verbinding. Als dat het gewenste resultaat levert kun je bij gelegenheid het aantal gelijktijdige verbindingen wat verhogen.

[DR!5EQ]

Ik ben het met je eens TS. De snelheid en het aantal peers is heel laag. Je gebruikt zeer degelijke apparatuur en er worden nog steeds aannames gedaan dat dit komt door de performance van de router. Ik draai ook een bittorrent client, dat over een vpn naar buiten gaat op een itx moederbord met een onboard cpu. Mijn router is de experiabox v10a en ik heb werkelijk nooit ergens last van. Ik tik dan ook zelden tot nooit meer dan 10 peers aan met uploaden. Met downloaden wel, maar ook daar heb ik nooit problemen mee ervaren.

Er worden hier een aantal aannames gedaan alsof we nog 10 jaar terug leven. Ik denk niet dat ik je probleem kan oplossen aangezien ik geen firewall of dergelijke apparatuur heb, maar wellicht kan ik je helpen troubleshooten.

Hoe zit je laptop met client aangesloten op het netwerk? via Wifi of kabel? Hoe zijn je overige apparaten aangesloten die dit probleem ervaren? Hoeveel peers zijn er verbonden op t moment dat het traag wordt? Wat ervaar je het meest als het probleem optreedt? Gaat de snelheid omlaag of is het de tijd die er nodig is om bijvoorbeeld een webpagina te laden?

[tMb]

Dank allemaal voor het meedenken.

Het is inderdaad niet het aantal connecties. Dat gaat via de VPN tunnel en op de router staan er voor de client maar twee connecties (UDP) open. Ook heb ik het aantal connecties gelimiteerd in de bittorrent client tot 5. En inderdaad ik draai pfSense op een i5, wat overkill zou moeten zijn.

M’n internetlijn (Ziggo) is 250mbps. Dus die is niet vol met 1 mbps torrentverkeer.

Een aantal gedachtes:
- De VPN via TCP ipv UDP lopen en dan kijken of het zelfde optreed.
- DNS resolving checken. Gaat dat mogelijk langs de VPN tunnel?
- Wireshark om verkeer van client te capturen. Wordt er naast VPN misschien veel lokaal verkeer gegenereerd dat mijn router niet ziet?

Client die bittorrent draait is wireless verbonden (5ghz). Clients die problemen ervaren zijn deels wireless, deels wired verbonden.

Ik hoop dat ik vanavond tijd heb om verder te troubleshooten. Ik post dan een update

[tMb]

Nog een gekke bevinding. Als ik kijk naar de round trip time (rtt) van de WAN interface, een statistiek in pfSense, dan zie ik dat die omhoog gaat van 8ms naar ~400ms zodra torrent verkeer aan staat.

Dat zou kunnen komen door de manier waarop pfSense die statistiek meet. Dat durf ik niet te zeggen.

[laurens0619]

hmm heb je misschien een vorm van IPS/IDS/Packet inspection aanstaan op de pfsense?
Ik weet niet of je bridge makkelijk kunt aanzetten maar je zou het eens kunnen proberen zonder de pfsense en direct op de ziggo

[DR!5EQ]

tMb schreef op zaterdag 13 februari 2021 @ 07:58:
Dank allemaal voor het meedenken.

Het is inderdaad niet het aantal connecties. Dat gaat via de VPN tunnel en op de router staan er voor de client maar twee connecties (UDP) open. Ook heb ik het aantal connecties gelimiteerd in de bittorrent client tot 5. En inderdaad ik draai pfSense op een i5, wat overkill zou moeten zijn.

M’n internetlijn (Ziggo) is 250mbps. Dus die is niet vol met 1 mbps torrentverkeer.

Een aantal gedachtes:
- De VPN via TCP ipv UDP lopen en dan kijken of het zelfde optreed.
- DNS resolving checken. Gaat dat mogelijk langs de VPN tunnel?
- Wireshark om verkeer van client te capturen. Wordt er naast VPN misschien veel lokaal verkeer gegenereerd dat mijn router niet ziet?

Client die bittorrent draait is wireless verbonden (5ghz). Clients die problemen ervaren zijn deels wireless, deels wired verbonden.

Ik hoop dat ik vanavond tijd heb om verder te troubleshooten. Ik post dan een update

Ik zou zelf eerst gaan checken of een kabel helpt ipv wireless. Hoeveel torrents heb je momenteel actief?

[tMb]

@laurens0619 IPS/IDS staat uit. pfSense is alleen router en firewall.

@DR!5EQ Oprechte vraag: hoe zou een kabel naar de client met torrent het verschil kunnen maken in het wel/niet langzamer maken van de rest van mijn netwerk? Aantal torrents is 5 tegelijk.

Vanavond gecontroleerd dat DNS resolving netjes via de VPN tunnel loopt. Geen overbelasting dus van m'n DNS forwarder (voor zover torrents überhaupt DNS resolven??).

Net het probleem gereproduceerd toen de VPN tunnel via UDP liep. Daarna de VPN tunnel omgezet naar TCP poort 443 en torrents weer opgestart. Resultaat: probleem treedt niet meer op + snellere downloadsnelheid.

Alleen waarom zou dat kunnen?! UDP is toch een efficiënter protocol dan TCP?

[Sniffert]

Toevallig, ik heb exact hetzelfde probleem! Ook ik draai pfsense als gateway. Ik heb het probleem zelfs met al mijn devices op het netwerk. Zodra ik een torrent start klapt de WAN interface helemaal dicht en gaat de packet loss naar 100%. Heb ook nog met de MSS/MTU settings in de ovpn file gespeeld, maar dit levert ook geen verandering op. Voor mij was ook de enige workaround het omzetten van UDP naar TCP maar ben zelf ook nog opzoek naar de oplossing van dit probleem...

[Voor 11% gewijzigd door Sniffert op 13-02-2021 22:34]

[laurens0619]

Dit klinkt idd als een pfsense issue. Pfsense is gaaf en erg tweakbaar maar soms ook gekke dingen

Ik zou het daarom eerst eens testen met de ziggo router of je het probleem dan nog steeds hebt

Daarna is het zoeken, firewall uit, hardware offloading, netwerk chipset drivers etc...

[DR!5EQ]

tMb schreef op zaterdag 13 februari 2021 @ 21:33:
[..]

@DR!5EQ Oprechte vraag: hoe zou een kabel naar de client met torrent het verschil kunnen maken in het wel/niet langzamer maken van de rest van mijn netwerk? Aantal torrents is 5 tegelijk.

[..]

Hoewel het wifi-verkeer met moderne routers over meerdere kanalen gaat ipv 1 met oudere routers, worden pakketten verwerkt middels de fifo methode. Dat kan er dus voor zorgen dat er vertraging optreed in de verwerking van de pakketten. Al je wifi apparaten delen die beperkt aantal kanalen. Dat plus dat wifi ook nog door deuren muren en ramen heen moet kan voor vertraging zorgen. Je deelt het wifi spectrum daarnaast met de hele wereld. Als je buren op hetzelfde wifi kanaal aan het zenden zijn, wordt jouw pakketje in de wacht geplaatst. Er zijn een hoop factoren waardoor wifi niet altijd even lekker werkt. Daarmee is wifi het beste bruikbaar voor apparaten als smartphones en tablets. Alle overige apparaten hebben meestal een netwerkaansluiting, waarbij je geen last hebt van al die factoren.

Maar ik lees dat je probleem is opgelost. Het enige verschil tussen TCP en UDP dat ik ken, is dat TCP ook checkt of het pakketje is aangekomen en UDP verstuurt het alleen. Bij VPN's merk je bij het aanpassen van het protocol wel dat je capaciteit van je snelheid inlevert en niet zo'n beetje ook. Maar met 1MB/s zou dat geen bottleneck moeten zijn.

[Vorkie]

UDP en waarschijnlijk een Connectbox?

Puma6 ellende misschien? Weet ook dat sommige tunnels, zoals GRE ontzettend langzaam zijn op die Ziggo modems....

[tMb]

@Vorkie Connectbox staat in bridge mode. Zou dat nog steeds een bottleneck kunnen zijn?

@laurens0619 Het is wat werk om pfSense er tussen uit te halen en de Connectbox uit bridge mode te halen. Ik zal vanavond eens kijken of me dat lukt.

Ik vind op het Netgate forum trouwens twee interessante vergelijkbare problemen:

Actually what happens is that I have packed drops/high latency when transfers over VPN are getting very slow, not fast. Then VPN server can easily reach half of the speed of my download DSL link (i.e 300Mbit/2=150Mbit) and then everything is OK. There are no issues when VPN is not used at all either. Problem is when the remote end behind VPN (=torrent sources) isn't that fast and download speed drops to say 10Mbit. Then torrent transfers are causing high latency/high packet drop on my link.

https://forum.netgate.com...-with-codel-and-openvpn/4

I'm connecting to privateinternetaccess VPN from my pfSense router, and behind that is a torrenting box. Only the torrenting box is being routed through the VPN, the rest of my network isn't. I have a 250/40 connection with a average ping of 10ms (To my ISP's gateway), but when the torrent box starts downloading something, my average ping shoots up to 80ms, and i get 40% packet loss, even though the torrent is only downloading with 1 megabyte a second.

https://forum.netgate.com...orrenting-through-pia-vpn

Wordt vervolgd.

[Thralas]

Vorkie schreef op zondag 14 februari 2021 @ 09:00:
UDP en waarschijnlijk een Connectbox?

Puma6 ellende misschien? Weet ook dat sommige tunnels, zoals GRE ontzettend langzaam zijn op die Ziggo modems....

Om nog even een kruisverband te leggen, hier heeft TS óók een Connectbox en werkt udp ook voor geen meter. Maar: met een router ertussen werkt het probleemloos.

Linux router met twee OpenVPN connectie's traagheid

Zou inderdaad niet de eerste keer zijn. Het issue leek destijds iets van een hardware connection tracking overflow (door udp met wisselende src/dst). Zou niet aan de orde moeten zijn bij één enkele VPN-verbinding, maar het doet je wel een beetje afvragen hoe ze dat uiteindelijk opgelost (of 'opgelost') hebben en of er nog niet meer schort aan udp handling.

Tegelijkertijd gaat er tegenwoordig nog veel meer over udp (WebRTC, QUIC) wat doet vermoeden dat er ergens nog een randvoorwaarde is om dit te triggeren.

@tMb Zelfde geldt hier als in dat andere topic: als je het weet te reproduceren met iperf3 heb je een veel simpelere test case dan BitTorrent + OpenVPN.

[Sniffert]

@tMb ik heb zelf ook de ConnectBox van Ziggo en mijne staat niet meer in bridge modus. Dus ik zou zeggen, bespaar je de moeite, bij mij heeft het in ieder geval geen effect. Het zou kunnen dat wellicht Ziggo throttling toepast maar die kans acht ik ook klein.

Overigens speelt dit probleem voor mij pas sinds 2 maanden. Daarvoor heb ik middels dezelfde setup nooit problemen gehad met bittorrent verkeer getunneld door UDP VPN.

[Voor 25% gewijzigd door Sniffert op 14-02-2021 12:58]

[tMb]

@Thralas Inderdaad zou het mooi zijn als ik het weet te reproduceren met iperf3 of een andere testtool (ik las over Flent). Nog geen tijd voor gehad om dat te proberen.

Puma zegt me niks, daar moet ik induiken.

@Sniffert Fijn om te horen, dan laat ik de connectbox in bridge modus staan. Als je zegt dat het probleem pas sinds 2 maanden speelt dan ga je toch throttling verwachten van Ziggo maar kan me dat niet voorstellen.

Ik heb vanavond gekeken naar het concept bufferbloat. Dat geeft vergelijkbare symptomen. Meer informatie in deze uitstekende Youtube video's:

• Comprehensive Guide to pfSense 2.3 Part 9: Traffic Shaper
• How To Solve pfsense Bufferbloat With A CodelQ / FQ_Codel Limiter in 2.4.4

Alleen helaas lost dit het probleem niet op. Sowieso wel goed om in te stellen denk ik, al haalt het iets van m'n maximum downloadsnelheid af.

[dennisdennis12]

Ik gok toch op een probleem met de connect box. Helaas kun je dit natuurlijk niet echt eenvoudig testen, maar ik weet dat er in het verleden problemen waren op de connectbox i.c.m. bepaalde traffic types.

Dit is ook niet echt bufferbloat, dat zou je namelijk alleen moeten hebben op het moment dat een device overbelast is, of op het moment dat je de volledige throughput gebruikt. Dit verkeer zou echter niet de buffers zodanig moeten vullen.

[tMb]

Ik heb het een tijd laten liggen omdat ik niet verder kwam (workaround was om via de VPN tunnel via TCP te laten lopen).

Vanavond weer troubleshooten en daarbij kwam ik deze post tegen op het Ziggo forum: p2p over VPN vertraagd alles.

En inderdaad, als ik het µTP protocol uitschakel op m'n torrent client (Transmission) dan treed het probleem voor zover ik heb kunnen testen niet meer op.