Messages

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 LUA 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.

[because wg reports the connection as active (not stale) even though the gateway is down]

Your assessment:

Unfortunately none of the solutions here worked. The Renew DNS for Wireguard on stale connections cronjob doesn't work in my case, because wg reports the connection as active (not stale) even though the gateway is down. So the action that should be triggered to restart the wg service is not triggered.

is almost surely wrong. The way the cron script detects if a wireguard connection is stale is by looking at the last handshake age and see if it is too old (> 135s). That way, you can be sure that there is still an ongoing wireguard connection. It is beyond me how that handshake should occur with the gateway down.

You can check this yourself:

https://github.com/opnsense/core/blob/ade7e9e9c7887978abf3f425c57def324ebcac03/src/opnsense/scripts/wireguard/reresolve-dns.py

The command for testing is "/usr/bin/wg show all latest-handshakes" and the last column is compared against "date +%s". If the difference is > 135, the connection is restarted. Of course, this can take up to ~2 minutes and also, if the drop is caused by the remore side changing its IP and DNS caching gets in the way, for an even longer time, because multiple tries must be taken until the connection gets up again.

If I am wrong, please create a bug report on github.

Ja, klar. Die Namen können immer noch im Leasefile stehen, beispielsweise passiert das, wenn man bei ISC einen Lease in eine Reservierung ändert, die eine andere IP hat. Ich habe den alten Mist immer aus den Dateien manuell rausgelöscht (dazu musst Du den Daemon aber erstmal stoppen, sonst schreibt er das selbe wieder rein).

Ob sich das allerdings noch wirklich lohnt, ist die Frage, in 26.1. (also in knapp zwei Wochen) wandert ISC DHCP in die Plugins und wird nur nicht mehr supported. Ich würde empfehlen, die Gelegenheit zu nutzen und auf Kea oder DNSmasq umzustellen.

Yes, that is expected if anywhere between you and 8.8.8.8 there is a limitation of 1492 bytes (probably imposed by your ISP). That also means your settings of 1512 do not work and you cannot use 1500 bytes MTU on either OpnSense WAN or LAN, you should set them to 1492 and be content with it.

For starters, you have got a few problems here:

a. That video of the HomeNetworkGuy handles an internet connection with DHCP only, not with PPPoE - so, you cannot follow this from the very start. That is the problem with many of these video guides: They show one specific setup - in reality, every setup is different and you will have to know what your are doing.

b. Speaking of this, the question you ask about IPs clearly show that you have little to no networking skills. Different networks (like WAN with the modem and LAN with your switch and/or AP) not only have different IPs, but even different IP ranges. So, you cannot have 192.168.1.1 for the modem, 192.168.1.2 for OpnSense WAN and also 192.168.1.x for anything that connects to your LAN (like the switch and AP). Besides that, OpnSense has an IP for every which interface, say 192.168.2.1 for LAN.

c. If you aim to learn while your regular network does not get interrupted, you should consider to use OpnSense behind your ISP router first. That way, you can try out these things. However, that is what is called a "router-behind-router" scenario, which in some ways is even harder to understand than a normal setup.

You could start with this post for hints and the official OpnSense docs, I do not recommend YT videos or AI to learn this. YT videos cannot cover every variant, like you see and AI is wrong most of the time.

However, you will find that it may take you serious time to learn the skills to master this. OpnSense is a professional tool, not your average consumer appliance.

No, no change there. Yet, for me, GeoIP works fine.

Maybe you wanted to block certain regions from accessing your forwarded ports and forgot that implicit NAT rules are prioritized over interface rules?

In order to make that work, you need to create floating block rules for your WAN interface or use the inverted range in the source part of your NAT rules.

So your problem is that your OpnSense has LAN on vmbr3 aka enp90s0 and it should act as a DHCP server (which it does according to your packet traces) but your clients attached to that NIC (via a switch?) do not get DHCP IPs assigned?

If the NIC is not attached directly to a client, but via a Unifi switch or the dream machine itself, you should know that there are settings in Unifi to block non-legit DHCP servers. Maybe your Dream Machine is the only allowed DHCP server. In order to verify, try to attach a client directly to that NIC (make sure to use the correct one).

Also, since your PVE host is already attached via some bonded SFP+ NICs, I would rather use those instead of another NIC. You can distribute VLANs over that NIC(s) to do that. Besides that, I am not a huge fan of bonding except for reliability. With Unifi equipment, you will gain no more throughput via bonding, because most Unifi hardware does not support "real" load-balancing. I think that balance-rr would not work in the way you think it does.

Two basic things:

1. In order for passthru to work, you must have exclusive access in the VM, so configuring the NIC on the PVE host is a no-go. There are lots of prerequisites to do this. It cannot be successful if you do not see the NIC in the OpnSense VM.

2. This worked under Proxmox with a virtio adapter? Then Linux is fine handling your Realtek device. How do I know it is Realtek? Because your MAC OUI tells me so. See this, point 6.

I generally do not recommend using passthru unless strictly neccessary, see: https://forum.opnsense.org/index.php?topic=44159.0. bridge-mcsnoop is explained there, too. And as a general rule: Do not use AI or YT videos to learn about OpnSense. There is plenty of ggod documentation and also the tutorial section of this forum.

I have never seen any such big MTUs. With 1.1.1.1, I did not get any conclusive results. Try 8.8.8.8.

There is no automatic migration. You can set up your new DHCP server of choice (Kea or DNSmasp) according to the documentation.

The only thing that warrants non-manual setup is the static reversations IMHO, and those you can export as CSV and import to either Kea or DNSmasq.

I would first try if the MTU size is the culprit first (it may also be HTTP/2 over UDP). Use the utility from this post: https://forum.opnsense.org/index.php?topic=45658.0 to find if the 1500 byte MTU is valid from your OpnSenses.

P.S.: I skip all of the obvious problems, like Realtek adapters, Proxmox underneath with mini jumbo frames, etc. Most of that is covered in the linked article and this one: https://forum.opnsense.org/index.php?topic=44159.0

Leer lassen.