Hey Zusammen, ich habe ein Glasfaseranschluss der Telekom und das WAN Interface entsprechend konfiguriert. Ich möchte nun auch die MTU und MSS richtig setzen. Für die Telekom wird 1492 empfohlen und die opnsens zeigt als Hinweis "Calculated PPP MTU 1484" an. Was bedeutet das?
Ich habe über Ping die MTU geprüft:
ping -f -l 1456 8.8.8.8
Alles was über 1456 ist geht nicht, da es fragmentiert werden würde. Die 1456 deutet aber eher auf eine MTU von 1484 hin (IP-Header 20 + ICMP-Header 8).
Bin dacher verwirrt, ob ich nun 1484 oder 1492 eintragen soll.
Dann kommt MSS. Da ich IPv4 und IPv6 nutzen will, ziehe ich 60 hab und könnte auf 1432 bzw. 1424. Aber im Hinweis steht, dass die 40 bzw. 60 von eingetragenen Wert angezogen werden. Bin daher unschlüssig was ich eintragen soll.
Soll ich dann noch unter Firewall - > Setting - > Normalization das MSS konfigurieren, oder reicht der Wert im WAN Interface.
Hab auch im Netzwerkkontroller vom WAN in proxmox die MTU angegeben. Müssen alle Controller die MTU gesetzt bekommen?
Die MSS musst Du normalerweise nicht setzen, da sie aus der MTU abgeleitet wird.
Dann solltest Du wissen, dass der ping-Befehl unter Linux sich von dem unter FreeBSD unterscheidet, denn offenbar hast Du nicht die OpnSense CLI genutzt. Ich würde zuerst vom OpnSense-CLI testen, um den Einfluss der LAN-MTU und MSS-Clamping auszuschließen. Dort geht das so:
ping -s 1472 8.8.8.8
Eine funktionierende Ping-Size von 1472, wenn sie funktioniert, zeigt eine maximal mögliche MTU von 1500 Bytes an (eben abzüglich IP-Header + ICMP-Header).
1456 entspräche also einer MTU von 1484, was ungewöhnlich wenig ist. Normal wären 1492 oder 1488, weil man von der physischen MTU 8 Byte PPPoE-Header und ggf. noch 4 Byte VLAN-Header abziehen muss (letzteres braucht man aber oft nicht). Die Telekom verwendet m.W. sowohl bei Glasfaser wie bei VDSL PPPoE über VLAN und normalerweise macht das Tagging die OpnSense, nicht das Modem oder der ONT.
Lies vielleicht mal dies (https://forum.opnsense.org/index.php?topic=45658.0) und entferne vorher die ganzen unnötigen Einstellungen wie MSS und MSS-Clamping, bevor Du testest. Beachte auch, das die Reihenfolge der Konfiguration der Interfaces (WAN/PPPoE/VLAN/physisches Interface) eine Rolle spielt und mach dann einen sauberen Reboot vor weiteren Tests.
MSS-Clamping würde ich erst dann machen, wenn Du eine WAN-MTU < 1500 benötigst und auf Deinen LAN-Interfaces weiter 1500 haben willst - es funktioniert auch ohne, wenn Du LAN-MTU = WAN MTU setzt, aber wie gesagt: wenn die feststeht.
Je nachdem, wie Du das Ganze von der Topologie her aufgebaut hast, kann Dir da auch Dein Proxmox reinspucken (BTW: Du solltest so etwas erwähnen, das verkompliziert ggf. einiges, siehe auch hier, Punkte 8 und 16 (https://forum.opnsense.org/index.php?topic=42985.0), oder am besten gleich ganz).
Quote from: meyergru on September 17, 2025, 09:54:44 PMDie MSS musst Du normalerweise nicht setzen, da sie aus der MTU abgeleitet wird.
OK, hab die Einstellung zurückgenommen und auch die in proxmox.
Quote from: meyergru on September 17, 2025, 09:54:44 PMDann solltest Du wissen, dass der ping-Befehl unter Linux sich von dem unter FreeBSD unterscheidet, denn offenbar hast Du nicht die OpnSense CLI genutzt. Ich würde zuerst vom OpnSense-CLI testen, um den Einfluss der LAN-MTU und MSS-Clamping auszuschließen. Dort geht das so:
ping -s 1472 8.8.8.8
Eine funktionierende Ping-Size von 1472, wenn sie funktioniert, zeigt eine maximal mögliche MTU von 1500 Bytes an (eben abzüglich IP-Header + ICMP-Header).
1456 entspräche also einer MTU von 1484, was ungewöhnlich wenig ist. Normal wären 1492 oder 1488, weil man von der physischen MTU 8 Byte PPPoE-Header und ggf. noch 4 Byte VLAN-Header abziehen muss (letzteres braucht man aber oft nicht). Die Telekom verwendet m.W. sowohl bei Glasfaser wie bei VDSL PPPoE über VLAN und normalerweise macht das Tagging die OpnSense, nicht das Modem oder der ONT.
Hab jetzt den Ping über die CLI von opnsense gemacht und 1460 geht, 1461 geht nicht. (vorher war es ja 1456 als MTU und MSS gesetzt war)
Quote from: meyergru on September 17, 2025, 09:54:44 PMLies vielleicht mal dies (https://forum.opnsense.org/index.php?topic=45658.0)
Ich habe es jetzt nicht mit dem Tool getestet, aber das Skript macht ja nur den Ping solange, bis die max. Größe gefunden ist. Das habe ich manuell auch gemacht und lande bei 1460.
Jetzt würde ich diesen Wert in der Advanced Configuration setzen und nicht im WAN Interface wie bisher. Aber was meinst du mit:
QuoteAs an example, if you have a WAN over PPPoE over VLAN, you should have to set WAN MTU = 1500, PPPOE VLAN = 1508, ethernet port = 1512, and it really only works for me with these tightly controlled MTUs:
Quote from: meyergru on September 17, 2025, 09:54:44 PMBeachte auch, das die Reihenfolge der Konfiguration der Interfaces (WAN/PPPoE/VLAN/physisches Interface) eine Rolle spielt
Was meinst du damit?
Quote from: n3 on September 17, 2025, 11:25:31 PMHab jetzt den Ping über die CLI von opnsense gemacht und 1460 geht, 1461 geht nicht. (vorher war es ja 1456 als MTU und MSS gesetzt war)
Klar, also ist die MTU 1488, wie erwartet, nämlich 1500 - 8 Byte PPPoE - 4 Byte VLAN, wie ich sagte.
Quote from: n3 on September 17, 2025, 11:25:31 PMIch habe es jetzt nicht mit dem Tool getestet, aber das Skript macht ja nur den Ping solange, bis die max. Größe gefunden ist. Das habe ich manuell auch gemacht und lande bei 1460.
Das Tool ist nicht der Punkt, Du solltest vielleicht
alles lesen. Es geht darum, wie Du auch bei defekter PMTUD mit der üblichen MTU von 1500 bei WAN und LAN arbeiten kannst, ohne, dass irgendwelches MSS-Clamping o.ä. notwendig sind.
Quote from: n3 on September 17, 2025, 11:25:31 PMJetzt würde ich diesen Wert in der Advanced Configuration setzen und nicht im WAN Interface wie bisher. Aber was meinst du mit:
QuoteAs an example, if you have a WAN over PPPoE over VLAN, you should have to set WAN MTU = 1500, PPPOE VLAN = 1508, ethernet port = 1512, and it really only works for me with these tightly controlled MTUs:
Darum geht es: Du setzt die "äußerere" MTU höher (was oft funktioniert), um damit für Dein WAN-Interface wieder die "üblichen" 1500 Bytes zu erreichen. Das Beispiel findet für Dich
exakt Anwendung (wenn es funktioniert). Danach hast Du eine MTU von 1500 auf dem WAN und damit eine Ping-Size von 1472.
Quote from: n3 on September 17, 2025, 11:25:31 PMQuote from: meyergru on September 17, 2025, 09:54:44 PMBeachte auch, das die Reihenfolge der Konfiguration der Interfaces (WAN/PPPoE/VLAN/physisches Interface) eine Rolle spielt
Was meinst du damit?
Ist alles im Artikel erklärt. Wenn man die Einstellungen macht, werden sie nicht sofort übernommen. Es braucht einen Reboot, um das alles zum Funktionieren zu bringen. Heißt: Du machst die Einstellungen, aber die gelieferten Werte sind nicht "sofort" richtig.
OK, ich habe jetzt nochmal alles sorgfältig gelesen und auch alle verlinken Artikel usw. Für mich ergeben sich jedoch weiterhin Fragen, die zumindest für mein Verständnis in dem Artikel nicht geklärt werden.
Quote from: meyergru on September 17, 2025, 11:39:26 PMKlar, also ist die MTU 1488, wie erwartet, nämlich 1500 - 8 Byte PPPoE - 4 Byte VLAN, wie ich sagte.
Ergibt für mich z.B. keinen Sinn. Wie kommst du von 1460 auf 1488. Ich habe jetzt auch mal das Skript von der opnsense aus gestartet und auch da kommt eine 1460 raus. Das bedeutet, dass die MTU 1460 beträgt.
QuoteYou should set your WAN MTU to the value that the tool will tell you can achieve.
An dieser Stelle im HowTo steht aber auch nicht, wo man diesen Wert einträgt. Ich würde natürlich von hier ausgehen:
mtu.png
Ja, weiter unten geht es dann weiter und es ist nicht ganz klar, ob das Optional ist, denn es geht hier um Jumbo Frames und das unterstützt nicht jeder ISP. Die Telekom unterstützt laut Schnittstellenbeschreibung kein RFC 4638, welches Jumbo Frames über PPPoE ermöglicht. Es wird auf eine maximale/empfohlene MTU von 1492 verwiesen, was mich etwas irritiert, da ich ja nur 1460 kann.
Ich verstehe das HowTo daher wie folgt:
Wenn dein ISP Jumbo Frames NICHT unterstützt (geht bei mir)
1. Prüfe mit dem Skript, welche max. MTU du nutzen kannst
2. Füge diesen MTU Wert in WAN Interface ein
Wenn dein ISP Jumbo Frames unterstützt (geht bei mir NICHT)
1. Setze in der PPP Configuration einen MTU Wert von 1500
2. Auf der Netzwerkkarte (in proxmox) eine MTU von 1512
Der Ping-Wert ist nicht die MTU. So komme ich auf die reale MTU. Du hast gesagt, Dein Ping könnte 1460 Bytes. Mit einer MTU von 1500 gehen noch 1472 Bytes, also 28 Bytes weniger als die reale MTU. Wenn ich auf Deine 1460 Bytes maximalen Ping die selben 28 Bytes draufaddiere, komme ich auf 1488 Bytes MTU, also exakt den Wert, den man erwarten dürfte.
Dieser liegt bei 1500 Bytes MTU minus 8 Bytes PPPoE - 4 Bytes VLAN, also effektiv nur noch 1488 Bytes MTU bei PPPoE mit VLAN, wie es z.B. bei der Telekom üblich ist. Schau Dir nochmal die Bilder im HOWTO an, dann verstehst Du es.
Das ist genau der Wert, den Du auf dem WAN und dem LAN als MTU eintragen solltest, wenn Dein sonstiges Equipment oder das des ISP Mini-Jumbo-Frames mit 1512 Bytes nicht wirklich unterstützt.
Davon bin ich aber aufgrund Deiner Ausführungen noch nicht ganz überzeugt:
Der ONT (oder das DSL-Modem) und das ISP-Equipment müssen das Mini-Jumbo-Frames unterstützen, damit das Rezept mit den 1512 Bytes funktioniert. In Deinem Fall kommt aber hinzu, dass auch Dein Proxmox auf der Bridge und dem zugrundeliegenden Interface die höhere MTU haben müssen. Es muss die gesamte Kette richtig konfiguriert sein, um Mini-Jumbo-Frames durchzulassen:
ISP (außerhalb Deiner Kontrolle) -> ONT/Modem (???) -> physisches Proxmox-Interface (1512) -> vmbrX (1512) -> vtnetX (1512) -> vlanXX (1508) -> pppoeX (1500)
(und bitte innerhalb der OpnSense genau so, wie es in den Screendumps dargestellt ist, NICHT auf dem WAN-Interface)
OK Danke! Ich habe erstmal auf meinen Interfaces direkt den Wert 1488 eingetragen. Das funktioniert soweit.
Jetzt zur Optimierung:
ISP (außerhalb Deiner Kontrolle) ->
ONT/Modem (???) -> Telekom Glasfasermodem 2
physisches Proxmox-Interface (1512) -> hatte ich auf 1512 gestellt
vmbrX (1512) -> hatte ich auf 1512 gestellt
vtnetX (1512) -> hatte ich vergessen (Hardwareeinstellung der vm)
vlanXX (1508) -> meinst du damit das Interface, oder wo das das eingetragen werden? Ich nutze keine VLAN, da ich 5 NICs habe.
pppoeX (1500) -> hatte ich eingestellt
proxmox_pve.png
proxmox_vm.png
opnsense.png
Quote from: meyergru on September 18, 2025, 05:51:03 PMDieser liegt bei 1500 Bytes MTU minus 8 Bytes PPPoE - 4 Bytes VLAN, also effektiv nur noch 1488 Bytes MTU bei PPPoE mit VLAN, wie es z.B. bei der Telekom üblich ist.
Die Telekom nutzt eine IP MTU von 1492.
Ethernet maximum frame size (https://en.wikipedia.org/wiki/Maximum_transmission_unit#Ethernet_maximum_frame_size)
QuoteThe IP MTU and Ethernet maximum frame size are configured separately. In Ethernet switch configuration, MTU may refer to Ethernet maximum frame size. In Ethernet-based routers, MTU normally refers to the IP MTU.
Frame format (https://en.wikipedia.org/wiki/IEEE_802.1Q#Frame_format)
Quote802.1Q adds a 32-bit field between the source MAC address and the EtherType fields of the original frame. Under 802.1Q, the maximum frame size is extended from 1,518 bytes to 1,522 bytes.
Das VLAN-Tagging hat also keinen Einfluss auf die IP MTU, um die es hier wohl geht. Es erhöht nur die "maximum frame size".
Wenn Du Telekom hast, musst Du pppoe1 auf ein VLAN-Interface konfiguriert haben, weil m.W. die Telekom VLAN 7 benutzt.
Der Stack innerhalb der OpnSense ist also:
WAN (pppoe1) -> VLANxxx (vlan???) -> vtnetX
Schau mal unter Interfaces: Devices: VLAN. Und beachte (auch das ist beschrieben): Du kannst im VLAN selbst die MTU nicht setzen, das geht nur, indem Du das VLAN einem Interface zuweist (also ihm einen Namen gibst, was man sonst nicht braucht) und dort dann die MTU 1508 setzt.
Es sei denn, Du machst das VLAN-Tagging irgendwo anders (im Glasfasermodem selbst oder im Proxmox?).
Aha, ich sehe gerade, Du setzt das VLAN im Proxmox. Dann sieht der Stack bei Dir anders aus:
ISP (außerhalb Deiner Kontrolle) -> ONT/Modem (1512) -> physisches Proxmox-Interface (1512) -> vmbrX mit VLAN (1512) -> vtnetX (1508) -> pppoeX (1500)
@Bob.Dig: Ja, ich weiß: Das wurde alles schon im Thread zum HOWTO diskutiert. Viele modernere Gerätetreiber können einfach das VLAN immer implizit ohne Aufschlag, weil sie schon mehr Speicher haben, weshalb man die 4 Bytes für das VLAN nicht immer braucht. Die Logik führt spätestens bei QinQ in die Irre und außerdem schaden die 4 Bytes mehr definitiv nicht. Hier verwirrt es nur.
Ja genau, ich setzte den VLAN Tag über Proxmox.
Ich habe jetzt die ganzen Einstellungen gemacht, wobei ich keinen Zugriff auf das Modem habe, um dort die MTU einzustellen. Aber NIC; vmbrX, netX und pppoex ist so wie oben von dir beschrieben. FW neugestartet und proxmox neugestartet.
Das Internet läuft schonmal und das Skript spuckt jetzt eine Maximum MTU size: 1492 aus. Sollte passen, oder hätte hier eine 1500 rauskommen sollen?
Ich hätte eine 1500 erwartet, aber wie gesagt, manchmal klappt es halt nicht. Offenbar fehlen die 4 Byte für das VLAN-Tag.
Ich würde das VLAN-Tagging übrigens im der OpnSense machen - es ist dann etwas einfacher, die Installation auf eine physische Installation zu übertragen, man muss dann nur vtnetX in igcX o.ä. umbenennen, wenn man mal umsteigt. Ich würde virtuelle OpnSensen nur als Backup nutzen.
1500 - 1492 = 8. Das sieht mir nach dem PPPoE Header aus. Ist ja auch völlig normal.
Deine Obsession mit dem VLAN verstehe ich sowieso nicht ganz - ich hab noch keine Implementierung gesehen, bei der das Tag von den 1500 Bytes abgezogen worden wäre. Ein getaggter Frame hat überall hier 1500 Bytes netto und das Tag klebt "außen". Das machen die Interfaces und die Switche einfach so, wenn sie 802.1q können ;-)
Können wir ja vielleicht nachher drüber quatschen.
Ja, hast recht, Patrick, mein Irrtum. Kann nicht mal richtig rechnen... ;-)
Das mit dem VLAN-Tag ist wie gesagt, heute kein Problem mehr, die ursprüngliche Framegröße war aber mal rein hardwaretechnisch auf 1518 Bytes begrenzt. Erst durch die Einführung von VLANs wurde das auf 1522 Bytes geändert. Das wird erst mit QinQ ein Problem, aber wie gesagt, es schadet auch nichts, noch 4 Bytes mehr zuzulassen.
Und QinQ kann durchaus ein Thema sein - ich hatte beispielsweise mal ein Problem, als ich ein SFP-Modul nicht direkt in der OpnSense-Hardware betreiben konnte, wohl aber am Switch. Also habe ich als "Router-on-a-stick" das VLAN durchgereicht. Und wenn das Provider-VLAN schon genutzt wird, braucht man dann QinQ.
OK, schade. Die hoffentlich letzte Frage ist nun...
1. Lasse ich nun die Einstellungen so?
2. Passe ich die aktuelle Einstellung an? Wie?
3. Mache ich alles Rückgängig und trage nur die MTU 1488 in die Interface?
Einstellen musst Du jetzt nichts mehr, wenn WAN MTU = LAN MTU, sollte alles so gehen. Wenn die Telekom in Deinem Ausbaugebiet nur Systeme einsetzt, die keine Mini-Jumbo-Frames unterstützt, dann kannst Du nichts mehr optimieren.
Eine Möglichkeit wäre es noch, mit MSS-Clamping das LAN auf 1500 einzustellen und auf dem WAN auf 1492 Bytes zu begrenzen. Dann werden ggf, zu lange Frames zerlegt zwei mit in 1492 + 8 Bytes.
An der MSS musst Du nichts ändern, die wird automatisch abgeleitet.
Quote from: meyergru on September 19, 2025, 10:17:52 AMWAN MTU = LAN MTU
Wie meinst du das genau? Aktuell habe ich ja nur in proxmox die MTU der NIC, Bridge und vnet für WAN angepasst und die PPPoE MTU. Beim WAN Interface und LAN Interface steht kein Wert. So richtig rund läuft es noch nicht.
Meinst du mit WAN MTU = LAN MTU, dass ich in den Interfaces auch eine MTU setze? Wäre das dann die 1492? Laut dem HowTo soll mal ja in den MTUs der Interfaces ja nichts einstellen, wenn man die MTU in der PPPoE einstellt.
Ich meinte mit WAN MTU die effektiv erreichbare MTU, weil man das im WAN selbst nicht einstellen kann/sollte. Und ja, wenn Du weißt, dass nur 1492 Bytes durchgehen, sollte Dein LAN das den Clients auch signalisieren (und dafür muss es dort eingetragen sein) - der Default sind eben die durch das Howto angestrebten 1500 Bytes.
Entweder das oder eben 1500 am LAN, aber dann per MSS-Clamping eine Anpassung zwischen LAN und dem WAN mit 1492 Bytes machen. Ansonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.
Quote from: meyergru on September 19, 2025, 02:26:21 PMAnsonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.
Ähm ... der MTU-Sprung findet doch in diesem Fall schon am ersten Hop statt. Und der Client macht PMTUD. Und die OPNsense sagt ihm sofort "Fragmentation needed, DF bit set". Deshalb verstehe ich den ganzen Wirbel auch nur teilweise.
Wir hatten doch bestätigt, dass die OPNsense das ordentlich tut - also PMTUD per ICMP-Antwort unterstützen? War da was, was klemmt?
Quote from: meyergru on September 19, 2025, 02:26:21 PMIch meinte mit WAN MTU die effektiv erreichbare MTU, weil man das im WAN selbst nicht einstellen kann/sollte. Und ja, wenn Du weißt, dass nur 1492 Bytes durchgehen, sollte Dein LAN das den Clients auch signalisieren (und dafür muss es dort eingetragen sein) - der Default sind eben die durch das Howto angestrebten 1500 Bytes.
Entweder das oder eben 1500 am LAN, aber dann per MSS-Clamping eine Anpassung zwischen LAN und dem WAN mit 1492 Bytes machen. Ansonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.
Sprich in den LAN und WAN Interface die 1492 einstellen?
wan_mtu.png
Nur auf dem LAN. Was auf dem WAN geht, ist ja bekannt und wenn Du es dort setzt, besteht das Potential, dass das die pppoe-MTU implizit noch kleiner macht. Das LAN soll nur nicht mehr haben als die wirkliche Größe.
Quote from: Patrick M. Hausen on September 19, 2025, 02:58:03 PMQuote from: meyergru on September 19, 2025, 02:26:21 PMAnsonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.
Ähm ... der MTU-Sprung findet doch in diesem Fall schon am ersten Hop statt. Und der Client macht PMTUD. Und die OPNsense sagt ihm sofort "Fragmentation needed, DF bit set". Deshalb verstehe ich den ganzen Wirbel auch nur teilweise.
Wir hatten doch bestätigt, dass die OPNsense das ordentlich tut - also PMTUD per ICMP-Antwort unterstützen? War da was, was klemmt?
Also, mal ganz von vorne:
1. Früher war die Nutzlast eines Ethernet Pakets mit 1518 Bytes spezifiziert. Sucht man im Internet nach dieser Zahl und "Ethernet", wird man sehr oft fündig. Diese Größe war z.B. bei den anfangs am meisten verbreiteten PC-Karten von Novell, der NE2000 auch exakt die Größe für ein Paket.
2. Nutzbar davon war eine MTU von 1500 Bytes.
3. Später wurde mit der Erfindung des VLAN-Standards dem Paket ein VLAN-Header von 4 Bytes hinzugefügt, der bei sehr alten Karten nicht in den RAM-Puffer passte, weshalb man dann mit einer verkleinerten MTU arbeiten musste.
Der Standard verlangte eigentlich eine Hardware-Erweiterung auf 1522 Bytes für die Paketdaten - heutige Karten können das und deshalb funktionieren
meistens auch 1500 Bytes plus VLAN-Tagging.
4. Diese Rechnung hört spätestens dann auf, wenn man mehrfache VLAN-Tags (QinQ, nach 802.1q-in-802.1q) benötigt, um VLAN-Frames in VLANs einzupacken, beispielsweise, wenn man das VLAN für PPPoE-Pakete für den ISP noch in ein weiteres VLAN zur Separierung auf dem Switch einpacken möchte (z.B. VLAN 7 in VLAN 700). Hier reichen dann auch 1522 Byte Paketgröße nicht mehr aus, um weiterhin 1500 Bytes Nutzlast zu transportieren.
5. Diese Diskussion ist aber müßig, denn wenn man schon anfängt, größere Frames für das Hinzufügen von weiteren Kapselungen wie PPPoE zulassen zu wollen, schaden weitere 4 Bytes auf keinen Fall, deshalb schlage ich die sicherheitshalber immer auf. Außerdem illustriert das das Prinzip besser: jede "Schicht" erfordert durch Hinzufügen von weiteren Kapselungen mehr Platz, die man normalerweise von der Bruttokapazität abziehen muss. Der Guide zeigt, wie man umgekehrt die Bruttokapazität erhöhen muss, um die gewünschte Netto-MTU zu erhalten.
Und zum Thema MTU: Die Kommunikation zwischen Client und OpnSense funktioniert - egal, ob mit 1492 oder 1500 Bytes. Alerdings passen sich manche Clients einer kleineren MTU als 1500 Bytes auch nicht selbsttätig an, weshalb ich im LAN 1500 Bytes bevorzuge.
Außerdem: wenn die OpnSense "denkt", dass die erzielbare MTU nach außen 1500 Bytes ist und die externe Site das Gegenteil nicht signalisiert, dann wird niemandem mitgeteilt, dass es nicht geht, sondern die Pakete werden verworfen.
Also sollte man der OpnSense im Zweifel explizit "sagen", was maximal auf dem WAN geht. Und wenn das von der LAN-MTU abweicht, braucht man MSS Clamping.
Daraus folgt:
- Entweder man stellt WAN-MTU und LAN-MTU gleich ein (auf das maximal erzielbare)
- oder man lässt die OpnSense die MTUs per MSS-Clamping matchen.
Und die Königsvariante ist IMHO, sowohl LAN als auch WAN auf 1500 Bytes zu trimmen, wenn es denn irgendwie möglich ist, dann braucht man kein MSS-Clamping und alles funktioniert ohne Probleme.
Hey Zusammen, es ist schon etwas her, aber ich bin die letzten Wochen einfach nicht dazu gekommen. Mit eurer Hilfe habe ich richtig konfigurieren können und jetzt läuft es zuverlässig. Zumindest konnte ich seitdem nichts negatives feststellen. War dann doch nicht ganz trivial und daher nochmals Danke!
Als nächstes werde ich mir das dokumentieren, weil dazu bin ich auch nicht gekommen. Danach muss ich mal schauen, ob mein AdGuard Home als DNS auch in Verbindung mit IPv6 richtig funktioniert.