Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - 9axqe

#1
Thanks for that, I also felt it was surprisingly difficult.

So far these are my initial candidates (only the last 2 are FOSS):
  • Splunk Enterprise Free License – I struggle to understand if this will support netflow or not, as "Splunk Stream" seems to be additionally required to ingest it.
  • ElastiFlow – the free tier supports up to 25 netflow sources, that would be enough in my case.
  • openobserve + goflow2
  • Akvorado
#2
ah that's netflow, good to know, thanks. Yes actually, I am investigating what options exist to outsource netflow. If you have FOSS recommendations, I am interested.
#3
"flowd_aggregate.py" is also the biggest CPU consumer for my case, it just was already like that before the upgrade.

I can't make out if it's flowd_aggregate.py which is now consuming even more CPU or if it's something else that went up. For example, I have 3 "php-cgi" processes regularly at the top of the processes consuming CPU. Unbound's logger.py also seems to consume some CPU.

Overall htop doesn't allow me to find a clear culprit, everything goes up and down.
#4
I have noticed a significant CPU consumption rise in 25.7.

I already had such an increase back with 24.7.11 (it never went back down), it's worrying me a bit on the long term, the DEC695 is now reaching 50% CPU usage on a regular basis with less than a Mbps traffic going over it.

Just putting this out there to hear if anyone has seen a similar increase.
#5
When the server reboots, time is kept, but on power outage (5min), it looses time.

This is problematic for me because I have DNS over HTTPS setup, and when the router boots up thinking it's 2022 instead of 2025, all TLS handshakes fail, hence no DNS. And because NTP tries to reach "de.pool.org", it needs DNS. Catch 22.

I have added a couple of IPs to my NTP servers to prevent this from happening again, but I feel the router shouldn't lose the time within 5min, some battery is empty or defective.

Is this issue expected and if not, is there a guide on how to replace the defective battery?
#6
25.1, 25.4 Series / Re: 25.1.12 broke my OPNsense
July 23, 2025, 12:06:28 PM
>That's not what I said. 25.1.11 has a bad SQLite build as per FreeBSD ports mistake that we unfortunately caught. 25.1.12 fixes that issue.

The confusing part is that this thread is called "25.1.12 broke my OPNsense". You reply make it sound like the issue is still present in this release.

Not panicking, just wanting to get some clarity on this point before attempting the upgrade. Thank you for confirming.

This means however we are a bit off-topic here, the issue of the original poster is a different one.
#7
25.1, 25.4 Series / Re: 25.1.12 broke my OPNsense
July 23, 2025, 09:04:06 AM
I am a bit confused now: I was holding off on 25.1.11 because of this, but you are saying it is NOT fixed in 25.1.12?

Or is it a "dormant" issue that _may_ be already present in some routers in previous versions and will cause an issue when upgrading to anything 21.5.11 or later anyway (if that dormant issue is present)?
#8
Ah, thanks, now I see what the issue is. Interesting.

The reservation is for a Raspberry Pi 4 which is connected both over Wi-Fi and LAN. It is the same DUID on both interfaces, but different IPv6 are assigned for each interface, presumably due to the IAID.

Now the interesting part is that ISC DHCPv6 erroneously assigns the **same** IPv6 on both interfaces, leading to IP conflicts (Raspberry Pi not happy). Kea on the other hand correctly tells apart the two interfaces are provides it two different IPv6.

The problem of Kea is of course for creating reservations in such a scenario, since it only checks for DUID and not IAID.
#9
Is there a way to delete a lease? I could manually delete it, and add the reservation.

The volume of such occurrences in my case is low, hence that would be manageable for now.
#10
This is the feature request for DHCPv4 as far as I can tell, although it does not explicitly say IPv4, it mentions MAC:

https://github.com/opnsense/core/issues/7950
#11
Quote from: Monviech (Cedrik) on July 16, 2025, 07:04:11 AMIm curious what exactly fails when creating a reservation with the same DUID as an existing lease, does KEA crash or something? Or logs it that its ignored?

Upon clicking "save", the DUID field becomes circled with red, and a red text appears on the right of the DUID field, stating: "Duplicate entry exists"
#12
When the DUID appears truncated, you can still copy the entire DUID. Just double click the DUID to the entire cell becomes highlighted/selected and press ctrl-C. It will copy the entire DUID, including the part which is hidden.

I believe this is called a CSS text overflow ellipsis, this is not specific to the opnsense web interface.
#13
ISC had a button that allowed this conversion, this does not seem to exist in Kea, at least not for DHCPv6.

Attempting to create a static reservation fails, because the DUID already exists (as a dynamic lease).
#14
I would start by checking that DNS is actually having an issue. While the issue is happening, do DNS lookups on your computer, use completely new domains or flush your local DNS to be sure the computer is not working off its DNS cache.

What are the lookup times?

The other thing you could check when the issue is happening, is memory and CPU usage of the opnsense machine, maybe bandwidth utilisation on the LAN interface too.

I am running AdGuardHome with Unbound, exactly this setup, and it works just fine for me. But I did not use these instructions, so I might have some difference, I didn't check everything in detail. One deviation of my setup is, I am not using port 5353 for Unbound but 53530. I did this because 5353 is used for mDNS and I thought, I'd rather use a port which is not commonly used for anything.
#15
Hello,

I think the below means it's not possible to run Kea DHCPv4 on some interfaces and ISC DHCPv4 on others:

root@opn:~ # sockstat -4 | grep :67
dhcpd    dhcpd      96041 11  udp4   *:67                  *:*

ISC seems to be binding against all interfaces by default, no matter which interface I have enabled it on.

Or am I reading this incorrectly?