Messages

Too little information given here. Sounds like a router-behind-router setup. See this, especially points 1, 4 and 16.

And BTW: There is no such thing as "lo0 routing".

1 & 2: The message does not apply to the microcode updates, you are misreading the console output.
3: Use "dmesg | fgrep microcode" on the CLI to see if an update was applied.

I did not say that the host discovery service erroneously detects all hosts.

I think (but cannot reproduce) that the mere active service causes ping responses for any IP "somehow" and "sometimes" (I know that sounds strange given that I cannot reproduce this, but have seen it happen more than once). This alone lets DHCP think the IPs are active.

That has nothing to do with what the host discovery service detects. It works via ARP and NDP, supposedly, but I have not looked into it.

I repeat: If you want to rule this out, you should disable that specific service. Of course, the adresses can onyl be resused once they time out or are beig deleted. None of this has to be taken off-hours, because no step in it will cause service disruption of more than a few seconds - and above all, your DHCP cannot hand out IPs at this time, anyway.

If you leave the host discovery service running and I am right, the deleted IPs will get reserved again. Probaby, you do not need it - before 26.1., it did not exist.

The automatic MTU calculation seems broken currently, also MTU sizes differ between IPv6 and IPv4. However, with IPv6, PMTUD is a mandatory feature, unlike IPv4. Thus, this should always work. If it does not, then likely your IPv6 setup is broken. See this.

Usually, there are only ISOs for the major versions. Everything else is done via online updates only. Sometimes, there are ISOs after a "full" release, especially when the installation itself was buggy.

I can:

1. packages.microsoft.com does never respond to ping requests:

Code Select Expand

~# ping packages.microsoft.com
PING packages.microsoft.com (2620:1ec:46::45) 56 data bytes
^C
--- packages.microsoft.com ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 10218ms

root@baremetal:~# ping -4 packages.microsoft.com
PING packages.microsoft.com (13.107.246.45) 56(84) bytes of data.
^C
--- packages.microsoft.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5150ms

That does not mean it does not work:

Code Select Expand

root@baremetal:~# nmap -Pn -p80,443 packages.microsoft.com
Starting Nmap 7.95 ( https://nmap.org ) at 2026-03-19 15:08 CET
Nmap scan report for packages.microsoft.com (13.107.213.45)
Host is up (0.0080s latency).
Other addresses for packages.microsoft.com (not scanned): 2620:1ec:bdf::45 2620:1ec:46::45 13.107.246.45

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

root@baremetal:~# nmap -Pn -p80,443 -6 packages.microsoft.com
Starting Nmap 7.95 ( https://nmap.org ) at 2026-03-19 15:10 CET
Nmap scan report for packages.microsoft.com (2620:1ec:bdf::45)
Host is up (0.014s latency).
Other addresses for packages.microsoft.com (not scanned): 2620:1ec:46::45 13.107.213.45 13.107.246.45

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 0.78 seconds

2. AFAIK, German Telekom always uses PPPoE "somewhere". In that, your maximum MTU can be limited to 1492 bytes. You did not say if that is a special business connection or what "fiber modem" you use. You can test what MTU is feasible for you - see this, point 9.

I thought you meant DHCPv6 because of the DUID discussion. As to your questions:

1. I wrote that: Stop the Kea service, delete all entries from /var/db/kea-leases4.csv* or delete the files, start Kea again.
2. I told you how DHCP works in general: If a legitimate client asks for an IP, the DHCP server uses a presumably "free" tentative address from the pool and pings it. If it gets back an answer, it knows it cannot use that IP and uses the next free one from the pool. So if "something" makes "someone" reply to pings, this effect would ensue.


Note that I only know these things for sure:

a. I have seen ping replies for all IPs on my network when I had the host discovery service enabled. I cannot reliably reproduce that behavior, if I could, I would have done a bug report on Github.

b. I know that ISC DHCP works like I said in point 1. I do not know if Kea works the same or if it actually registers such tentative IPs as taken in its database, but my educated guess from your observations seem to indicate that. Also: how should it prevent using an already-dismissed IP otherwise?

P.S.: Going back to 26.1.3 or any 26.1.x version will not fix that problem (if that is the case), because the host discovery service was introduced with that. The only remedy if the host discovery service is the culprit would be to disable it - which I did shortly after I discovered the ping problems.

I use KEA, but not actually with DHCPv6.

If you really have disabled DUID-based handout, one would argue that there must be different MACs associated with the filling of the pool. That could in theory by caused by some device(s) that change their MACs for privacy reasons, like iPhones do it these days.

However, what is strange is that apparently, the lease entries do not have a MAC or DUID associated.

My observation is that sometimes, I saw an abundance of IPv4s answering to my ping detection service on my LAN when I had "Interfaces: Neighbors: Automatic Discovery" active. If that serive is active on your OpnSense, I would disable it completely, stop Kea, clean out the DHCPv6 leases manually, restart Kea afterwards and observe if the problem goes away.

Do not ask why this happens - I never investigated any further, I just disabled the service. I cannot even tell if there were actual DHCPv4 leases in those situations. My theory here would be something like: The cause may be the way DHCP makes sure that no IP collisions occur by first pinging a tentative IP:

A (legitimate) client asks for an IP, Kea chooses one, but always gets a ping answer and sets it as reserved (but with no DUID and no MAC), afterwards, it switches to the next free IP, to which it again gets a ping answer, and this repeats until there are no pool IPs left.

You did not say anything apart from the Zenarmor part about multithreading.

See this, point 10:

a. With speeds > 1 GBit, you need to enable multithreading for unimpeded measurements.
b. You also need to enable RSS to use all cores. It may also depend on how the FreeBSD NIC drivers are optimized, there may be special tuneables for yours.

That being said: With Zenarmor, you can only utilize one thread at this time. Period. Pinning a core does only make sure that this one core does not get utilized by anything else, but you will still be limited by it.

You probably installed a newer version of OpnSense where ISC DHCP has become a plugin. Once you have your internet back up, you can reinstall the package and get everything up and running again.

Patrick, my settings look like the one above, as well. Your seems to be from an old version or the business version. There is no dropdown in "Source Adress" with 26.1.4, not even when a CARP VIP exists on the interface.

Vielleicht mal die Suche nutzen? Siehe auch: https://forum.opnsense.org/index.php?topic=42985.0, speziell Punkt 16.

https://forum.opnsense.org/index.php?topic=50961

https://forum.opnsense.org/index.php?topic=50357

https://forum.opnsense.org/index.php?topic=51055.0

Willkommen im Forum!

Apart from the hype, what is it good for? I mean, apart from > 1 Gbps connections...

Ich verstehe den Ansatz nicht:

Du willst einen extra Switch anschaffen, in den dann ein GPON-SFP-Modul gesteckt wird und den Switch dann auch per DAC-Kabel an einen SFP-Port des Routers anschließen?

Im Gegensatz zu: Einfach einen externen ONT per RJ45 mit dem Router zu verbinden?

Es ist erst eine Änderung, wenn Du danach Apply drückst.

Und dann greift halt die Tatsache, dass OpnSense mit pf eine stateful Firewall ist - gleichzeitig Segen und Fluch: Du musst, wenn Du eine Richtung erlaubt hast, die Antworten nicht explizit erlauben. Andererseits merkt sich die Firewall den Zustand und lässt zunächst weiter Pakete zu.

Bei ICMP ist das besonders seltsam, weil es da per se keine "Richtung" gibt - entweder die Pakete sind zulässig oder nicht. Und wenn man ein Ziel pingt, werden Antworten sowieso zugelassen. Dann darf auf einmal auch das Ziel selbst Pings auslösen, weil der Zustand es erlaubt.