"
Seeing 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.
