firewalld nf_conntrack_max Static Default Lacks Runtime Scaling on openSUSE

Missing Dynamic Adjustment for Connection Tracking Table

openSUSE Leap and Tumbleweed ship firewalld as the default firewall manager, which relies on the kernel's nf_conntrack subsystem. The parameter nf_conntrack_max is calculated once at boot from MemTotal (typically 65,536 entries per GB of RAM) and never adjusted afterward. High-concurrency workloads—database connection pools, HTTP servers, or container orchestrators—can exhaust this table, producing intermittent nf_conntrack: table full, dropping packet messages that surface as connection pool exhaustion.

Constraints and Uncertainty

• Increasing nf_conntrack_max consumes kernel memory (~300 bytes per entry); setting it too high risks OOM kills.
• firewalld provides no built-in monitor or scaler for nf_conntrack_max; administrators must create static /etc/sysctl.d/ drop-ins or direct rules.
• Upstream firewalld and openSUSE packaging have not decided whether to implement a dynamic adjuster (e.g., a oneshot service that scales with MemTotal and memory hot-plug events) or to document static tuning as the only supported approach.

Open Questions

1. Should openSUSE package a oneshot systemd service that reads MemTotal at boot and on memory hot-plug, then sets nf_conntrack_max proportionally with a configurable safety margin?
2. What guardrails (maximum entries per GB, absolute ceiling, watermark alerts) would prevent OOM while still eliminating table-full drops under burst loads?
3. Is there an existing firewalld hook, systemd generator, or kernel notifier pattern that could be adopted instead of a custom service?