De invloed van pfsense op mijn internetsnelheid?

Het stond al heel lang op de planning, maar de afgelopen week eens lopen stoeien met pfsense; ik had immers vakantie :slight_smile:

Als hardware heb ik een Intel NUC 11 Pro Kit NUC11TNHi30L gekocht met 2x 2.5GB poort, 16GB geheugen en 250GB nvme ssd.
(Véél te ruim allemaal, maar als ik pfsense niet aan het werk krijg, kan ik het gelijk inzetten als VM-server. Bovendien hoop/denk ik met deze NUC de vpn-snelheden op te krikken vanwege de i3-processor met AES-NI CPU support)

Laatste versie van pfsense er op en verder vrij standaard gelaten, op een handvol VLANs na. Volgens mij werkt het allemaal redelijk goed en de firewall kan ik pas afregelen als alles aangesloten is. Dat doe ik stapsgewijs, omdat ook alles gelijk alles omnummer (IP-nummers van 192.168.x.x naar 10.x.x.x).

Vandaag ben ik dus aan het over te stappen en heb wat testjes gedaan. Uploaden en Downloaden lijken sneller te gaan dan met de Draytek, maar de speedtest van Ookla kom met pfsense tot 50-60% van wat ik normaal achter de Draytek haal (heb 500 mb abonnement en zit daar normaliter ietsjes onder met download en ruim er boven met upload).
Uiteraard het halve internet afgezocht en een paar dingen geprobeerd, maar die hielpen niet of waren niet van toepassing.

Nu zag ik bij de reacties van het installeren van pfsense voor Freedom, dat er ook wat MTU-instellingen te doen zijn, maar hier heb ik totaal geen verstand van en heb dus geen idee of dit zinnig is.

Heeft iemand een verklaring voor de -bijna- halvering van mijn internetsnelheid via Ookla? en is de oorzaak daarvan ook van invloed op de werkelijke snelheid van de verbinding in de dagelijkse praktijk?

Probeer met een 2e (fysieke) netwerkkaart/poort 's een backdoortest te doen om daarmee te achterhalven wat de software doet.
Snelheden extern worden imo vooral bepaald door slidingwindows en ja, de specificatie van de aansluiting zegt niet veel over het kunnen gebruiken daarvan.

Er zitten 2 poorten in de NUC, maar heb geen idee hoe iets dergelijks te doen.

Ik weet dat als ik 500mb koop, dat ik niet per se dat ook tot mijn beschikking heb; echter als tot gisteren bij Ookla de Draytek constant rondom de 500 zit, is het gek als de pfsense consequent ineens een stuk later uitvalt. Wellicht dat ik zo nog een testje doe met de Draytek om te zien of het niet aan mijn verbinding ligt, maar dat zou mij verbazen.

Ja, die MTU instellingen zijn heel belangrijk. Hoe staan ze nu?

Ik heb ze als volgt.

WAN-interface: 1508

LAN-interface: Leeg

PPPoE: 1500

1 like

Er staat nu niks, maar ik heb het met jouw waarden geprobeerd en dat maakt al een flink verschil!
het resultaat is nu:

Download: 407 (was: 287)
Upload:   580 (was: 356)

Dat is aardig in de buurt van wat het was.
DANK @Eirikr !

Mooi! Heb je IPv6 ook op orde?

euh… nee nog niet :grimacing:

Ik heb wel gekeken of ik direct de overstap naar IPv6 kon maken, maar het duizelde mij na 2 dagen inlezen. Ik heb totaal null verstand van IPv6 en ben blij dat ik het met die vlans en zooi aan de praat heb.

Ik ga er zeker naar kijken, want ik zie de voordelen er van zeker wel van in.

Heel eenvoudig.

WAN:

LAN:

Zodra alles operationeel is op IPv4 ga ik dit een slinger geven, want als het zó eenvoudig is… :wink:

Wat is er nog niet operationeel?

Ben de hele dag aan het rotzooien geweest omdat ik de VLANs niet aan de praat kreeg in 1 segment van het netwerk. Dacht aan een verkeerde configuratie, maar het blijkt dat mijn TP-Link POE switch geen VLANs accepteert die niet op de switch zelf in gebruik zijn :thinking:

Dus nieuw kabeltje naar een andere router en toen werkte het in 1x

Ik moet alleen nog wat firewall rules uitzoeken en OpenVPN te activeren… Want daar was ik deze hele exercitie voor begonnen! Met een i3 met AES-NI en 16GB geheugen, zou dat toch als een raket moeten gaan.

OpenVPN werkt een soort van…
De instellingen:

OpenVPN Server:

.ovpn-file:

   persist-tun
   persist-key
   data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
   data-ciphers-fallback AES-256-CBC
   auth SHA256
   tls-client
   client
   remote <publiek ip nummer> 443 udp4
   nobind
   verify-x509-name "abcdef_cert" name
   auth-user-pass
   remote-cert-tls server
   explicit-exit-notify

Met deze instellingen, heb ik een split tunnel; de 2 lokale netwerken zijn bereikbaar en internet ook, alleen het internet gaat niet via OpenVPN.
Dit is tijdelijk wel werkbaar, maar

Wanneer ik in de .ovpn-file de regel redirect-gateway def1 toevoeg, heb ik geen internet meer.

Het liefst zou ik willen dat al het verkeer via de tunnel gaat en dat dit verkeer onderhavig is aan de firewall. Zo kan ik in de firewal rules van OpenVPN niet kiezen voor “OpenVPN net” of “OpenVPN address”. Ik zou graag met vaste IP’s werken zodat ik die toegang kan geven aan de juiste server en de rest onzichtbaar maken.
Ik heb het geprobeerd door een interface aan te maken met ovpns1. Ondanks dat ik er een tabje bij krijg in de firewall rules, doet het niks met de regels die ik instel.

Zul je altijd zien… Vast IP toewijzen en Firewall settings op deze Italiaanse site. Video is niet handig, tenzij je Italiaans verstaat.

Je moet wel de subnetten waar je toegang toe wil in de "IPv4 local network(s) zetten; gescheiden door een komma! en geen puntkomma :wink:

Op zich logisch dat een switch die is ingesteld voor vlan’s, alleen de packets van vlans afhandelt die het moet switchen. De rest wordt dan per definitie genegeerd omdat de switch geen andere vlan packets zal bridgen (laat staan routeren).

Daar zijn trunk-poorten voor toch? Die zetten het door naar de volgende switch.
Bovendien als het waar is wat jij zegt, is het gek dat de TL-SG105PE het niet doet, maar mijn TL-SG1016D het wél doet.

Op een trunkpoort moet ook worden ingesteld welke vlan’s daarin pariciperen doorgaans dan weer geregeld - mits aanwezig - door bv het MVRP / GVRP /VTP©cisco) (zeg maar multi vlan registratie) protocol.
Het hebben van een trunk zegt dus niet dat daarmee of -en welke vlan’s daarop gaan en kunnen deelnemen.

Voorbeeld, bij Cisco is er VTP (vlan trunking) dat lijkt op MVRP, hetzelfde doel dient maar maar totaal anders is ingeregeld. Dan onbedacht ‘zomaar’ een trunk inprikken, kan dan een (her)ontdekking zijn dat iets niet zomaar vanzelfsprekend is om te werken.

Dat iets dan niet werkt, laat staan binnen één fabrikant - die er vaak een eigen uitleg aangeeft - is dan de klacht daar op /dev/null deponeren. Been there2 en heb een kasT vol hangen.

Dit topic is 24 uur na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.