"Recent posts
#21
26.1 Series / Re: Let's talk firewall rule o...
Last post by meyergru - January 29, 2026, 11:18:22 PMQuote from: Patrick M. Hausen on January 29, 2026, 10:17:52 PM*phew* What a rabbit hole :-)
I wonder what percentage of people can still follow what we are talking about here... ;-)
Yet, I had only the typical "Block RESTRICTED to local networks" and "Allow any to internet" rules in the RESTRICTED group, which I switched out for explicit interface rules at some point. Unless you have a large number of VLANs, it seemed more explicit that way to me.
#22
German - Deutsch / Re: "Sicheres" betreiben eines...
Last post by phil435345 - January 29, 2026, 10:35:16 PMAlles klar, dann weiß ich Bescheid. Danke nochmal für den ganzen Input, ist wirklich Gold wert! :)
#23
25.7, 25.10 Series / Re: Dnsmasq stops occasionaly
Last post by franco - January 29, 2026, 10:33:49 PMHow about testing Dnsmasq 2.92 instead?
# opnsense-revert -z dnsmasq
if this is no workie you can go back to the latest with
# opnsense-revert dnsmasq
Cheers,
Franco
# opnsense-revert -z dnsmasq
if this is no workie you can go back to the latest with
# opnsense-revert dnsmasq
Cheers,
Franco
#24
25.7, 25.10 Series / Re: Dnsmasq stops occasionaly
Last post by ligand - January 29, 2026, 10:32:20 PMI sent Simon the information. And for fun I asked Claude to take a stab.. below is its analysis...
Analysis Complete
Your dnsmasq memory issue is caused by unbounded DHCP lease tracking combined with a high volume of client activity. Here's what's happening:
The Problem
Over 16.6 hours, your dnsmasq process grew from 9.8 MB to 208 MB (a 2,017% increase). This steady growth at ~11.9 MB/hour is driven by:
355 unique MAC addresses generating continuous DHCP traffic, with dnsmasq storing lease history for:
Both IPv4 and IPv6 addresses (dual-stack)
Lease renewals and hostname resolution attempts
123 IP addresses being reused across multiple MACs
The cache is configured at size 10000, but dnsmasq doesn't automatically expire old DHCP lease data from memory, causing indefinite accumulation.
Key Contributors
High client volume: 355 unique devices is substantial for a home network
Peak activity spikes: 103-114 unique MACs active at 6 AM
Hostname conflict: Your mac-mini-server generates 740 warnings/day due to IPv6 address mismatch (DHCP trying to assign ::1863 while static entry uses ::bbc2)
Recommended Fix Priority
Immediate (today):
Restart dnsmasq to clear memory
Fix the mac-mini-server IPv6 conflict in your static host entries
Short-term (this week):
3. Monitor memory post-restart to confirm the pattern repeats
4. Enable dhcp-leasefile to persist leases to disk instead of RAM
Long-term:
5. Set up weekly automated dnsmasq restart via cron
6. Review your 355 MAC addresses - are they all legitimate/active devices?
7. Consider reducing cache-size if you don't need 10000 DNS entries
8. If the issue persists, consider dedicated DHCP server software
This is a known behavior with dnsmasq under high DHCP load rather than a bug - it simply needs periodic restarts or better lease file management.
Analysis Complete
Your dnsmasq memory issue is caused by unbounded DHCP lease tracking combined with a high volume of client activity. Here's what's happening:
The Problem
Over 16.6 hours, your dnsmasq process grew from 9.8 MB to 208 MB (a 2,017% increase). This steady growth at ~11.9 MB/hour is driven by:
355 unique MAC addresses generating continuous DHCP traffic, with dnsmasq storing lease history for:
Both IPv4 and IPv6 addresses (dual-stack)
Lease renewals and hostname resolution attempts
123 IP addresses being reused across multiple MACs
The cache is configured at size 10000, but dnsmasq doesn't automatically expire old DHCP lease data from memory, causing indefinite accumulation.
Key Contributors
High client volume: 355 unique devices is substantial for a home network
Peak activity spikes: 103-114 unique MACs active at 6 AM
Hostname conflict: Your mac-mini-server generates 740 warnings/day due to IPv6 address mismatch (DHCP trying to assign ::1863 while static entry uses ::bbc2)
Recommended Fix Priority
Immediate (today):
Restart dnsmasq to clear memory
Fix the mac-mini-server IPv6 conflict in your static host entries
Short-term (this week):
3. Monitor memory post-restart to confirm the pattern repeats
4. Enable dhcp-leasefile to persist leases to disk instead of RAM
Long-term:
5. Set up weekly automated dnsmasq restart via cron
6. Review your 355 MAC addresses - are they all legitimate/active devices?
7. Consider reducing cache-size if you don't need 10000 DNS entries
8. If the issue persists, consider dedicated DHCP server software
This is a known behavior with dnsmasq under high DHCP load rather than a bug - it simply needs periodic restarts or better lease file management.
#25
26.1 Series / Re: MiniUPNPD
Last post by Marius_ - January 29, 2026, 10:18:02 PMHi,
It worked perfectly fine on 25.7.11 before upgrade... :)
I got the same errors... After upgrade.
2026-01-29T22:10:40Errorminiupnpdpfctl_get_rules_info: Invalid argument
2026-01-29T22:10:40ErrorminiupnpdFailed to add NAT-PMP 28159 TCP->192.168.1.19:32400 'NAT-PMP 28159 TCP'
2026-01-29T22:10:40Errorminiupnpdioctl(dev, DIOCCHANGERULE, ...) PF_CHANGE_GET_TICKET: Invalid argument
2026-01-29T22:10:40Errorminiupnpdpfctl_get_rules_info: Invalid argument
It worked perfectly fine on 25.7.11 before upgrade... :)
I got the same errors... After upgrade.
2026-01-29T22:10:40Errorminiupnpdpfctl_get_rules_info: Invalid argument
2026-01-29T22:10:40ErrorminiupnpdFailed to add NAT-PMP 28159 TCP->192.168.1.19:32400 'NAT-PMP 28159 TCP'
2026-01-29T22:10:40Errorminiupnpdioctl(dev, DIOCCHANGERULE, ...) PF_CHANGE_GET_TICKET: Invalid argument
2026-01-29T22:10:40Errorminiupnpdpfctl_get_rules_info: Invalid argument
#26
26.1 Series / Re: Let's talk firewall rule o...
Last post by Patrick M. Hausen - January 29, 2026, 10:17:52 PMQuote from: meyergru on January 29, 2026, 10:14:21 PMLook under Firewall: Groups, the interface group have an assigned "sequence" which I believe to determine the order.
I never noticed this exists. Bummer! Thanks!
They are both set to 0 - so it's alphabetical or order of creation or whatever, but at least now I know how to force a specific order.
EDIT:
I could not find that in the docs - lowest number wins. All automatic groups (IPsec, OpenVPN, WireGuard) are set to 10 by default, all user created ones to 0.
If I set "Internal" to 1 and "Restricted" to 2, outbound SMTP is still blocked, if I change "Internal" to 3, it's allowed.
*phew* What a rabbit hole :-)
#27
26.1 Series / Re: Let's talk firewall rule o...
Last post by meyergru - January 29, 2026, 10:14:21 PMMade me laugh, Patrick, because I have exactly the same distinction between "internal" and "restricted" (this one even with the same name).
As for your question: Look under Firewall: Groups, the interface group have an assigned "sequence" which I believe to determine the order.
As for your question: Look under Firewall: Groups, the interface group have an assigned "sequence" which I believe to determine the order.
#28
25.7, 25.10 Series / Re: Let's Encrypt IP address c...
Last post by adv - January 29, 2026, 10:12:03 PMQuote from: gspannu on January 29, 2026, 08:25:46 AMQuote from: adv on January 29, 2026, 01:02:01 AMThanks for the help, everyone. I guess we'll wait and see....
I guess it may have been implemented in 26.1, I haven't had chance to read the changes notes (or install 26.1 yet), but I have an inclination, it has been included...
So you are saying such functions as described by @rajiv may have been included in 26.1? Where would I find that functionality in the menu structure?
#29
Hardware and Performance / Re: No thermal sensors on D750...
Last post by Patrick M. Hausen - January 29, 2026, 10:11:24 PMDid you set the thermal sensors to "AMD"?
System: Settings: Miscellaneous: Thermal Sensors
System: Settings: Miscellaneous: Thermal Sensors
#30
German - Deutsch / Re: "Sicheres" betreiben eines...
Last post by meyergru - January 29, 2026, 10:10:07 PMSiehst Du, die Subnetzstruktur wäre mit OpnSense eben kein Problem (mit VLANs).
Der Reverse Proxy läuft auf der OpnSense und reicht namensbasiert von seiner IP 10.1.0.3, wo er auf 80/443 lauscht zu dem (oder den) Webserver(n) im "LAN" (= DMZ) durch. Er kann u.a. die Beantragung von Zertifikaten machen. Ob es Caddy oder HAproxy ist, ist dabei ziemlich egal und man kann es natürlich auch mit IPv4 only machen.
Unterschätze den späteren "Umbau" nicht - es ist wahrscheinlich einfacher, gleich alles richtig zu machen - besonders, wenn die Frau und die Kinder dann nerven, weil das Netz wieder nicht mehr funktioniert.
Der Reverse Proxy läuft auf der OpnSense und reicht namensbasiert von seiner IP 10.1.0.3, wo er auf 80/443 lauscht zu dem (oder den) Webserver(n) im "LAN" (= DMZ) durch. Er kann u.a. die Beantragung von Zertifikaten machen. Ob es Caddy oder HAproxy ist, ist dabei ziemlich egal und man kann es natürlich auch mit IPv4 only machen.
Unterschätze den späteren "Umbau" nicht - es ist wahrscheinlich einfacher, gleich alles richtig zu machen - besonders, wenn die Frau und die Kinder dann nerven, weil das Netz wieder nicht mehr funktioniert.
