"Recent posts
#1
26.7 Series / Re: SSD drive died - I disable...
Last post by oc - Today at 06:41:45 PMVielen Dank, Patrick...aber:
root@OC-OPNsense01:~ # du -sk * | sort -rn | head
du: No match.
root@OC-OPNsense01:~ # du -sk * | sort -rn | head
du: No match.
#2
26.7 Series / Re: [26.7] UPnP/NAT-PMP leaks ...
Last post by atomist23 - Today at 06:41:01 PMSeeing the same thing on 26.7.7 (miniupnpd 2.3.9_3), a CARP pair with PCP/NAT-PMP only, about 350 mappings from Tailscale clients. But symptoms match #300 exactly:
- could not find nat rule to delete on every expiry
- more than 10,500 nat quick rules in the miniupnpd anchor for about 344 live leases after 2.5 days
- the UPnP status page shows 0 active maps, because pfctl fails with DIOCGETRULE: Device busy when the anchor is that large
The root cause is the one described in #300. In 2.3.9's libpfctl code, delete_nat_rule() searches the filter ruleset instead of the NAT ruleset, so the NAT rule is never removed. Upstream fixed this in miniupnpd 2.3.11 (commit 463ec13).
The ports tree briefly had 2.3.11 (d7f73bad) and then reverted it (607426bb). Backporting only that one commit onto 2.3.9 would fix it.
Workaround until then: restart the service on a schedule. That flushes the anchor, and the leases reload from the lease file. We run it nightly from System → Settings → Cron.
This is a customer fleet with clients growing daily. I might have to restart UPnP twice daily to keep up.
- could not find nat rule to delete on every expiry
- more than 10,500 nat quick rules in the miniupnpd anchor for about 344 live leases after 2.5 days
- the UPnP status page shows 0 active maps, because pfctl fails with DIOCGETRULE: Device busy when the anchor is that large
The root cause is the one described in #300. In 2.3.9's libpfctl code, delete_nat_rule() searches the filter ruleset instead of the NAT ruleset, so the NAT rule is never removed. Upstream fixed this in miniupnpd 2.3.11 (commit 463ec13).
The ports tree briefly had 2.3.11 (d7f73bad) and then reverted it (607426bb). Backporting only that one commit onto 2.3.9 would fix it.
Workaround until then: restart the service on a schedule. That flushes the anchor, and the leases reload from the lease file. We run it nightly from System → Settings → Cron.
This is a customer fleet with clients growing daily. I might have to restart UPnP twice daily to keep up.
#3
26.7 Series / Re: SSD drive died - I disable...
Last post by Patrick M. Hausen - Today at 06:22:22 PMBesorg dir eine Shell als root.
Code Select
cd /
du -sk * | sort -rn | head
# größtes Directory steht oben
cd <directory>
# zurück zu Schritt 2 "du ..."
#4
26.7 Series / SSD drive died - I disabled mu...
Last post by oc - Today at 06:18:18 PMHello,
After about six months of having deployed my first "production" OPNsense, during a scheduled reboot (replacing the UPS with a larger one) the computer's BIOS indicated that S.M.A.R.T is deeming the drive as "about to fail". I have good backups, and was able to still access the old drive even after I had restored the setup onto the new one (I was initially missing a backup, that of ntopng, which together with zenarmor has its own configuration settings file) - so I can write if off as a good exercise of restoring OPNsense (albeit onto the same computer).
However after having gone through that experience (I never had any of my SSDs die on me, and I own some that I have used for well over ten years - including the one in the laptop I'm writing this message from), and after having more experience with OPNsense than in the beginning, and knowing that I won't spend much time with historical records (for instance I had set up Zenarmor to keep logs for 90 days, I now reduced that to three days), to extend the life of my next SSD I have decided to lighten logging considerably (I had already enabled /var/log RAM disk and /tmp RAM disk). I have disabled netflow, reduced zenarmor logging, ntopng logging, re-enabled the cron for trimming zroot - and started paying close attention to free space and S.M.A.R.T.
So here's my question: what continues to fill up my drive? The dashboard widget reports 0.7GB more used space in less than 24h. Some pointers on what to look for would be really helpful. My (new) mindset is to keep logging disabled as much as possible, and to only enable something if I need it for troubleshooting and/or forensics. But at the moment I'd like to know what's going on, what is writing to the drive - I would like this one to last MUCH longer. Note: I am not a FreeBSD file system expert, but am able to SSH/SCP in the filesystem as necessary.
Thank you :)
After about six months of having deployed my first "production" OPNsense, during a scheduled reboot (replacing the UPS with a larger one) the computer's BIOS indicated that S.M.A.R.T is deeming the drive as "about to fail". I have good backups, and was able to still access the old drive even after I had restored the setup onto the new one (I was initially missing a backup, that of ntopng, which together with zenarmor has its own configuration settings file) - so I can write if off as a good exercise of restoring OPNsense (albeit onto the same computer).
However after having gone through that experience (I never had any of my SSDs die on me, and I own some that I have used for well over ten years - including the one in the laptop I'm writing this message from), and after having more experience with OPNsense than in the beginning, and knowing that I won't spend much time with historical records (for instance I had set up Zenarmor to keep logs for 90 days, I now reduced that to three days), to extend the life of my next SSD I have decided to lighten logging considerably (I had already enabled /var/log RAM disk and /tmp RAM disk). I have disabled netflow, reduced zenarmor logging, ntopng logging, re-enabled the cron for trimming zroot - and started paying close attention to free space and S.M.A.R.T.
So here's my question: what continues to fill up my drive? The dashboard widget reports 0.7GB more used space in less than 24h. Some pointers on what to look for would be really helpful. My (new) mindset is to keep logging disabled as much as possible, and to only enable something if I need it for troubleshooting and/or forensics. But at the moment I'd like to know what's going on, what is writing to the drive - I would like this one to last MUCH longer. Note: I am not a FreeBSD file system expert, but am able to SSH/SCP in the filesystem as necessary.
Thank you :)
#5
Portuguese - Português / Re: Failover dual-WAN automáti...
Last post by zakrot93t - Today at 04:42:12 PMMuito bom tutorial! Só fiquei com uma dúvida: quando a fibra volta, o OPNsense regressa automaticamente ao Tier 1 ou é necessário ajustar algum parâmetro para garantir esse comportamento? Seria interessante saber quais as configurações de monitorização que recomendam para tornar o failover mais fiável.
#6
26.1, 26,4 Series / Re: os-ndp-proxy says it is fo...
Last post by Monviech (Cedrik) - Today at 03:29:50 PMOh, you're right, it's older than expected there. Np :)
#7
26.1, 26,4 Series / Re: os-ndp-proxy says it is fo...
Last post by really_lost - Today at 02:46:39 PMNo static prefixes listed in business ndp-proxy-go plugin and when I tried your suggestion on the commandline, it complained that --static-prefix was not defined.
Thanks, though.
Thanks, though.
#8
26.1, 26,4 Series / Re: os-ndp-proxy says it is fo...
Last post by Monviech (Cedrik) - Today at 02:35:00 PMThinking about it, it might currently also work with this configuration (enable advanced mode and you should see static prefix), you might also have to supply the upstream router link local address:
ndp-proxy-go \
--static-prefix 2603:XXXX:XXXX:XX60::/59 \
--static-prefix 2603:XXXX:XXXX:XXe0::/59 \
--static-prefix 2603:XXXX:XXXX:XX20::/59 \
--static-router fe80::XXX \
--no-ra \
--no-routes \
--debug \
igb0 \
ix2
Cause you allow your LAN side hosts to be learned, and the prefix you want to proxy is known, the ndp proxy should respond on WAN. It most likely didn't respond before because the prefix to proxy was not in the allowed prefixes, and the upstream router was not allowed via link local address. If both cannot be learned from RAs it won't respond.
You also dont need routes and RA proxying in your case.
Would still be an interesting test.
The new prefix respond mode just makes the above case simpler cause it needs less configuration.
ndp-proxy-go \
--static-prefix 2603:XXXX:XXXX:XX60::/59 \
--static-prefix 2603:XXXX:XXXX:XXe0::/59 \
--static-prefix 2603:XXXX:XXXX:XX20::/59 \
--static-router fe80::XXX \
--no-ra \
--no-routes \
--debug \
igb0 \
ix2
Cause you allow your LAN side hosts to be learned, and the prefix you want to proxy is known, the ndp proxy should respond on WAN. It most likely didn't respond before because the prefix to proxy was not in the allowed prefixes, and the upstream router was not allowed via link local address. If both cannot be learned from RAs it won't respond.
You also dont need routes and RA proxying in your case.
Would still be an interesting test.
The new prefix respond mode just makes the above case simpler cause it needs less configuration.
#9
26.7 Series / Re: Access from incoming Wireg...
Last post by beneix - Today at 02:21:30 PMQuote from: viragomann on October 04, 2026, 07:59:46 PMApart from a proper Wireguard configuration and a rule on the wg interface, which allow access to any destination, you need a source NAT rule like this:
interface: WAN
source: wg tunnel subnet
destination: any
translation: interface address (default)
Thanks! That is all that was needed. Now I just need to gather courage to one day migrate my legacy rules...😊
#10
26.1, 26,4 Series / Re: os-ndp-proxy says it is fo...
Last post by really_lost - Today at 02:11:25 PMThanks. I can wait a few weeks and test the supported version. If not, I'll snapshot and try compiling.
In either case, I'll report back in this thread.
In either case, I'll report back in this thread.
