How to Configure IPv6 Firewall Rules for a Self-Hosted Home Server

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Apply a stateful default-deny policy to unsolicited inbound IPv6 traffic and allow only the public services you intend to expose. Do not copy an IPv4 ruleset blindly or rely on the absence of port forwarding.

IPv6 hosts may receive globally routable addresses, so the router and host firewall—not NAT—must enforce the boundary. The main operational risk is overblocking ICMPv6, which supports neighbor discovery, router discovery, and packet-size feedback. Begin with inventory and an external test, preserve console access, and change one layer at a time.

Inventory addresses, interfaces, and exposure

Identify the server's global, unique-local, and link-local addresses and which interfaces receive them. Confirm whether the ISP prefix changes, because rules tied to one full address can silently become stale.

List every listening socket for IPv6 and map it to an intended audience: LAN only, VPN only, or public. A service bound to :: may accept connections on every IPv6 address unless the firewall restricts it.

Perform an external scan from a network that genuinely has IPv6. Recent research found many residential devices directly reachable over IPv6, reinforcing why residential IPv6 exposure should be measured rather than assumed.

Build the stateful baseline

Allow loopback, established and related traffic, and necessary local-network control traffic. Drop invalid state and unsolicited inbound forwarding by default.

Permit the required ICMPv6 message types instead of blocking the protocol wholesale. If address assignment, neighbor reachability, or large transfers break after the rule change, restore ICMPv6 handling before altering application ports.

Keep the router's input policy separate from the server-forwarding policy. Exposing an application through the router does not require exposing the router's own SSH or web interface.

Add narrow service rules

Allow each public service by destination server, protocol, and port, preferably on the external interface only. Keep database, container management, and storage administration limited to trusted LAN or VPN sources.

Use a stable destination strategy supported by the firewall, such as interface groups, prefix aliases, or host rules updated with prefix changes. Verify the rendered rules after every delegated-prefix renewal.

If the service is behind a reverse proxy, expose only the proxy ports and keep the upstream private. The ZimaSpace guide to reliable Immich network shares helps keep storage-path failures separate from exposure and firewall changes.

-15% OFF
Single board computer zimaboard2

Validate from both sides of the firewall

From an external IPv6 connection, test the intended HTTPS name and then scan a small explicit set of prohibited admin ports. The service should connect with the correct certificate, while the admin ports remain closed or filtered.

From the LAN, renew the client address, resolve names, and run a large transfer. These checks prove that router advertisements, neighbor discovery, and path-MTU feedback still work.

Review counters and logs, then remove temporary logging that is too noisy. Roll back if the server loses address configuration or large flows stall; stop publishing the service if you cannot verify the policy from an independent external IPv6 network.

Support & Tips

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.