Verkeer via VPN: sommige websites laden niet.

[Intru]

Mijn Ubuntu bak heb ik geconfigureerd als VPN server (pptpd). Ik laat mijn verkeer via deze VPN lopen, en dat werkt bijna prima. Bijna prima, want sommige websites weigeren te laden. Het meeste verkeer loopt normaal en snel. Ik kan geen patroon vinden in de websites die het niet doen, een kleine selectie:

• rtl.nl
• volkskrant.nl
• meteofrance.com
• ratp.fr

Een aantal hiervan blokkeren ICMP, maar bij degenen die dat niet doen werkt pingen nog WEL gewoon.

Zonder VPN:

ping meteofrance.com

Pinging meteofrance.com [160.92.161.169] with 32 bytes of data:
Reply from 160.92.161.169: bytes=32 time=12ms TTL=234
Reply from 160.92.161.169: bytes=32 time=12ms TTL=234
Reply from 160.92.161.169: bytes=32 time=12ms TTL=234
Reply from 160.92.161.169: bytes=32 time=12ms TTL=234

Ping statistics for 160.92.161.169:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 12ms, Average = 12ms

Met VPN:

ping meteofrance.com

Pinging meteofrance.com [160.92.161.169] with 32 bytes of data:
Reply from 160.92.161.169: bytes=32 time=33ms TTL=244
Reply from 160.92.161.169: bytes=32 time=34ms TTL=244
Reply from 160.92.161.169: bytes=32 time=34ms TTL=244
Reply from 160.92.161.169: bytes=32 time=33ms TTL=244

Ping statistics for 160.92.161.169:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 33ms, Maximum = 34ms, Average = 33ms

Niet echt een verschil om over naar huis te schrijven. Wanneer ik de website open in m'n browser blijft hij heel erg lang laden (er verschijnt 0,0), tot de verbinding gereset wordt. Pure snelheid is het probleem ook niet, grote bestanden komen met ongeveer 30Mbit binnen. Iemand enige idee wat dit zou kunnen veroorzaken, of wat ik verder kan testen om de oorzaak te vinden?

[gertvdijk]

Wat zijn je MTU instellingen? 95% kans dat dat het is. In IPv4 is de router verantwoordelijk voor reassemblen van packets tussen interfaces van verschillende MTU sizes.

En test eens met welke waarde de ping nog wel doorkomt en welke niet meer?

ping -s 1440 mijnserver.nl

met -s <size in bytes>

[ Voor 29% gewijzigd door gertvdijk op 10-10-2011 16:39 ]

[Intru]

gertvdijk schreef op maandag 10 oktober 2011 @ 16:38:
Wat zijn je MTU instellingen? 95% kans dat dat het is. In IPv4 is de router verantwoordelijk voor reassemblen van packets tussen interfaces van verschillende MTU sizes.

Spot on, MTU stond te hoog! Aangepast, en alles loopt weer als een trein. Dank!

Een leuk bijkomend effect is dat de echte downloadsnelheid ook een stuk omhoog is gegaan.

[ Voor 11% gewijzigd door Intru op 10-10-2011 17:09 ]

[gertvdijk]

Intru schreef op maandag 10 oktober 2011 @ 17:08:
Een leuk bijkomend effect is dat de echte downloadsnelheid ook een stuk omhoog is gegaan.

Dat is een logisch gevolg van de packet loss i.c.m. TCP. Niet zomaar een bijkomend effect, hoor.
Heb laatst een probleem gehad met MTU/MRU/MRRU e.d. en dat bleek na een uurtje of 16 (van twee mensen) toch nog een stomme instelling ergens in een L2TP tunnel waar de MRRU te klein van stond.

[Intru]

Toch een beetje te vroeg gefeest denk ik. Met wat uitgebreider testen komen er toch weer behoorlijk wat problemen. Dus bij deze even de MTU instellingen.

Op de server staan de MTU en MRU op 1500. MTU op client:

netsh interface ipv4 show subinterfaces

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  1400                1    1106787     393862  VPN Connection

Ik heb gekeken met welke waarde de ping er wel/niet meer doorkomt. 1472 komt er nog door, 1473 niet.

[gertvdijk]

Intru schreef op maandag 10 oktober 2011 @ 20:12:
Ik heb gekeken met welke waarde de ping er wel/niet meer doorkomt. 1472 komt er nog door, 1473 niet.

Klopt precies. 8 bytes ICMP header + 20 bytes IPv4 header + 1472 bytes data = 1500 bytes.
En dat geldt voor beide richtingen? De echo-reply heeft niet dezelfde grootte als je echo-request die je opgeeft namelijk.

If so, dan zou ik dus nu even naar andere oorzaken voor problemen zoeken.

[ Voor 17% gewijzigd door gertvdijk op 11-10-2011 10:06 ]

[Intru]

gertvdijk schreef op dinsdag 11 oktober 2011 @ 10:04:
[...]

Klopt precies. 8 bytes ICMP header + 20 bytes IPv4 header + 1472 bytes data = 1500 bytes.
En dat geldt voor beide richtingen? De echo-reply heeft niet dezelfde grootte als je echo-request die je opgeeft namelijk.

If so, dan zou ik dus nu even naar andere oorzaken voor problemen zoeken.

Die 1472 klinkt inderdaad logisch. Beide richtingen bedoel je van VPN server naar client?

Als ik ping (van de client) naar een server die ik niet kan bereiken (bv meteofrance.com), dan gaat dit goed tot 1472 bytes. Als ik ping met -f (niet fragmenteren) dan gaat het goed tot 1368 bytes. Op 1369 bytes krijg ik een timeout, geen "Packet needs to be fragmented but DF set."

Pingen van de client naar VPN server gaat door tot boven de 1500 bytes, met -f gaat goed tot 1372 bytes, daarboven een "Packet needs to be fragmented but DF set."

Pingen van VPN server naar client gaat ook tot boven de 1500 bytes door (tijden lopen wel op). Als ik hem niet laat fragmeteren, gaat het weer goed tot 1368.

ping 192.168.111.234 -s 1369 -c 1 -M do
PING 192.168.111.234 (192.168.111.234) 1369(1397) bytes of data.
From 192.168.111.1 icmp_seq=1 Frag needed and DF set (mtu = 1396)

Uit een ifconfig op de VPN server lijkt de mtu voor ppp0 inderdaad op 1396 te staan. In de config file staat hij op 1500.

[Intru]

Ik heb nu de MTU van de client handmatig op 1396 gezet, en dit lijkt de problemen weg te halen. In dit geval is het een prima oplossing, aangezien ik toch zelf de enige client ben. Maar hoe zou ik dit serverside kunnen afdwingen? Als echte Tweaker wil ik het nu ook eigenlijk goed doorhebben.