Wat zijn de juiste settings voor de Tweak verbinding? Ik zoek naar de juiste MTU en MSS settings. MTU is standaard 1500, maar dat is niet altijd de meest geschikte waarde. En “Disable hardware checksum offload”, Disable hardware TCP segmentation offload" en Disable hardware large receive offload" ? Die horen alle drie aan te staan?
Mijn verbinding lijkt af en toe niet te werken, ik moet dan PFSense opnieuw opstarten en dan is het probleem weer verholpen. Ik weet nog niet zeker waar het probleem zit, dus ik ben even wat dingen aan het uitsluiten (waaronder dus de juiste MTU/MSS waardes).
Ik heb bij alle drie géén vinkje staan.
Ook heb MTU en MSS standaard. Echter , als ik bij diagnostics/ Routes kijk zie ik de MTU op de igb interfaces 1500 maar op de lo0 16384. Ik heb geen idee wat dat betekent?
In principe is de MTU niet van invloed op de stabiliteit van je verbinding. De vraag is dan ook hoe zich dat uit
MTU 1500 is goed in ieder geval.
Voor wat betreft die hardware offloading, ook dat heeft (in principe) geen invloed op de verbinding. Als je hardware offloading kunt doen, zou ik het gewoon aanzetten. Hoe minder in CPU hoe beter.
@johan, mijn probleem is dat ik wanneer ik Open VM-Tools installeer ik ongeveer na een uur geen verbinding meer hebt met deze error:
Arpresolve: can’t allocate lllinfo for 185.227.72.1 on vmx0 ( dat is mijn WAN interface).
Nu kan je simpelweg zeggen dan deinstalleer je die VM tools package toch? Ja dat kan… maar ik wil toch graag altijd weten waarom iets niet/wel werkt
Heb jij enig idee?
Als het bij benadering een uur is (ik gok dat het precies een uur is), is de kans groot dat er iets fout gaat bij DHCP. Ik verwacht dat er 1x een DHCP request wordt gedaan waarna het IP-adres verkregen is en je daadwerkelijk connectiviteit hebt, en daarna niet meer. Als er niet binnen een uur een DHCP request vanuit jouw pfsense komt, is de sessie in de router weg en heb je geen connectiviteit meer. Toevallig heb ik daar vandaag nog iets over uitgelegd in dit topic.
Ik snap wat je zegt, maar weet je toevallig ook hoe dat op te lossen? Want zoals ik zei zonder de VM tools package gaat het wel goed en die package heeft toch niks met de DHCP (lease) van Tweak te maken?
Je zou zeggen van niet, maar het is wel heel toevallig (of verdacht) dat het na een uur stuk gaat. Ik heb verder geen ervaring met pfsense of VM-tools dus ik kan er verder ook niks zinnigs over roepen helaas.
MTU en MSS moet je niet aanzitten als je niet weet wat je doet. Alleen als je een VPN gebruikt om traffic te tunnelen moet je in specifieke gevallen de MTU van de interne interface van je firewall verlagen om freezes van de TCP sessie te voorkomen. In alle andere gevallen moet de MTU gewoon de Max. Transfer Unit van de interface zijn. Met Path MTU discovery zoekt je host zelf uit wat de MTU end-to-end moet zijn.
Als je denkt dat je MTU een probleem is moet je pingen met steeds grotere pakketten:
ping -s 64 8.8.8.8
ping -s 640 8.8.8.8 (krijgt response van maar 76bytes, maar het werkt dus).
ping -s 1472 8.8.8.8 (1472 -> MTU - 28b header? je krijgt geen response als het niet goed is).
Hardware problemen moet je terug kunnen vinden in de Release notes van de FreeBSD versie die jou pfSense gebruikt. Zie www.freebsd.org. Als je me de pfSense versie en de specifieke adapter mailt kan ik hierbij helpen. Je kunt ook op de pfSense inloggen en vanaf die machine beide kanten op pingen om te kijken of je kunt achterhalen wat er aan de hand is.
Ik heb PFSense opnieuw opgebouwd, het probleem lijkt hem te zitten in mijn ExtraIP GRE Tunnel. Hierbij geeft een andere MTU/MSS waarde een verschil in up/down snelheid, maar wellicht dus ook dus ook de oorzaak van dit probleem.
Het probleem is dan als volgt: Je tunnel zit achter de firewall. Tegen de tijd dat je pakketjes daar aankomen zijn ze genat. Als ze te groot zijn, krijg je van de GRE tunnel een ICMP “Destination Unreachable-Fragmentation Needed and DF Set”. Maar omdat het pakket genat is gaat dat naar het firewall IP adres en die doet er niets mee. Dus je outgoing PMTU discovery werk niet goed.
Daar heb je normaalgesproken minder last van, omdat het om upload gaat.
GRE overhead is 24 bytes, dus zet de -interne- interface van je firewall op MTU-24 bytes (dus bijvoorbeeld 1476) en kijk of je verbinding dan nog steeds vastloopt als je een grote file -upload- via de GRE tunnel.
Als je de MTU van de interne interface verlaagt, detecteert je laptop, IoT device, internet enabled broodrooster, WiFi camera , etc. automatisch een lagere MTU middels Path MTU discovery.
Ik draaide al een tijdje met MSS op 1472, en sindsdien is het probleem niet meer voorbij gekomen. Is uiteraard nog niet zo heel lang, zeg je van MTU op 1476 is echt the way to go?
EDIT: dit is niet helemaal correct. Ik gebruik nu 1472 MSS op de GRE interface. Jij spreekt (vrij duidelijk ) over de interne interface. Neemt niet weg dat dit wel mijn probleem lijkt te hebben opgelost.
Nee. MTU is de Max Transmission Unit van het onderliggende medium, en bedoeld om 1 pakket efficient te versturen.
Op ethernet komt dat zo uit ivm de grootte van een ethernet frame, maar als je in bijvoorbeeld een WiFi omgeving zit met veel ruis, dan kan je proberen je MTU omlaag te gooien. Ik heb wel eens een MTU van 256 gebruikt op een 2G verbinding, omdat er zoveel packet drop op 2G niveau was (64 bytes per frame?) dat met een MTU van >1000 dat kans bijna 100% was dat er 1 frame de mist in ging, en dus het hele IP pakket. Dus daar was de ‘standaard MTU’ van de PPP interface onjuist gekozen door de 2G operators. Maar ja, iedereen verwacht 1500 en dus moest het dat zijn…
Je hebt ook jumbo frames van ~9000 bytes op LANs om de overhead te verlagen, maar dat moet je aanzetten.
In GRE tunnels is het weer anders. IPSec ook, want dan gaat de AH header er weer vanaf. IP-in-IP tunnelling heeft ook een kleinere MTU.
Good old SLIP (Serial Line Internet Protocol) had een MTU van 256. Als dat ergens in je pad zat dan was je MTU voor dat pad dus 256 of lager.
Path MTU discovery probeert middels probe pakketten uit te zoeken wat de maximale transmissie eenheid is die verstuurd kan worden. Wie dat doet en wanneer dat gebeurt weet ik gek genoeg dan weer niet .
Ik heb hier toevallig net een machine die gebruik maakt van vmx interface and daarop doet iperf3 niet meer dan 25kbit/s. Ja. Na TSO uitgezet te hebben middels sudo ifconfig vmx0 -tso doet ie opeens 430MBit/s. Probeer eens wat dingen uit de options=<…> van ifconfig uit te zetten. Misschien dat dat soelaas biedt.
