OPNsense Forum

TL;DR - The Short Version
My ISP only provides a single /64 IPv6 prefix, making it impossible to give different VLANs their own native IPv6 subnets. The solution is to use a private ULA (Unique Local Address) range for all internal VLANs and create a single IPv6 Outbound NAT rule in OPNsense. This translates the private ULA addresses to the WAN's public IPv6 address, giving every device on every VLAN full internet access.

Summary of Steps - The Long Version

• Plan Your Network: Choose a private ULA prefix for your network (e.g.,
  
  
  Code Select Expand
  fd00:dead:beef::/48) and assign a /64 subnet from it to each of your VLANs.
• Configure Interfaces: Set up your OPNsense interfaces. The WAN interface gets its public address via DHCPv6. Your LAN/VLAN interfaces are configured with static ULA gateway addresses from your plan (e.g.,
  
  
  Code Select Expand
  fd00:dead:beef:10::1/64).
• Enable Router Advertisements (RA): On each internal interface, enable Router Advertisements in "Assisted" mode so clients can auto-configure their IPv6 addresses. Clients will get DNS server info from your existing IPv4 DHCP setup.
• Create the NAT Rule: In Firewall > NAT > Outbound, switch to Hybrid mode and add one IPv6 rule. This rule should be on the WAN interface and translate the traffic from your entire ULA source (
  
  
  Code Select Expand
  fd00:dead:beef::/48) to the Interface Address.
• Verify Firewall Rules: Ensure your firewall rules for each VLAN allow IPv4+IPv6 traffic to pass from the local subnet to any.

The Problem: One /64 to Rule Them All

Many of us are enthusiastic about deploying IPv6 on our home networks. The dream is to have multiple, neatly segmented VLANs—for trusted devices, servers, IoT, guests—each with its own properly routed IPv6 subnet.
I want to preface this by saying that I am very new to the world of IPv6, and this entire project has been a massive learning experience. After migrating my home network from pfSense to OPNsense, I spent weeks trying to solve this exact problem. I scoured forums and documentation but couldn't find a clear guide for this specific scenario—or perhaps my inexperience meant I wasn't searching for the right terms. This guide is the product of that struggle, written to hopefully save others the time and frustration I went through.
The core of the issue is that many ISPs create a significant roadblock:

• They provide only a single /64 IPv6 prefix to residential customers.
• They often require you to use their provided router, which may or may not support features like Prefix Delegation (PD).

A single /64 prefix cannot be subnetted further for different VLANs. This leaves you with a frustrating choice: give one VLAN native IPv6 and leave the rest on IPv4-only, or dive into complex workarounds that are often unreliable.
After moving from pfSense to OPNsense and spending a great deal of time researching, I found a stable and effective solution. This guide documents how to use Unique Local Addresses (ULA) combined with Outbound NAT (NAT66) to provide robust IPv6 internet access to every device on every VLAN, even with a limited ISP setup.
The Solution: ULA for Internal, NAT for External
Instead of trying to split the unsplittable /64, we will sidestep the problem entirely.

• Internal Network: We will assign a private
  
  
  Code Select Expand
  fd00::/8 ULA prefix to our internal networks. This allows us to create as many /64 subnets as we need for our VLANs, giving us full control over our internal addressing scheme.
• External Access: We will create a single Outbound NAT rule. This rule will take all outgoing IPv6 traffic from our private ULA range and translate its source address to the single public IPv6 address on our OPNsense WAN interface.

This is conceptually identical to how IPv4 NAT has worked for decades and is a perfectly valid way to handle this common ISP limitation.

Step 1: Plan Your ULA Network
First, choose a ULA prefix for your network. You can use an online generator or create your own
fd00::/48 prefix. For this guide, we will use the example prefix
fd00:dead:beef::/48.
Next, plan the /64 subnets for your VLANs.

Network Name	VLAN ID	IPv4 Subnet	IPv6 ULA Subnet
LAN (Trusted)	10	Code Select Expand 10.10.10.0/24	Code Select Expand fd00:dead:beef:10::/64
SERVERS	20	Code Select Expand 10.10.20.0/24	Code Select Expand fd00:dead:beef:20::/64
DMZ	50	Code Select Expand 10.10.50.0/24	Code Select Expand fd00:dead:beef:50::/64
GUEST	99	Code Select Expand 10.10.99.0/24	Code Select Expand fd00:dead:beef:99::/64

Step 2: OPNsense Interface Configuration

Assign your IPv4 and the newly planned IPv6 addresses to your OPNsense interfaces.

WAN Interface

• Navigate to Interfaces > [WAN].
• IPv4 Configuration Type: Set to DHCP.
• IPv6 Configuration Type: Set to DHCPv6.
• Ensure Request only an IPv6 prefix is not checked. You need OPNsense to get a public IPv6 address on the WAN interface itself for the NAT to work.

LAN & VLAN Interfaces

• Navigate to Interfaces > [LAN] (and repeat for your other VLANs).
• IPv6 Configuration Type: Set to Static IPv6.
• In the Static IPv6 configuration section, enter the gateway address for that subnet (e.g.,
  
  
  Code Select Expand
  fd00:dead:beef:10::1 with a /64 prefix length).

Step 3: Configure Router Advertisements (RA)

Router Advertisements are essential for your clients to automatically configure their IPv6 settings.

• Navigate to Services > Router Advertisements > [LAN] (and repeat for other interfaces).
• Set the Router Advertisement mode to Assisted. This is a flexible option that allows clients to get their address via SLAAC while still getting DNS information from a DHCPv6 server.
• Set Router Priority to Normal.
• DNS Configuration: Since your clients will be dual-stack, the simplest method is to let them receive DNS server information via their IPv4 DHCP configuration. Leave the DNS servers field in the RA settings blank. As long as your internal DNS resolver (like Technitium or Pi-hole) can resolve AAAA records, everything will work seamlessly.

Step 4: Create the Outbound NAT Rule

This is the core of the solution.

• Navigate to Firewall > NAT > Outbound.
• Change the mode to Hybrid outbound NAT rule generation and click Save.
• Click Add to create a new rule.
• Configure the rule as follows:
  
  
  • Interface: WAN
  • TCP/IP Version: IPv6
  • Source address: Enter your entire ULA prefix,
    
    
    Code Select Expand
    fd00:dead:beef::/48. This single rule will cover all your VLANs.
  • Translation / target: Select Interface Address.
  • Description:
    
    
    Code Select Expand
    NAT66 for all ULA networks
• Click Save and then Apply changes.

Step 5: Verify Firewall Rules

Ensure your internal interfaces have a firewall rule that permits IPv6 traffic to the internet. A default rule allowing traffic from [Interface] net to any is usually sufficient. Just make sure the TCP/IP Version is set to IPv4+IPv6.

Conclusion

By implementing this ULA and NAT66 configuration, you can overcome the limitations of a single ISP-provided /64 prefix. This setup provides stable, firewalled IPv6 internet access to all your internal networks, allowing you to build a fully modern, dual-stack environment without relying on your ISP for proper network delegation.

Nothing wrong with deploying ULAs, but treating IPv6 like IPv4 (private addresses NATed to a single public address) has a major caveat: When choosing a source address, clients always prefer IPv4 over a ULA (unless the destination is also a ULA). This means the IPv6 NAT will only get used for connecting to IPv6-only services. For dual-stack services, your clients will use IPv4. As a result, you'll see very little IPv6 Internet traffic with this setup.

So yes, better than nothing, but not a "fully modern dual-stack environment".
As a slight improvement, you can deploy your single delegated /64 in the "primary" LAN, while using NAT for the others.

Cheers
Maurice

On a side note: If you really only have one /64 prefix, you can still use any subnet thereof via static and DHCPv6 assignments. It is only SLAAC that breaks with anything <> /64 (as of today (https://www.ietf.org/archive/id/draft-mishra-6man-variable-slaac-08.html)).

Having said that, I never really tried that besides static assignments. Both static and DHCPv6 would only work wll if static prefixes are used - if they are dynamic, you probably need the fast change "push"-type mechanism that only SLAAC can provide, that is why I advocate for it here (https://forum.opnsense.org/index.php?topic=45822.0).

In short: if you have both dynamic prefixes and a /64 assignment only, you are limited to one /64 LAN and for the other VLANs, you need NATv6 like depicted here (Maurice's caveat is applicable). If the your prefix is fixed, you can use either DHCPv6 or static assignments, because then, you can use arbitary prefix lengths for all VLANs.

You might get away with a dirty hack, however: Because of the vastness of the IPv6 address space, you could use an unused IPv6 prefix instead of an ULA prefix. That way, this prefix would not be prioritized lower than IPv4. You can refer to this (https://en.wikipedia.org/wiki/IPv6_address) to find something useful - I would probably choose 3fff::/48 or 4000::/48. Also, it should be fairly easy to change that range, should it be used later on (3fff::/48 won't).

Or as I suggested in the past you borrow a handful of /64 GUAs from a friend, colleague, employer, ... with a larger fixed assignment. Still need to NAT, of course, but your clients will think they have GUA IPv6.

Quote from: Maurice on September 09, 2025, 06:48:45 PMNothing wrong with deploying ULAs, but treating IPv6 like IPv4 (private addresses NATed to a single public address) has a major caveat: When choosing a source address, clients always prefer IPv4 over a ULA (unless the destination is also a ULA). This means the IPv6 NAT will only get used for connecting to IPv6-only services. For dual-stack services, your clients will use IPv4. As a result, you'll see very little IPv6 Internet traffic with this setup.

So yes, better than nothing, but not a "fully modern dual-stack environment".
As a slight improvement, you can deploy your single delegated /64 in the "primary" LAN, while using NAT for the others.

Cheers
Maurice

So I actually have quite a bit of experience with NAT66 myself even made this tutorial to help people that aren't familiar with it:

https://forum.opnsense.org/index.php?topic=47644.0

But what you just said I haven't really noticed on any of my deployments over the years both official ULAs and the rest of the f000::/4 range which are technically not official "ULAS" and might be why they bypass this behaviour altogether.

I have seen the behaviour you're mentioning on only some specific use cases and very very rarely:

- Linux i almost never ever see it preferring IPv4 over IPv6
- Windows Server 2016-2025 almost never IPv4 over IPv6
- MacOS Mojave-Tahoe same as Linux
- Windows 10/11 occasionally I have indeed noticed this behaviour on specifically Desktop versions of Windows for some odd reason i ping eg google.com and it goes to ipv4 instead of ipv6 but ping -6 google.com will immediately just ping with ipv6 but it's not consistent some domains will prefer ipv4 some ipv6.

 I'm not able to replicate this consistently nor explain why but I'm curious if you've tested many other OSes and if you only use strictly ULAs or any of the other f000::/4 subnets.

Only strictly ULAs.

https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/