Network Address Translation was drafted as a temporary fix for IPv4 exhaustion, yet home networks still treat stateful translation as an indispensable security boundary. Native IPv6 restores end-to-end connectivity by assigning every host a globally routable address, which makes many administrators uneasy when dynamic upstream prefixes enter the equation. When an ISP treats your delegated prefix as a moving target, carving that block across multiple VLANs in OPNsense requires understanding the underlying protocol mechanics rather than fighting them.

Understanding the Mechanism: Prefix Delegation and the /64 Boundary

Native IPv6 routing fundamentally differs from IPv4 DHCP mechanics. In an IPv4 WAN deployment, the firewall requests a single address via DHCP and applies outbound NAT for all transit traffic behind it. With IPv6, an edge firewall requires two distinct resources: WAN connectivity to communicate with the ISP's upstream gateway, and a routed block of addresses to distribute to down-link segments.

DHCPv6 handles this split through two primary constructs:

  • Identity Association for Non-Temporary Addresses (IA_NA): Requests a single IPv6 address assigned directly to the firewall's WAN interface.
  • Identity Association for Prefix Delegation (IA_PD): Requests a routed network prefix that the firewall carves into smaller subnets for downstream interfaces.

In IPv6, the /64 prefix length is the immutable standard for a single broadcast domain. Protocols like Stateless Address Autoconfiguration (SLAAC) rely on a 64-bit interface identifier derived from endpoint MAC addresses or randomized privacy tokens. Subnetting beyond a /64 (such as assigning a /80 or /112 to a local network) breaks baseline IPv6 specifications and causes client autoconfiguration to fail.

To support multiple VLANs, an ISP must delegate a prefix larger than a /64. Consumer and prosumer connections typically deliver a /56 or /60 delegation. A /60 assignment provides 16 discrete /64 subnets, while a /56 assignment grants 256 distinct /64 networks.

Upstream ISP DHCPv6-PD Server
          │
          │ Delegated /56 or /60 Block (IA_PD)
          ▼
   [ OPNsense WAN ] (Accepts RA for Upstream Gateway)
          │
          ├── VLAN 10 (Prefix ID 0x01) ──> 2001:db8:1:10::/64 (LAN)
          ├── VLAN 20 (Prefix ID 0x02) ──> 2001:db8:1:20::/64 (IoT)
          └── VLAN 30 (Prefix ID 0x03) ──> 2001:db8:1:30::/64 (DMZ)

Step 1: Configuring WAN for DHCPv6 Prefix Delegation

To route IPv6 downstream, the OPNsense WAN interface must operate as a DHCPv6 client configured to request prefix delegation rather than relying on a static address or SLAAC handoff.

WAN IPv6 Configuration Settings

Navigate to Interfaces > [WAN] and apply the following settings:

  1. IPv6 Configuration Type: Select DHCPv6.
  2. DHCPv6 Client Configuration:
    • Configuration Mode: Basic (or Advanced if your ISP mandates custom DUID parameters).
    • Request only an IPv6 prefix: Check this box if the upstream provider routes prefixes without binding an explicit IA_NA address to the interface itself.
    • Prefix delegation size: Match the exact allocation provided by the carrier (typically /56 or /60).
    • Send IPv6 prefix hint: Check this box. This instructs the client daemon to actively request the specified prefix size rather than accepting an arbitrary default from the ISP.
    • Use IPv4 connectivity as parent interface: Leave unchecked for standard native connections. Only enable this toggle if your provider explicitly requires IPv6 DHCP exchanges to transit an existing IPv4 encapsulation or point-to-point tunnel.

Handling ISP Quirks and Upstream Prefix Sizes

Upstream edge implementations vary widely across telecom providers. A common point of confusion is expecting an IPv6 default gateway inside the DHCPv6 lease acknowledgment.

By protocol design, DHCPv6 supplies the interface address, delegated prefixes, and recursive DNS servers, but not the default gateway. The upstream gateway is discovered via ICMPv6 Router Advertisement (RA) messages sent by the ISP's edge router. The WAN interface must therefore be allowed to process incoming Router Advertisements to learn its default link-local (fe80::) route.

If an ISP provides only an IA_PD block without granting an address to the WAN interface, checking Request only an IPv6 prefix is mandatory. If the WAN interface hangs in a solicitation loop without binding a lease, verify that the firewall allows incoming ICMPv6 traffic from link-local sources, and confirm whether the provider expects an explicit delegation size hint.

Step 2: Segmenting Subnets Using Track Interface

Manual static addressing of internal interfaces is unworkable on residential or dynamic business circuits. If the ISP rotates the upstream prefix, hardcoded configurations break. OPNsense resolves this through Track Interface, which anchors local interfaces to the WAN lease and programmatically calculates /64 assignments.

Assigning Prefix IDs Across VLANs

For each local interface or VLAN requiring native IPv6 connectivity, link tracking to the primary WAN:

  1. Navigate to Interfaces > [Interface Name] (e.g., LAN, Trusted, IoT).
  2. Set IPv6 Configuration Type to Track Interface.
  3. Scroll to Track IPv6 Interface:
    • IPv6 Interface: Select WAN.
    • IPv6 Prefix ID: Assign a distinct hexadecimal value.

Because a /56 or /60 assignment yields a series of /64 slices, the Prefix ID defines which slice binds to each interface:

  • LAN (VLAN 10): Assign Prefix ID 0x01
  • Trusted (VLAN 20): Assign Prefix ID 0x02
  • IoT (VLAN 30): Assign Prefix ID 0x03
  • DMZ (VLAN 40): Assign Prefix ID 0x04

When OPNsense updates the WAN DHCPv6 lease, it calculates the network address for each tracked interface by combining the delegated base prefix with the assigned hexadecimal Prefix ID. The interface's own IP address is automatically configured within that derived /64.

Mitigating Dynamic Prefix Churn

When an ISP renumbers a connection, the delegated prefix shifts. If endpoints retain stale SLAAC addresses from the deprecated prefix, outbound traffic halts.

To minimize the impact of upstream renumbering:

  • Interface Tracking Alignment: Ensure all downstream interfaces obtain subnets strictly through Track Interface rather than static assignments. When the WAN receives a new prefix, downstream tracking logic re-indexes each /64 automatically.
  • Firewall Rule Design: Never reference hardcoded global IPv6 addresses in firewall rules. Build rules utilizing built-in interface aliases (such as LAN net or IoT net) that adjust dynamically as tracking IDs update.
  • Allow IPv6 Verification: Ensure the global toggle for IPv6 traffic processing is enabled in core firewall settings. If disabled, internal drop rules silently suppress all non-IPv4 traffic regardless of interface assignments.

Step 3: Router Advertisements and Address Autoconfiguration (SLAAC)

Once interfaces receive their respective /64 allocations, endpoints must discover their network prefix, build addresses, and locate upstream DNS resolvers. In IPv6, this is managed via ICMPv6 Neighbor Discovery Protocol (NDP) router advertisements.

Navigate to Services > Router Advertisements and configure each tracked interface.

Operating Modes: SLAAC, Assisted, or Managed

The behavior of local endpoints depends on the flags broadcast within the Router Advertisement frames:

Operating Mode Autonomous Address Configuration (SLAAC) Managed Address Configuration (M-Flag) Other Stateful Configuration (O-Flag) Client Use Cases
Router Only No No No Gateway announcement only; relies on manual host addressing.
SLAAC Yes No No Standard autoconfiguration; endpoints generate their own addresses.
Assisted Yes No Yes SLAAC for addressing; DHCPv6 for DNS and search domains.
Managed No Yes Yes Stateful DHCPv6 assignment; mirror of traditional IPv4 DHCP. 
Client Address Resolution Flow
                │
         [ Receives RA ]
                │
        Is M-Flag set?
       ┌────────┴────────┐
      Yes                No
       │                 │
[ Stateful DHCPv6 ]  Is A-Flag set?
                     ┌───┴───┐
                    Yes      No
                     │       │
                 [ SLAAC ] [ Manual ]
                     │
               Is O-Flag set?
                 ┌───┴───┐
                Yes      No
                 │       │
             [ DHCPv6 ] [ RDNSS ]
             (Options)   (Only)

Selecting the correct mode depends on client platform support across your subnets:

  • SLAAC: The router broadcasts the /64 prefix. Endpoints autonomously generate their own 64-bit interface identifier. DNS configuration relies on the Recursive DNS Server (RDNSS) option.
  • Assisted: The router advertises the prefix for SLAAC, but sets the "Other Configuration" (O) flag. Endpoints configure addresses via SLAAC, but query a stateless DHCPv6 service on the firewall for local DNS server lists and domain search paths.
  • Managed: The router sets the "Managed Address Configuration" (M) flag, instructing endpoints to obtain addresses directly from a stateful DHCPv6 pool, bypassing autonomous SLAAC generation entirely.

Android platforms do not support stateful DHCPv6, relying exclusively on SLAAC and RDNSS for address and resolver assignment. Windows, macOS, and Linux support both SLAAC and stateful DHCPv6.

For mixed environments containing mobile devices, smart home gear, and hypervisors, Assisted or SLAAC provides the widest compatibility. When using Assisted mode, ensure that Services > DHCPv6 Server is enabled for the tracked interface, configured with preferred local DNS servers, and left to derive its pool directly from the tracked WAN prefix.

Step 4: Constructing Stateful Firewall Rules for Subnetted VLANs

Without NAT hiding internal endpoints behind a single external IP, every host on a tracked interface receives a publicly routable IPv6 address. Stateful firewall policy serves as the sole barrier separating internal systems from the public internet.

Default configurations block inbound connections initiated from the outside world. However, inter-VLAN and outbound rules must be tailored to accommodate IPv6 transport requirements.

       WAN Interface (Blocks Inbound by Default)
                      │
      ┌───────────────┴───────────────┐
      │ Stateful Firewall Processing  │
      └───────────────┬───────────────┘
                      │
   ┌──────────────────┼──────────────────┐
   ▼                  ▼                  ▼
[ LAN ]            [ IoT ]            [ DMZ ]
Pass to Any        Pass to WAN only   Block to RFC 1918 / ULA
Block to IoT       Block to LAN Net   Pass specific inbound

Essential ICMPv6 Rules

Never apply a blanket block to ICMPv6. While blocking IPv4 ICMP echo requests causes few operational issues, IPv6 relies fundamentally on ICMPv6 for core transport functionality:

  • Type 133 / 134: Router Solicitation and Router Advertisement.
  • Type 135 / 136: Neighbor Solicitation and Neighbor Advertisement (the IPv6 functional equivalent of ARP).
  • Type 2: Packet Too Big (PTB) messages, required for Path MTU Discovery (PMTUD) because intermediate IPv6 routers do not fragment packets.

Dropping ICMPv6 Type 2 messages creates "black hole" connections where lightweight terminal sessions work, but transfers stall indefinitely during TLS handshakes or large payload exchanges. Permit these ICMPv6 types explicitly across all local interfaces.

Inter-VLAN Isolation

Applying effective OPNsense firewall rules to isolate IoT devices requires identical discipline under IPv6, where internal interfaces must retain outbound internet access without reaching adjacent subnets:

  1. Navigate to Firewall > Rules > [IoT Interface].
  2. Add a DNS pass rule: Permit IPv6 UDP/TCP from IoT net to the local interface IP or upstream DNS resolver on port 53.
  3. Add an isolation rule: Block IPv6 * from source IoT net to destination LAN net (or an alias defining all internal segments).
  4. Add an internet egress rule: Pass IPv6 * from source IoT net to destination any.

Because any matches both internet destinations and adjacent local /64 subnets, the block rule targeting internal ranges must always sit above the general egress pass rule in the evaluation order.

Verification and Troubleshooting

Validating end-to-end native IPv6 connectivity requires checking delegation, interface addressing, client autoconfiguration, and stateful transit.

Checking Interface Allocations

Navigate to Interfaces > Overview and inspect the assignments:

  • The WAN interface should display a link-local (fe80::) address, an upstream link-local gateway, and an active prefix delegation length.
  • Each tracked VLAN interface must display a globally unique IPv6 address matching the allocated prefix, ending with the configured Prefix ID (such as ...:01::1 for LAN).

If a tracked interface shows no assigned IPv6 address, navigate to Status > System Logs > DHCP and inspect the dhcp6c client logs for lease rejections or missing IA_PD responses from the provider.

Endpoint Validation

From a workstation on a tracked VLAN, verify client-side addressing:

On Linux or macOS:

ip -6 addr show
ip -6 route show

On Windows:

ipconfig /all

Confirm that the host has obtained: 1. A global IPv6 address matching the /64 prefix derived for that VLAN. 2. A temporary IPv6 address used for outbound privacy. 3. A default gateway matching the link-local (fe80::) address of the OPNsense interface for that segment.

Functional Routing and Path MTU Tests

Run an end-to-end ICMPv6 ping from the client to an external target to confirm stateful routing:

ping -6 -c 4 2600::

If ICMPv6 ping succeeds but HTTPS web connections to native IPv6 endpoints hang during negotiation, Path MTU Discovery is failing. Verify that firewall rules are not filtering ICMPv6 Type 2 "Packet Too Big" frames, and verify that the Maximum Transmission Unit (MTU) on the WAN interface matches the upstream carrier's line constraints. When these protocol expectations are met, OPNsense handles dynamic IPv6 prefixes across multiple VLANs without requiring manual intervention on upstream lease renewals.