Skip to main content
Sticky

Gebruik een eigen router i.p.v. de Experia Box

  • September 8, 2018
  • 8969 reacties
  • 640969 keer bekeken
Gebruik een eigen router i.p.v. de Experia Box
Toon eerste bericht

8969 reacties

Forum|alt.badge.img
  • Slimmerik
  • January 9, 2026

Bedankt voor je reactie.

Als ik de WireGuard documentatie bekijk voor OpnSense spreken ze over 80 bytes minder dan de WAN MTU:
 


Daarnaast heb ik de MTU van mijn WAN interface op 1508 ingesteld wat er voor zorgt dat ik een MTU van 1500 heb:

 

Als ik naar https://www.speedguide.net/analyzer.php ga, zie ik dat ik ook netjes een MTU van 1500 heb, wat geloof ik gewenst is. In het verleden heb ik problemen gehad met een MTU van 1492 waarbij bepaalde pagina’s niet wilde laden.


TDN
Wijsgeer
Forum|alt.badge.img+13
  • Wijsgeer
  • January 9, 2026

Dus de maximaal veilige WireGuard-MTU op KPN is:
1492 − 60 = 1432

MTU wireguard server is standaard ingesteld op 1392, dus maximaal MTU is 1392

ping -f -l 1373 1.1.1.1
Pinging 1.1.1.1 with 1373 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 1.1.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

ping -f -l 1372 1.1.1.1
Pinging 1.1.1.1 with 1372 bytes of data:
Reply from 1.1.1.1: bytes=1372 time=22ms TTL=58
Reply from 1.1.1.1: bytes=1372 time=22ms TTL=58
Reply from 1.1.1.1: bytes=1372 time=22ms TTL=58
Reply from 1.1.1.1: bytes=1372 time=22ms TTL=58
Ping statistics for 1.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

 


Firewizz
Topper
Forum|alt.badge.img
  • Topper
  • January 9, 2026

Je hebt gelijk dat mijn eerdere uitspraak te kort door de bocht was, dus even rechtzetten.

Bij KPN geldt:

→ PPPoE zonder RFC4638 → IP-MTU = 1492
→ PPPoE met RFC4638 (“baby jumbo”, WAN 1508) → IP-MTU = 1500

KPN ondersteunt RFC4638, dus beide situaties bestaan. Dat was mijn fout: ik stelde het te absoluut.

 

Voor WireGuard:

Overhead is 60 bytes bij IPv4
80 bytes bij IPv6 (OPNsense rekent hier standaard mee)

Daarom hanteert OPNsense terecht:

WAN 1492 → WG MTU 1412
WAN 1500 → WG MTU 1420

Die waarden komen dus puur uit WireGuard-overhead, niet uit KPN.

De 1392 die jij stelt komt niet van KPN maar van de WireGuard-server zelf.
Die server heeft een lagere tunnel-MTU ingesteld en dat wordt dan de bottleneck, ongeacht je WAN-MTU.

Dat zie je ook met DF-ping:

 

ping -f -l 1373 1.1.1.1 → faalt

ping -f -l 1372 1.1.1.1 → werkt

1372 + 28 bytes IP/ICMP = 1400 IP-MTU
WireGuard-overhead erbij → past net binnen een 1392-tunnel

Dus:

  • KPN + RFC4638 bepaalt of je WAN 1492 of 1500 is

  • WireGuard-overhead bepaalt 1412 of 1420

  • Maar de laagste MTU in de tunnel (hier 1392 op de server) is uiteindelijk bepalend

  • Met ping is dit gemakkelijk te testen of je goed zit.
    je moet óf de WireGuard-serverconfig controleren óf met DF-ping vaststellen waar de echte bottleneck zit.

 


Forum|alt.badge.img
  • Slimmerik
  • January 9, 2026

Oke, dan denk ik dat mijn aanname prima is.

Mijn KPN is inderdaad ingesteld met baby jumbo frames dus kan ik op WireGuard een MTU van 1420 hanteren (ondanks dat ik geen gebruik maak van ipv6 en dit uitgeschakeld heb).

 

Bedankt voor de reacties!


Firewizz
Topper
Forum|alt.badge.img
  • Topper
  • January 9, 2026

@TDN 

Even één correctie op je berekening.

ping -f -l meet ICMP-payload, niet IP-MTU.

Dus jouw meting:

ping -f -l 1372 → werkt ping -f -l 1373 → faalt

betekent:

1372 + 28 bytes (IP + ICMP headers) = 1400 bytes path-MTU

Je hebt hiermee dus een bottleneck rond 1400 bytes aangetoond, niet 1392.

Waar die 1400 vandaan komt (WireGuard-MTU op server, client of een tussenliggende link) weet je met deze test nog niet — alleen dát dit de effectieve ceiling is.

Als je wilt weten of het echt de WireGuard-server is, moet je daar de WG interface MTU controleren.
De DF-ping laat alleen het eindresultaat van het hele pad zien.


Firewizz
Topper
Forum|alt.badge.img
  • Topper
  • January 9, 2026

@vicking 
Je aanname klopt alleen als er nergens in het WireGuard-pad een lagere MTU zit.

Dus ook met baby-jumbo op KPN blijft gelden: testen is beter dan aannemen.

Even checken via de tunnel:

ping -f -l 1392 1.1.1.1 ping -f -l 1393 1.1.1.1

Werkt 1392 maar faalt 1393, dan is 1420 te groot en zit er ergens (client/server/pad) een lagere MTU.

WAN 1500 maakt 1420 mogelijk, maar het complete pad beslist wat echt werkt.


Forum|alt.badge.img
  • Slimmerik
  • January 9, 2026

@vicking 
Je aanname klopt alleen als er nergens in het WireGuard-pad een lagere MTU zit.

Dus ook met baby-jumbo op KPN blijft gelden: testen is beter dan aannemen.

Even checken via de tunnel:

ping -f -l 1392 1.1.1.1 ping -f -l 1393 1.1.1.1

Werkt 1392 maar faalt 1393, dan is 1420 te groot en zit er ergens (client/server/pad) een lagere MTU.

WAN 1500 maakt 1420 mogelijk, maar het complete pad beslist wat echt werkt.

Ik ga het eens testen vanaf een cliënt!

Heb nu alleen m’n iPhone ingesteld maar helaas niet ontdekt of daar iets van een terminal voor beschikbaar is om een ping te kunnen doen 😅


Firewizz
Topper
Forum|alt.badge.img
  • Topper
  • January 9, 2026

Ik bebruik vaak de “shelly” app voor ssh naar mijn router en ping vanaf daar.


Forum|alt.badge.img
  • Slimmerik
  • January 9, 2026

Ik bebruik vaak de “shelly” app voor ssh naar mijn router en ping vanaf daar.

Maar voert de router de ping dan niet uit, en is dat dan niet juist een cliënt zonder VPN? Of omdat je als cliënt verbonden ben over een VPN naar de router wordt de VPN alsnog gebruikt?


TDN
Wijsgeer
Forum|alt.badge.img+13
  • Wijsgeer
  • January 9, 2026

Maar voert de router de ping dan niet uit, en is dat dan niet juist een cliënt zonder VPN? Of omdat je als cliënt verbonden ben over een VPN naar de router wordt de VPN alsnog gebruikt?

Voor router maakt niet uit, je stel MTU=1508 voor WAN en MTU=1500 voor PPPoE. Voor VPN past je de MTU op LAN op lagere waarde om fragmentatie te vermeiden, maar ook zonder aanpassing werkt jouw VPN, dan met beetje mindere prestatie.


Forum|alt.badge.img
  • Slimmerik
  • January 9, 2026

Oké ik ben dus via mijn VPN ingelogd in mijn router om vanaf daar in de shell een ping te doen.

Met 1392 is dit het resultaat:

229995 packets transmitted, 225707 packets received, +1277 duplicates, 1.9% packet loss
round-trip min/avg/max/stddev = 3.388/5.320/11.216/0.721 m
 

Oftewel packet loss van 1.9%
 

Met 1393 is dit het resultaat:

2346 packets transmitted, 53 packets received, 97.7% packet loss
round-trip min/avg/max/stddev = 3.452/4.559/14.765/3.280 ms

 

Een packet loss van 97.7%, lijkt me niet goed dus 😅


Firewizz
Topper
Forum|alt.badge.img
  • Topper
  • January 9, 2026

Dat is dan een geslaagde test. Je antwoord is 1392.

:)

je router handeld inderdaad dit af en werkt prima vanaf router, mits verkeer door de tunnel gaat.


Forum|alt.badge.img
  • Slimmerik
  • January 9, 2026

Dat is dan een geslaagde test. Je antwoord is 1392.

:)

je router handeld inderdaad dit af en werkt prima vanaf router, mits verkeer door de tunnel gaat.

Haha oké, alleen is me nu nog niet helemaal duidelijk wat ik succesvol getest heb? Dat ik een MTU van 1420 kan gebruiken voor m’n VPN verbinding of juist niet? 


Firewizz
Topper
Forum|alt.badge.img
  • Topper
  • January 9, 2026

Ja correct,

Je ping -s 1392 is ICMP-payload.

Daar komt 28 bytes IP+ICMP headers bij.

dus 1420 max mtu :)


Forum|alt.badge.img
  • Slimmerik
  • January 9, 2026

Ja correct,

Je ping -s 1392 is ICMP-payload.

Daar komt 28 bytes IP+ICMP headers bij.

dus 1420 max mtu :)

Thanks!

 

Ik was een beetje in de war door je volgende zin;

 

Werkt 1392 maar faalt 1393, dan is 1420 te groot en zit er ergens (client/server/pad) een lagere MTU.

 

En aangezien 1393 faalde dacht ik dat 1420 te groot zou zijn :)


  • Nieuwkomer
  • January 12, 2026

Ik heb een vraag omtrent firewalling en IPv6. Ik had tot voor kort een Box12 draaien met IPv6 enabled. Hier had ik een prefix delegation voor en een server van mij via de ingebouwde firewall in het Box12 modem bereikbaar via het internet. 

Nu ben ik overgestapt van de Box12 naar een Asus router, wat verder uitstekend werkt. Wederom de prefix delegation aangezet en een firewall rule ingesteld die poort 443 op het IPv6 addres van mijn server vrijgeeft. Dit krijg ik echter met geen mogelijkheid aan de praat. Het enige wat mij opvalt is dat de router op de WAN interface geen IPv6 adres uit mijn PD-reeks krijgt, maar een link-local address. Iemand een idee wat hier mis kan zijn?


obelisk
Wijsgeer
  • January 13, 2026

Met een eigen router moet je via dhcpv6 om een prefix vragen op de pppoe link. Deze prefix moet je zelf opdelen en uitgeven aan je lan segmenten. Hoe je dat configureert op de Asus heb ik geen weet van. 

Meestal voldoet SLAAC/RA voor deze klus. 


  • Nieuwkomer
  • January 13, 2026

Met een eigen router moet je via dhcpv6 om een prefix vragen op de pppoe link. Deze prefix moet je zelf opdelen en uitgeven aan je lan segmenten. Hoe je dat configureert op de Asus heb ik geen weet van. 

Meestal voldoet SLAAC/RA voor deze klus. 

Ja, dat weet ik. Dat is nu ook wat er gebeurt. De machines krijgen ook netjes adressen in de prefix. Alleen heeft de router zelf geen WAN adres in die prefix. En toegegeven, dat zou ook niets uit moeten maken. Binnen het LAN is de server ook gewoon via dat adres bereikbaar. Maar vanaf WAN niet.

 


obelisk
Wijsgeer
  • January 13, 2026

Een adres moet je expliciet aanvragen bij de dhcp request. Op mijn router kan ik dat aangeven. Overigens heeft je router Wan interface geen publiek adres nodig. 

Als een server binnen je LAN niet van buiten te benaderen is, dan moet dat een firewall ding zijn.