Moin zusammen,
ich nutze eine OPNSense seit ca. einem Jahr als VM auf meinem Proxmox Host. Diese lief bisher auch immer völlig problemlos.
Seit wir Glasfaser haben, komme ich aber langsam ins Verzweifeln, da ich ständig nicht-ladenden Internetseiten habe, seit wir zu DG (PPPOE + VLAN + MTU 1492) gewechselt sind.
Ich hab im Anschluss viel von MTUs gelesen (danke an @meyergru), aber ich glaube, dass ich immer noch etwas falsch eingestellt habe.
Meine Verbindung ist wie folgt:
ONT -> PVE -> NIC WAN PHY (MTU 1512) -> VMBR1 (WAN) (MTU 1512) und VMBR0 (LAN) (MTU 1500) -> VM (vtnet0 für LAN (MTU 1500) / vtnet1 WAN (MTU 1508, VLAN 7)) -> Clients
Ich habe in der GUI bei den PPPoe Einstellungen 1500 als MTU Wert eingetragen und unter WAN wird mir als berechnet 1492 angezeigt. Also eigentlich alles wie es soll. Ich habe auch beim LAN 1492 als MTU eingetragen, damit LAN=WAN - ich dachte, dass damit die Drops verschwinden. Leider klappt das nicht.
Anbei noch ein paar Bilder, damit man sieht, was ich meine:
pve-lan.pngpve-brige.pngpvevm.png
wanmtu.png
Mehr im 2.ten Post.
Vielleicht kann mir ja noch jemand helfen und mich in die richtige Richtung schubsen.
Vielen Dank! :)
LG
Ich hoffe es hilft.
Vielen Dank schonmal.
pppoe.pngwan.png2026-01-16 15_47_07-Einstellungen.pngpppoeconfig.png
Und wie ist is, wenn du mtu nicht spezifizierst und auf default Einstellungen lässt? Geh davon aus der physische Port ist exklusiv der VM zugewiesen?
Hi carepack,
alles untouched lassen war quasi meine Standardeinstellung, die auch Drops hatte.
Darum bin ich quasi erst angefangen mich mit dem Thema zu beschäftigen ...
Ja, NIC WAN ist exklusiv für OPNSense
Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann. Das steht im Guide im P.P.S. (https://forum.opnsense.org/index.php?topic=45658). Und das betrifft neben der Bridge auch den zugrundeliegenden physischen Adapter.
Im LAN dürfte das egal sein, weil man da ja nicht über die üblichen 1500 Bytes gehen muss, für das WAN aber schon. Die Alternative wäre passthru, dann kann das alles die OpnSense selbst machen. In den obigen Screendumps läuft das WAN aber über vtnetX.
Am Rande bemerkt: Die DG hat normalerweise kein PPPoE, wenn sie selbst ausbaut, sondern direkt DHCPv4. Falls also PPPoE und ausgerechnet VLAN 7 eingsetzt werden, gehe ich von einem Telekom-Reseller-Anschluss aus, für den selbstverständlich Telekom-Rahmenbedingungen gelten. Siehe dazu den prominenten Disclaimer im HOWTO, der im Wesentlichen sagt, dass die Telekom keine Mini-Jumbo-Frames unterstützt - ich unterstelle, dass das auch für Glasfaser gilt.
Ergo: Es gehen wahrscheinlich nur die üblichen 1492 Bytes MTU. Die müsste man dann auch im LAN nehmen oder MSS Clamping nutzen.
Danke für die Antwort.
Bei uns ist es nordischnet, welche ja eine 100% Tochter der DG sind ...
Ich habe das PPS natürlich gelesen ;) und hoffentlich auch so korrekt umgesetzt (siehe Screens).
Spaßeshalber habe ich die MSS nun auf 1452 gesetzt, obwohl diese ja automatisch berechnet wird...
Seit dem (ca. 1h her) läuft es ohne Abbrüche, was aber noch nichts heißen muss...
Folgender Hinweis ist im Internet für die nordischnet PPPOE Verbindung auffindbar:
Quote3. Dienstezugang / Einwahlverfahren
• Protokoll: PPPoE (Point-to-Point Protocol over Ethernet)
• VLAN-Tagging gemäß IEEE 802.1Q
° Bevorzugte VLAN-ID: 7
° Alternativ: nativ (untagged)
• Maximale Übertragungseinheit (MTU): 1492 Byte
• Authentifizierung: Benutzername + Passwort
Hab ich es dann so wie auf den Screens oder im ersten Post erwähnt, korrekt umgesetzt?
QuoteONT -> PVE -> NIC WAN PHY (MTU 1512) -> VMBR1 (WAN) (MTU 1512) -> VM (vtnet1 WAN (MTU 1508, VLAN 7)) -> Clients
und heißt das
Quoteim LAN dürfte das egal sein, weil man da ja nicht über die üblichen 1500 Bytes gehen muss
dass ich im LAN Interface ruhig wieder 1500 bzw. nichts eintragen kann?
QuoteErgo: Es gehen wahrscheinlich nur die üblichen 1492 Bytes MTU. Die müsste man dann auch im LAN nehmen oder MSS Clamping nutzen.
Also LAN auf 1492 belassen und bei WAN MSS 1452 einstellen? oder reicht eins von beiden?
Vielen Dank.
MSS <> MTU. Berechnete Werte stimmen oft nicht. Probieren geht über studieren. Wie groß die von der OpnSense aus nutzbare MTU ist, gibt Dir das Skript konkret aus, wenn Du es mit dem Ziel 8.8.8.8 aufrufst - egal, was Du eingestellt hast, es zeigt, was aktuell funktioniert.
Entsprechend stellst Du die MTU dann im LAN ein (oder Du belässt diese bei 1500 Bytes und machst MSS-Clamping.
Verstehe.
Das Skript hat mir 1464 als besten Wert ausgegeben, was dann ja einer MTU von 1492 entspricht.
Stelle ich MSS beim LAN oder beim WAN Interface oder bei beiden ein, wenn ich die MTU im LAN auf 1500 belassen möchte?
Vielen Dank.
Die MSS ergibt sich aus der MTU, muss man normalerweise nicht einstellen.
Verstehe ich und hab ich auch so aus deinen Tutorials gelesen.
Aber momentan mit MSS=1452 auf dem WAN Interface läuft das Internet schneller wie je zuvor.
Wo wäre es denn theoretisch einzustellen, wenn LAN MTU = 1500 bleiben soll ?
Das ist sowieso der Default, wenn Du nichts einstellst.
OK, vielen Dank.
Kurze Frage noch. Wenn die MTU 1492 ist oder sein muss, macht dieser Wert dann überhaupt Sinn oder muss ich ihn auch auf 1492 stellen (oder leer lassen? )
PPPOE Advanced Setting:
pppoe2.png
Leer lassen.
OK,
hab ich alles gemacht.
Mal schauen, wie es die Tage läuft.
Ich beobachte mal und melde mich :)
Danke und schönes Wochenende.
Moin zusammen,
also das Setzen des MSS Wertes 1492 bei WAN scheint tatsächlich Erfolg zu bringen.
Seit Freitag hatte ich nicht einen gedroppten Seitenaufruf.
Nach etwas weiterem Googlen habe ich dann noch folgenden GitHUB Eintrag gefunden, der genau auf das Thema eingeht:
https://github.com/opnsense/core/issues/9398
Also scheint die Berechnung des MSS Wertes bei der Konstellation PPPOE + MTU fehlerhaft zu sein, wenn MTU = 1492
Wenn ich keinen MSS Wert eintrage, bekomme ich den Wert von 1460 angezeigt, was natürlich falsch ist.
Mit Setzen des Wertes auf 1492 analog der MTU ist der Wert korrekt auf 1452.
Ich bedanke mich und wünsche noch einen schönen Sonntag :)
LG
Quote from: meyergru on January 16, 2026, 07:43:16 PMExklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.
Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)
Quote from: s.meier68 on January 20, 2026, 03:01:15 PMQuote from: meyergru on January 16, 2026, 07:43:16 PMExklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.
Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)
Quote from: s.meier68 on January 20, 2026, 03:44:04 PMDie MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes.
Die MTU gilt für den Layer 2 Payload und der beginnt dann üblicherweise mit dem Layer 3 Header, ja. Falls es ein Layer 3 gibt, was ja nicht sein muss. Also hier bei OPNsense schon, aber es gibt so Audio-Kram und ähnliches, was direkt auf Ethernet aufsetzt.
Du hast aber m.E. vollkommen Recht, dass ein 802.1q (VLAN) Header immer "außen" an den Layer 2 Frame dran geklebt wird und nicht auf Kosten der MTU geht. Ich hab das noch nie gesehen und wir haben mit VLANs angefangen, als man auch noch ISL statt 802.1q verwendet hat, ein proprietäres Format von Cisco.
Genau, natürlich gibt es eine Maximalgröße des gesamten Pakets. Diese ist bei der Verwendung von vLAN aber normalerweise um den vLAN-Header ergänzt (dann 1518) damit der Payload weiterhin 1500 Byte groß sein kann. Das gilt dann auch noch nicht als Jumboframe.... Und, ja. stimmt. MTU ungleich Payload.... :-)
Quote from: s.meier68 on January 20, 2026, 04:03:21 PMUnd, ja. stimmt. MTU ungleich Payload.
Die MTU ist die Größe des Layer 2 Payloads. Also die Ethernet MTU, von der wir hier die ganze Zeit reden.
Ich wollte an deinem vorangegangenen Post nur korrigieren, dass du geschrieben hattest, die MTU sei Layer 3. Im Layer 2 Payload sind üblicherweise Layer 3 Frames. So stimmt's dann.
Cisco IOS kennt übrigens eine Ethernet MTU und eine IP MTU. Ich muss nochmal nachgucken, was letztere eigentlich genau angibt.
EDIT:Die Interface MTU in Cisco IOS ist erwartungsgemäß die Layer 2 MTU, also meistens aber nicht immer Ethernet. Die IP MTU gibt ebenfalls die Layer 2 MTU an, aber nur für die Frames, bei denen Layer 3 IP ist. Wenn sie größer ist als die MTU wird die Einstellung verworfen und die MTU gilt. Wenn sie kleiner ist, gilt für IP die IP MTU und für alles andere die MTU.
Wozu man das braucht erschließt sich mir nicht auf Anhieb, aber jedes Feature hat eine Geschichte. Ich hab nie selbst MPLS oder L2TP Tunnel für andere geliefert - evtl. kommt das daher.
Ja, ich weiß. :-) Ich habe es aber (das war auch lange vor vlans) auch mal mit den jeweiligen OSI Headern und dem dazugeghörigen Payload gelernt... Da weiß ich manchmal nicht wie ich das nennen soll...
Zumindest MPLS wird auch draußen dran gehängt und wird eigentlich auf den Endpunkten so konfiguriert, dass die MTU auch wieder 1500 betragen kann
Wenn wir schon spitzfindig werden:
"Meistens" - nicht bei allen ISPs, die Telekom ist ein gutes Beispiel, sonst bräuchte es ja die Reduktion auf 1492 Bytes MTU dort nicht.
Und ja, es ist richtig, dass nach der Einführung von 802.1q die Hersteller dafür gesorgt haben, dass die VLAN-Tags noch zusätzlich zu den üblichen 1500 Bytes passen. Das war aber nicht immer so, z.B. vor Einführung von 802.1q und außerdem stimmt das spätestens nicht mehr, wenn man dann QinQ macht, das ist nämlich NICHT einkalkuliert.
Klar, es kann funktionieren, weil manche moderne Netzwerkhardware sogar Frames bis 9014 Bytes unterstützt, ich habe das aber im Guide so beschrieben, dass es IMMER funktioniert (gesetzt den Fall, dass Mini-Jumbo-Frames auf der ISP-Strecke auch gehen).
Mal ganz abgesehen davon, dass OpnSense auch noch ein paar Glitches hat bei der automatischen Berechnung von MSS usw. aus den gegebenen Werten. Deshalb rate ich dazu, die Werte explizit zu setzen und eher zu hoch als zu niedrig. Und dann: Nicht glauben, sondern testen - deswegen gibt es das Tool.
Quote from: meyergru on January 20, 2026, 04:57:21 PM"Meistens" - nicht bei allen ISPs, die Telekom ist ein gutes Beispiel, sonst bräuchte es ja die Reduktion auf 1492 Bytes MTU dort nicht.
Das liegt an den 8 Oktetts PPPoE Header, die eben im Layer 2 Payload transportiert werden. Hat nichts mit den 802.1q Tags zu tun.
Korrekt. Ganz safe wären 1488. Die Telekom erlaubt tatsächlich 1500 Bytes plus VLAN Tag abzüglich PPPoE - wie heutzutage die meiste Netzwerk-Hardware auch.
Die Bemerkung mit der Erhöhung der Proxmox-Payload bezieht sich darauf, dass man das tun muss, weil sonst die virtio-Karte auch auf 1500 Bytes plus VLAN beschränkt ist, nämlich als Antwort hierauf:
https://forum.opnsense.org/index.php?msg=257341
Quote from: meyergru on January 20, 2026, 05:01:03 PMKorrekt. Ganz safe wären 1488.
Nein, das ist eben nicht notwendig,zumindest nicht in Deutschland. 1492 ist safe . Für dein Gutes HowTo, welches nicht nur für D. gilt mag das allerdings anders sein.
Quote from: meyergru on January 20, 2026, 05:01:03 PMsonst die virtio-Karte auch auf 1500 Bytes plus VLAN beschränkt ist, nämlich als Antwort hierauf:
Was vollkommen ok ist. Auch aus einer virtuellen Maschine funktioniert damit PPPoE und die Anmeldung über ein dsl Modem.... Wichtig ist, dass das PPPoE Interface eine MTU von 1492 hat.
Quote from: meyergru on January 20, 2026, 04:57:21 PMWenn wir schon spitzfindig werden:
stimmt das spätestens nicht mehr, wenn man dann QinQ macht, das ist nämlich NICHT einkalkuliert.
Klar, es kann funktionieren, weil manche moderne Netzwerkhardware sogar Frames bis 9014 Bytes unterstützt, ich habe das aber im Guide so beschrieben, dass es IMMER funktioniert (gesetzt den Fall, dass Mini-Jumbo-Frames auf der ISP-Strecke auch gehen).
Das macht überhaupt nichts, die meiste Netzwerkhardware ist durchaus in der Lage neue Header mitaufzunehmen und die Framegröße entsprechend anzupassen. Ja, nicht alle aber selbst alte Switche können das. Qinq ist da keine Ausnahme.
Ein Jumboframe ist der Payload. Die Header werden, soweit ich weiß nicht mitgezählt. Selbst wenn Du 28 vLAN Header hinzufügen würdest, so lange die MTU 1500 beträgt ist es technisch kein Jumboframe
Ich verstehe deine Intention, dass ist für dein HowTo durchaus sinnvoll, aber ist inzwischen eher anders herum. Die meiste Hardware unterstützt dass, nur wenige Komponenten können das nicht.