Heeft iemand eens vergelijkbare problemen gezien?
Vaker dan me lief is..
ping eens door de tunnel met:
ping <destination> -f -l 1472
Normaliter zou je een reply verwachten omdat IP+ICMP = 28bytes overhead. Totaal = 1500bytes en past net bij een normale verbinding. Echter, door de tunnel overhead kan dit dus nooit passen. De vraag is echter of je een timeout krijgt of een fragmentation required response.
Dit zou je moeten zien:
Packet needs to be fragmented but DF set.
Indien je ziet:
Request timed out.
Dan heb je een Path MTU discovery probleempje, de aanwezigheid van een VPN voegt wat complexiteit toe. Een router in je pad stuurt geen ICMP Fragmentation Required pakket terug naar de bron of het gaat verloren. Dit ICMP pakket was nodig om te laten weten dat het eerdere pakket niet gerouteerd kan worden.
Maak nu steeds de waarde 1472 lager totdat je een reply krijgt. Dan zit je op de daadwerkelijke MTU van de binnenkant tunnel. Je kunt dan:
- De schuldige router vinden en aanpassen;
- MTU van de server of client instellen op binnenkant tunnel MTU zodat het altijd past; (workaround);
- Een MSS clamping rule aanmaken die al het TCP verkeer aanpast naar een lagere MSS waarde. (workaround).
Wellicht even kijken naar DF-Bit propagatie op de tunnel en ICMP firewall rules. ICMP echo-request, echo-reply en fragmentation-required moeten op alle lagen worden doorgelaten, binnenkant en buitenkant tunnel. Daarnaast moet er als er op het WAN een fragmentation-required wordt ontvangen, aan de binnenkant van de tunnel gepropageerd worden. Dat wil zeggen dat de reactie op het buitenste WAN packet wordt geforward naar de host op het interne LAN die het buitenste packet veroorzaakte. Deze kan zijn MSS dan naar beneden aanpassen. Dit is op junipers vaak een los vinkje op de tunnel interface bijvoorbeeld. Path MTU werkt dus tussen twee hosts aan 2 tunnel endpoints met in achthouding van de WAN MTU + Tunnel overhead. Zolang het ICMP packet maar naar beneden propageert kun je theoretisch tunnels tunnelen over tunnels met behoudt van PMTU Discovery
Daarnaast is een zelfde ping test buiten de tunnel om (tussen de WAN IP's) ook interessant om te zien of Path MTU Discovery op die laag ook wel functioneert. Daar zou een payload van 1464 moeten passen, 1465 zou niet meer mogen passen (IP+ICMP+PPP = 36). Ervanuitgaande dat je een PPP sessie gaande hebt. Hoe dan ook moet je altijd een reply of een frag-required krijgen. Nooit een timeout bij het vergroten of verkleinen van de payload..
Path MTU discovery valt overigens niet te forceren. Het is een continue proces. Zelfs als de verbinding al tot stand is gekomen (wat vaak het geval is voordat er een groter packet wordt gestuurt zoals je zelf hebt ondervonden). Zolang de packets stromen gebeurt er niets, pas bij het eerste packet wat niet kan worden gerouteerd ontvang je een fragmentation-required ICMP packet en direct zal de host MSS bijstellen naar beneden. Windows onthoudt maximale MTU per destination adres voor een bepaalde tijd geloof ik. Soort van cache mechanisme. Pas dus op met testen en reboot tussendoor just to be sure.
Dat van die >1500 werkt wel zal wel een raar bijverschijnsel zijn. Kan veel oorzaken hebben, ik zou er niet op letten want dat is sowieso niet de bedoeling.
Voor de duidelijkheid, we hebben het over
rfc1191 en niet over
rfc4821.
In this memo, we describe a technique for using the Don't Fragment
(DF) bit in the IP header to dynamically discover the PMTU of a path.
The basic idea is that a source host initially assumes that the PMTU
of a path is the (known) MTU of its first hop, and sends all
datagrams on that path with the DF bit set. If any of the datagrams
are too large to be forwarded without fragmentation by some router
along the path, that router will discard them and return ICMP
Destination Unreachable messages with a code meaning "fragmentation
needed and DF set" [7]. Upon receipt of such a message (henceforth
called a "Datagram Too Big" message), the source host reduces its
assumed PMTU for the path.
Bron: https://tools.ietf.org/html/rfc1191
Zodra je de MTU van een van de 2 peers lokaal instelt op bijvoorbeeld 1400 dan zal bij de 3-way TCP handshake de initierende partij per direct al aangeven een MSS te willen van 1360 (limitatie eerste hop, zijn eigen NIC) waar de ontvangende kant aan moet voldoen waardoor er geen problemen op kunnen treden. De MTU op de NIC moet kleiner zijn of gelijk aan de MTU binnenkant tunnel. Dan gaat het (als workaround) goed.
Als het een Linux bak is kun je rfc4821 proberen in te schakelen:
net.ipv4.tcp_mtu_probing=1 naar /etc/sysctl.conf en reload.
'man tcp' on these two values:
------------------------------
tcp_mtu_probing (integer; default: 0; since Linux 2.6.17)
---
This parameter controls TCP Packetization-Layer Path MTU Discovery. The
following values may be assigned to the file:
0 Disabled
1 Disabled by default, enabled when an ICMP black hole detected
2 Always enabled, use initial MSS of tcp_base_mss.
Bron: https://lists.opensuse.or...ugs/2016-03/msg02376.html
Good luck. Kunnen soms vervelende probleempjes zijn maar dit is ongeveer hoe het zou moeten werken.
Zo nu staat er weer wat meer informatie online
Interesting read: https://blog.cloudflare.com/path-mtu-discovery-in-practice/
Stukje oudzeer: https://forum.netgate.com/topic/89558/ipsec-pmtu (2015)
[
Voor 74% gewijzigd door
Pakjebakmeel op 09-03-2019 16:57
. Reden: post while you type ]
:strip_icc():strip_exif()/u/61340/125281113_256.jpg?f=community)
/u/38159/DirkJan.png?f=community)
:strip_icc():strip_exif()/u/92426/garfield_avatar.jpg?f=community){kind=avatar}