The phrase that scares people off IPv6 is “there is no NAT,” and it is misunderstood. IPv6 firewall rules home network security does not come from hiding behind a shared address — it comes from an explicit default-deny inbound rule that your router sets by default. NAT on IPv4 blocked inbound traffic as a side effect; on IPv6 the firewall does the same job on purpose. “No NAT” does not mean “wide open.” It means the wall is now a rule you can see and audit.
I have run IPv6 default-deny across my segments for years, and the rule set is genuinely simpler to reason about than the IPv4 NAT-plus-port-forward tangle it replaces. On my WAN the whole inbound policy is six allow rules plus the implicit deny — far less surface to audit than the port-forward list it replaced. The one thing you must not do — the mistake that actually breaks IPv6 — is block all ICMPv6. Let me lay out exactly what to allow, what to deny, and why the boundary is solid.
Why “No NAT” Still Means “Not Reachable”
On IPv4, your devices share one public address and a NAT table. Unsolicited inbound packets have nowhere to go because the NAT table only has entries for connections your devices started — so they get dropped. That drop is accidental security; it was never the point of NAT, just a happy side effect. On IPv6, every device has its own routable address, so there is no NAT table doing that incidental blocking.
What replaces it is the stateful firewall. Both OPNsense and pfSense default the IPv6 WAN to block all inbound connections while allowing return traffic for connections your devices initiated — exactly the behavior NAT gave you, now as an explicit, intentional rule. The internet cannot reach your devices unless you write a rule that lets it. The protection is identical in effect; it is just honest about being a firewall instead of a routing accident.
The Default-Deny Inbound Rule Is Your Wall
The foundation of IPv6 home security is one principle: default-deny on inbound from the WAN, allow only what you explicitly intend. This is the IPv6 equivalent of “no port forwards.” Out of the box, your firewall already does this — the danger is only if you start poking holes carelessly or, worse, add a sweeping allow rule because something did not work and you wanted it fixed fast.
When you do need to expose a service — a reverse proxy, a game server — you add a narrow rule allowing a specific protocol and port to one specific internal address, and nothing else. Because there is no NAT translation, the rule points straight at the device’s global address; there is no port-forward indirection. This is cleaner than IPv4, but it comes with a catch: the device needs a stable address, which means pinning it with a DHCPv6 reservation or a static assignment rather than letting it rotate with privacy extensions. The same allow-list discipline I use for OPNsense firewall rules on IPv4 applies here unchanged.
The One Rule That Breaks Everything: Blocking ICMPv6
Here is the trap. On IPv4, plenty of people block all ICMP and nothing bad happens. On IPv6, ICMPv6 is load-bearing (its message types are defined in RFC 4443) — the protocol literally depends on it. Neighbor Discovery (the ARP replacement), Router Advertisements, and Path MTU Discovery all ride on ICMPv6. Block it wholesale and you get a network that half-works in infuriating ways: some sites load, large transfers stall, connections hang.
The worst offender is blocking Packet Too Big (type 2), which breaks Path MTU Discovery — large packets silently vanish and you get stalled downloads with no obvious cause. You do not need to allow all ICMPv6 from everywhere, but you must permit the types the protocol needs to function. The table below is the practical allow set; RFC 4890 is the authoritative guide to which ICMPv6 messages a firewall should permit.
| ICMPv6 type | Name | Why you allow it |
|---|---|---|
| 1 | Destination Unreachable | Proper error signaling for failed delivery |
| 2 | Packet Too Big | Path MTU Discovery — never block this |
| 3 | Time Exceeded | Traceroute and loop detection |
| 4 | Parameter Problem | Malformed packet signaling |
| 128 / 129 | Echo Request / Reply | Ping for diagnostics (optional but useful) |
| 133-136 | Neighbor Discovery | Link-local addressing — the ARP replacement |
Types 133 through 136 operate on the local link, so they matter on your LAN-side rules rather than the WAN. On the WAN inbound, permitting the error types — especially Packet Too Big — keeps the connection healthy while default-deny still blocks actual inbound connection attempts.
Inter-VLAN Rules Carry Straight Over From IPv4
Inbound-from-internet is only half the firewall story. The other half is traffic between your VLANs, and IPv6 does not change that design at all. My inter-VLAN policy is default-deny with explicit allow rules: the IOT /64 gets no egress except whitelisted endpoints, GUEST is fully isolated, and management is reachable only from trusted segments. These rules look exactly like their IPv4 counterparts, just matching IPv6 source and destination networks.
The practical tip: reference your VLANs by their assigned /64 (or better, by an alias or the “track interface” network object) so the rule stays correct even if addresses within the subnet change. If you built your segmentation properly on IPv4, you are duplicating that rule set for v6, not inventing a new one. The VLAN firewall rules guide covers the segmentation logic, and the per-interface setup is in the OPNsense IPv6 configuration guide.
The Mistake That Bit Me: a Stale Allow Rule
The first time my ISP renumbered the delegated prefix, an inbound allow rule I had written for the reverse proxy quietly stopped working — the rule still pointed at the proxy’s old global address, which no longer existed. Nothing errored; the service was simply unreachable from outside for the better part of a day before I traced it. That is the IPv6 failure mode nobody warns you about: there is no NAT indirection to absorb the change, so a rule pinned to a literal global address breaks the moment the prefix rotates.
The fix that stuck was two-fold: pin the host with a DHCPv6 reservation so its suffix never moves, and write the allow rule against a stable reference — a ULA address or the interface network object — rather than a hardcoded global. Since I switched to that pattern a renumber is invisible to my firewall rules. If you expose anything over IPv6, assume your prefix will change and build the rule so it survives that, not so it works only until your ISP’s next lease event.
A Sane Rule Order
Firewall rules are evaluated top to bottom, first match wins, so order matters. My WAN inbound order is: allow the necessary ICMPv6 types first, then any explicit service-exposure rules for specific hosts, then let the default-deny catch everything else. On internal interfaces: allow the segment its needed services and DNS, allow established return traffic, apply the inter-VLAN allow-list, and default-deny the rest. Keeping the allow rules narrow and the deny implicit at the bottom is what makes the whole thing auditable at a glance — you can read it and know exactly what is permitted.
If any of this feels shaky, do not half-configure it. A partially built IPv6 firewall with a stray allow rule is genuinely worse than no IPv6, which is one of the points I make in the cost-benefit take. When it misbehaves, the dual-stack troubleshooting guide and the broader setup guide are where to look.
Frequently Asked Questions
Is IPv6 insecure because it has no NAT?
No. IPv6 routers default to blocking all inbound connections with a stateful firewall, which provides the same protection NAT did on IPv4, just as an explicit rule instead of a side effect. The internet cannot reach your devices unless you write a rule allowing it. The risk is misconfiguration, not the protocol.
Should I block all ICMPv6 on my firewall?
No, never block all ICMPv6. IPv6 depends on it for Neighbor Discovery, Router Advertisements, and Path MTU Discovery. Blocking Packet Too Big (type 2) in particular breaks large transfers silently. Allow the necessary ICMPv6 types and let default-deny block actual connection attempts.
How do I expose a service over IPv6 without port forwarding?
Because IPv6 has no NAT, you add a firewall rule allowing a specific protocol and port directly to the device’s global address, with no port-forward translation. Pin that device to a stable address using a DHCPv6 reservation or static assignment so the rule keeps matching.
Does my IPv6 firewall replace my IPv4 firewall?
No, they run side by side on a dual-stack network. You maintain an IPv6 rule set and an IPv4 rule set in parallel. The inter-VLAN logic is identical, but each stack has its own inbound rules, so you configure and audit both.
What ICMPv6 types must I allow?
At minimum allow Packet Too Big (type 2) for Path MTU Discovery, plus the other error types: Destination Unreachable, Time Exceeded, and Parameter Problem. Neighbor Discovery types 133 to 136 are needed on the local link. Echo for ping is optional but useful for diagnostics.
Do inter-VLAN rules change with IPv6?
No, the design is identical to IPv4. Keep default-deny between VLANs with explicit allow rules, isolate guest, and restrict IoT egress. The only difference is the rules match IPv6 source and destination networks. Reference VLANs by their interface network object so rules stay correct.