Messages

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

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.

Actually, it would also work for disk cloning on physical installs which often becomes neccessary with cheap SSD disks or when replacing them with larger ones. IMHO it should probably be the default. I can only imagine exotic cases where it would not work as intended, like when somebody wants to leave room on the disk for another OS. There was a case just these days, but I wonder who needs OpnSense other than as a 24/7 appliance?

gibt es eine beschreibung wie man das macht leider kein erfahrung,

Wie immer, in der Tutorial-Sektion: https://forum.opnsense.org/index.php?topic=36936.0 oder auch hier, Punkt 11.

You probably used something like this: https://github.com/FingerlessGlov3s/OPNsensePIAWireguard to do this.

If so, that means you added non-standard functionality to OpnSense, including scripts that are probably still being called and creating configurations on-the fly via cron or other means. If you cannot undo these modifications, your best bet would be to save your configuration, reinstall and import your configuration again in order to restore system state.

Just made it into the HOWTO, thanks @Maurice!

That is because OpnSense itself contacts internet sites via its WAN interface (and the MTU of that). Your LAN devices contact OpnSense with their respective LAN MTU size, which should match. If it does not, there is MSS clamping (if enabled) or else it can go wrong.

Yes, I linked it in my first answer.

And the difference to DHCPv6-derived IPs is that SLAAC-provided IPs are pushed, i.e. they are applied immediately when the GUA prefix changes.

The only thing you do not have is "known" static IPv6s that you can reference in DNS names (because the prefix can change). Usually, you do not need them anyways, because you can always use the IPv4 for internal purposes in DNS. All of that is covered in the HOWTO I linked above.

every server inside the lan (homelab) has a statiq IP fddd:31e8:3076:XX:YY
DHCPv6 with prefix and RA managed on carpv6 (also updated with IPv6 changes) and RA advertises fddd:31e8:3076:XX:YY
Do not send any DNS configuration to clients

fddd:31e8:3076:: is an ULA prefix that is not routed outside of your LAN, unless you use NAT66 or you still have the assigned GUA prefix IPv6s on top for outside access. If you use those ULA IPs for server access, fine.

But then, why / how do you rely on ISC DHCPv6?

I can see only two things it could provide: routeable IPv6 addresses, which can be handed out via SLAAC as well and leases and/or reservations which allow to use internal DNS names (which you say you do not use).

Frankly, I do not get what you are missing.

Du kannst in Interfaces->Overview sehen, welche Interfaces online sind. Bei diesem Router-behind-Router-Setup benötigst Du Outbound NAT, wenn Du von "hinter" der OpnSense Internet-Zugriff haben willst. Und ja, das WAN-Gateway (wahrscheinlich 192.168.178.1) fehlt. Das wäre alles korrekt, wenn Du auf dem WAN nicht Static IP, sondern DHCPv4 eingestellt hättest.

Vielleicht liest Du mal dies: https://forum.opnsense.org/index.php?topic=39556

Die Bilder sind viel zu klein zum Lesen.

You should change the title to include "with an UFS install" - I think you need different (probably no steps at all) inside the VM for ZFS installs.

There is a problem with your approach with ISC DHCPv6 as well: The prefix change will potentially go unnoticed for as long as your lease time, because your clients will use the old prefix for as long.

With dynamic IPv6 prefixes, you basically have two choices:

a. Use SLAAC in "assisted" mode, where DHCPv6 only supplies the DNS server (besides RDNSS) - if at all, because DNSv4 is sufficient to supply both IPv4 and IPv6 resolution. This is the safest/easiest approach and shown here. Any local traffic is done via IPv4, such that you do not need DHCPv6 to supply specific IPv6 to your devices in order to adress those in DNS.

b. If you need to have fixed IPv6, you will need to use some adresses on top of GUA that you can use for internal DNS purposes. Keep in mind that ULA will probably not work, because it is prioritized lower than even IPv4. Still, you can use any unused IPv6 prefix.

Potentially yes, but depending on working PMTUD, some sites work with the wrong MTU and some do not.