IPv6 and access

Published with v4.10.4 on 10 October 2026. See the publication record for exact identities and IVV limits.

IPv6 connectivity needs more than an address and an open application port. A host must continue receiving the messages that maintain its neighbours, routes and address configuration. A working connection immediately after installation is not enough to establish that those messages survive filtering.

This guide explains the v4.10.4 policy and the checks to make on a representative host. Start with authenticated packages and recovery prerequisites. Consult the release assurance record for the exact tested platforms and limits.

Understand a delayed IPv6 failure#

An existing address, neighbour entry or default route can remain usable while its lifetime counts down. Connectivity may fail later if the host cannot receive the messages that refresh that state. Stateful connection tracking alone does not establish permission for all IPv6 discovery traffic. The ICMPv6 filtering recommendations in RFC 4890 explain why essential IPv6 messages need explicit treatment.

DHCPv6 and Router Advertisements have distinct roles. Receiving a DHCPv6 lease does not, by itself, prove that router discovery and default-route maintenance work. Check the host's actual addressing mode and its configured network manager. Do not change that mode just to make a firewall test pass.

What SysWarden permits#

The generated policy evaluates a bounded IPv6 control chain before SysWarden's source-reputation, geographic and connection-state filtering, in both its ingress and host-input paths.

DHCPv6 is not limited to source port 547. RFC 9915, section 7.2 permits another source port while fixing the client destination. This exception does not open IPv4 UDP 546 or a DHCPv6 server port.

The chain does not grant arbitrary application access to a router or neighbour. Redirects and unsolicited echo traffic receive no special permission from it. The kernel still validates protocol messages. The discovery checks follow the message-validation boundaries in RFC 4861, but an expected hop limit does not authenticate an on-link router.

Keep the existing network policy visible#

SysWarden does not change NetworkManager profiles, IPv6 forwarding, Router Advertisement acceptance settings or upstream router trust as part of this correction. The network and host policy must already support the intended IPv6 configuration.

A SysWarden accept verdict cannot override a drop in another nftables base chain. An administrator-managed firewalld or UFW policy can still reject traffic. Inspect the complete effective path when troubleshooting, including the cloud firewall and upstream network. The nftables base-chain documentation describes this verdict behaviour.

Verify renewal and access#

Before installation or upgrade, keep an independent console available and record the expected IPv4 and IPv6 administration paths. Retain the current addressing, routes, network-manager configuration and firewall policy privately.

These commands inspect host state without changing it:

ip -6 address show scope global
ip -6 route show default
ip -6 neighbour show

On a host that uses NetworkManager and firewalld, also inspect their state:

systemctl is-active NetworkManager.service firewalld.service

After installing the authenticated package, inspect the generated product chains:

sudo nft -a list chain inet syswarden ipv6-control-plane
sudo nft -a list chain netdev syswarden_hw_drop ipv6-control-plane

Keep these outputs private: rules, routes and addresses can expose operational details. If a chain is absent, establish whether the product is installed, configured and active before changing any rules.

Check more than immediate connectivity:

1. Confirm the expected global address and default route.
2. Observe successful route and address renewal beyond the relevant lifetimes.
3. Keep an existing authorised SSH session open and test a second session over each intended address family.
4. Repeat the checks after product policy reload, feed regeneration and any applicable firewall frontend reload.
5. Reboot the representative test host and verify access and renewal again.

Use an authorised endpoint you control for traffic checks. A failed echo request alone does not prove that IPv6 configuration failed, because echo remains subject to the ordinary firewall policy.

Preserve administrator authority#

SysWarden v4.10.4 OS hardening preserves membership of sudo, wheel and adm, together with existing group and sudo policy. A package hook may run without SUDO_USER, and the invoking account is not necessarily the only authorised administrator.

Before an upgrade, record the intended administrator accounts and their effective access. Verify those accounts again afterwards. The correction does not infer which privileges should be restored if an older installation already removed them. Restore previous access only from the administrator's known policy and trusted recovery evidence.

Keep the correction persistent and removable#

Installation, normal reload and feed-driven policy regeneration include the generated control chain. Manual insertion of workaround rules is not needed for this correction. Runtime reconciliation also recognises that exact generated chain, so the next reload can preserve compatible dynamic ban sets and their remaining lifetimes.

Removal verifies the exact generated rule set and its recorded identity. An old manual workaround, changed rule or missing ownership evidence cannot be silently adopted as product state. Follow historical recovery and complete removal if verification refuses cleanup. Preserve administrator rules and verify both product absence and unrelated protection after removal, reload and reboot.

On RHEL-family systems, removal recognises the standard nftables service loader and checks its executable and configuration dependencies without invoking its broad ruleset flush. Administrator-managed loader files and independent frontend policy remain subject to the same preservation boundary.

Incomplete nftables JSON can also prevent proof of complete ownership. For example, the older nftables 1.0.9 rendering omits ingress device identities. A refusal in that situation is incomplete recovery, not a successful complete uninstall. Use the version and recovery limits in the verified release documentation; do not bypass the check by deleting ownership evidence.

Verify native removal through its final step#

Check native package script output as well as its exit code. RPM can erase a package and report transaction success while a post-removal script fails. Confirm that product services, binaries, active rules and removal barriers are absent, that explicitly retained administrator configuration is intact, and that unrelated protection survives reload and reboot.

v4.10.4 creates a missing recovery-backup parent safely and retires the exact empty compatibility receipt and empty binary directory. It preserves the short kernel transaction deadline by synchronizing the removal journal before opening that transaction window. Live ownership and concurrent-change checks remain mandatory.

Newly created threat feed files carry exact writer-origin evidence. Old unmarked generations require an explicit review before private archival. To inspect that bounded inventory without changing the host:

sudo syswarden recover-removal --retain-legacy-lists

Review every listed file and confirm that it has no other producer. Only then use the exact apply command and digest printed by that inspection. Changed files require a new inspection. Existing administrator modules have a separate preservation decision:

sudo syswarden recover-removal --retain-operator-config

That decision preserves the reviewed configuration at its original paths; it does not authorize deleting those files. An inactive backup of the migrated flat SysWarden configuration has a separate inspection:

sudo syswarden recover-removal --retain-legacy-config

This route is available only during removal and selects one supported inactive backup at a time. Confirm that no other service or administrator workflow consumes it, then use the exact reviewed digest printed by the inspection. It preserves the original bytes and inode in private recovery storage. It excludes active configuration and incomplete migration sources, and refuses changed evidence. Each additional backup needs its own review. Never restore these inactive archives automatically during a later installation.

An inactive backup belonging to another firewall manager remains a separate recovery artifact. Preserve its original bytes and establish its role before any action. Do not delete shared frontend configuration or backups merely because they contain a former product rule.

After resolving the reported cause, retry the original removal command and repeat the complete absence and access checks. Keep recovery inventories and backups private.

Retry an interrupted RPM removal#

A native package manager may remove an unused dependency even when the product's removal hook refuses the erase. If wireguard-tools has already been removed, the v4.10.4 path can proceed only after repeated, independent checks prove that the exact unit and kernel interface are absent and no ownership artifact remains. A missing command is never proof that the VPN is absent. Active or ambiguous state still stops removal and retains its evidence.

The optional package-owned RHEL profile has an explicit two-step lifecycle: syswarden uninstall prepares runtime removal, then the native package manager erases the verified payload. Its preparation preserves the installed binaries for RPM and checks the exact package profile. This distinction does not change the standard package's native-manager removal contract.

The optional profile also preserves explicitly retained administrator TOML configuration through interrupted post-removal recovery, including later administrator edits. Empty product directories can be retired, while directories needed by those retained files remain. Unexpected contents or changed ownership evidence require inspection. If RPM reports a failed post-removal script, follow the exact recovery instruction it prints and verify the final state before treating removal as complete.