Hello!
I made a tutorial about this on the pfsense forums and my goal was to make it here as well since I use both even though nowadays I am mostly leaning towards OPNsense due to the netgate policies but I personally prefer the UI of pfsense just old habits and whatnot but anyway.
I literally am tired of reading about people not knowing how IPv6 works on the internet in general assuming that you either have only public addresses or nothing, anything outside of ULAs without internet access or public IPv6 = impossible. The worst part is that they use this an excuse not to implement IPv6 in their network but now that's over.
The point of this tutorial will be to change this concept once and for all and hopefully this will change a few things for a lot of people out there. As in I want to plant the final nail in the coffin and answer all the questions once and for all.
If you just want the tutorial skip to the chapter where I talk about this but first an introduction to the scope of the problem. And excuse my rant :)
1 -- Introduction:
NAT44 came to resolve a problem the lack of IPv4 addresses or at least many would assume that at first glance or if you ask the people at IANA about RFC1918 (that is after they regain consciousness from their panic attacks upon you mention that RFC) you will get a lot of angry, dismissive and frowny comments from them about how awful it was and that IPv6 with all public addresses came exactly to address this problem, as in the whole point of IPv6 was to solve the lack of addresses of IPv4.
The reality is that NAT44 brought one major security benefit, your computers can be in a safe internal network without being immediately exposed to the internet or rely on a system firewall which you may/may not have control over it, you also don't have to worry about unencrypted traffic being sniffed by your ISP as in traffic in transit from amongst your internal computers, does it mean NAT is a security feature? Yes and No, the whole point of having an edge and core router is to control and direct traffic with far more horsepower than your phone/fridge/security camera has in terms of routing and firewall but we'll get to that.
The point of NAT is simple, control, your network your rules no one else has the right to force you to design your internal network a certain way, as for security it does provide you with advanced port control where it needs it, you can route ports out different uplinks, load balance and just in general have full control, but that means that if you have a machine where having a certain port exposed to the internet will cause it to be compromised by being on an internal network that cannot be reached from the outside it puts you in a position where NAT is your most important security feature in this example, but of course if you were to route that port to a public ip address (v4 or v6 doesn't matter what it is) you would be just as compromised, the key is control.
The people at IANA decided that the common/average IPv6 deployment MUST be public and NAT is evil, and your system must be able to handle security individually (given no network firewall in between such as opnsense) which is a common case with the average people which only have an ISP provided box in their home if you think about it, not everyone out there is even aware of the benefits of having a firewall in their network and can perceive that as an unnecessary expense because 'it just works', but in reality having a firewall is quite important and no i'm not shilling for firewall platforms whether it's opnsense pfsense or any other firewall solution available in specific, regardless whether it's paid or free this applies to any firewall out there that is controlling the traffic from outside to inside.
Ask yourself, do you want or need a public ip address on your smart fridge, your phone, your security camera, your computer even, do you actually NEED it, as it are you actually accessing it's resources directly over the internet (not using an encrypted site-to-site tunnel such as wireguard with static routes/iBGP) do you want a botnet to have the same access to your devices as you do while they constantly try to use common known exploits and even brute force to get into all of your devices while you sleep? Does that sound like a good way to setup network? Because this is how IANA thinks it should be, you buy a fridge which you have 0 access to it's firewall features it relies on some cloud server for control/software updates if they decide to make your fridge EOL and you keep it connected you're on your own and they never provided any access to control services/ports for it most likely.
Yes I am absolutely furious with IANA for many reasons, I have tried to push for an ID (Internet Draft) in the past to acknowledge and standardise the prefixes for NAT66 but upon being met with hostility by pretty much everyone there I gave up and instead decided to simply spread the word because the bottom line is this, you don't need anyone's permission to do anything internally you can run any IP prefix inside your private network the only advantage of having standard prefixes is to avoid the possibility of not being able to reach an external network. They did standardise some of the prefixes and pretty much all of them are in the f000::/4 subnet for many purposes and not only NAT/ULA but the "F" prefix was designed to be a special use case prefix multicast/ula/link-local/site-local etc.
What is f000::/4? It's everything from f000:0000:0000:0000:0000:0000:0000:0000 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff It consists of 8 hextets (unlike IPv4's octets IPv6 it's called hextets). It is perfect for NAT66/NPt it allows you to customise 8 hextets allowing you lots of freedom when organising your internal addresses, you can do something like this for example:
f1:33:3:1a :: 1 : 2 : 3 : 4
f1 = Network 1/Organisation 1
33 = France
3 = Strasbourg
1a = Location 1 Building A
:: = Separator
1 = 1st Internal Separation
2 = 2nd Internal Separation
3 = 3rd Internal Separation
4 = 4th Internal Separation
This gives you the network f1:33:3:1a::/64 for this site/location. Again just an example feel free to customise as you please it's your network after all.
Something like f1:33:3:1a::77::2a (could mean for instance 77 = Virtual Machines, 2a = VM 2 and the A is the first virtual IP or simply 2 for physical nics) f1:33:3:1a::/64 being your network in this example, conveniently sized, easy to route, organised and now if the public IPv6 changes or the entire prefix changes your internal addresses are static/dynamically assigned by your own infrastructure and everything will work as expected without any outages.
See how customisible this is? Instead of using randomly assigned ISP owned addresses you have lots of flexibility and lots of addresses thanks to f000::/4, not everything is available for use let's explore further:
Let's separate these further:
f000::/8 - f999::/8 = The "numbers", Available to use!
fa::/8 and fb::/8 = Also not in use, Available to use!
fc::/8 and fd::/8 = Those are actual ULAs RFC4193, these are used by many things because it's an "official" local IPv6 address much like the ones from RFC1918 but the downside is using these can lead to problems for instance the matter protocol assigns fd::/8 addresses to your local devices for internal communications, so if you use matter at home i would stay away from using fd::/8 as your internal network, fc can be used by certain things like VPNs and whatnot so to avoid the possibility of things not working i usually don't touch fc either but technically fa fb fc are all options as well I like using fa fb for SAN networks.
fe80::/8 - I do not touch fe either because of fe80::/10 as defined in RFC 4291 is used for link-local this is a core feature of IPv6, fec0::/10 used to be site local unicast but it has been since deprecated RFC 3879 for references. and finally ff00::/8 is multicast also from RFC4291.
In short you can use anything from f000::/4 except "fe,ff" and you should avoid "fc,fd" just in case something else may need it, literally everything else up for grabs eg. f1f3:: f333:: f16:: f22:: f35:: f117:: etc
so for a SAN literally fa::3:1a/64 as the example for the VM used earlier even fa::1 would be a nice short ipv6 in this network, it can be even easier to remember than IPv4, all this can be your reality it does not have to be complicated it does not have to be difficult, IPv6 can be this easy.
UPDATE: I now recommend absolutely to avoid ULAs (fd:: and fc:: due to RFC 6724) it seems that those specific subnets will usually prioritise IPv4 traffic and other oddities so you can absolutely use them for special use cases but for a LAN or a dual stack setup I recommend the other f000::/4 subnets which work because they're not official ULAs (so I guess I want them to be that way now).
2 -- Understanding your options at the network design level.
A - Direct IPv6:
This could be a desired configuration sometimes, just like servers that had their public IPv4 directly on device, if you have limited resources a VM or a machine somewhere with a single ipv4 and even a large ipv6 prefix but a very simple purpose it may be the case that all you want is just a public ipv6 and ipv4 with nothing in between but ufw/iptables and that's about it, there is a use case for it but certainly shouldn't be the default just like using public IPv4 even if there were enough IPv4s out there would've seem quite insecure because it is but it means no added routing complexity.
B - NAT66/NPt:
This is basically the same as RFC1918 (the good old 192.168.x.x addresses) the difference here between NAT66 and NPt is how ports are handled with NAT66 you will have the same limitation as you have with IPv4 in terms of ports which is 65.536 ports per public IP, if this isn't enough you can use multiple public ips, each will give you the same number of ports, keep in mind this is the amount of concurrent connections not the number of maximum connections you can ever make, if you understand this limitation which for most home users it really isn't a concern for most cases then NAT66 is fine here, also if you run your static routes/iBGP with wireguard anything handled by your site-to-site VPNs do not count so if your home workstation is "f1:33:3:1a::55:1" and your office workstation is "f2:33:3:1a::55:1" and they're connected through site-to-site vpn then this internal connection goes through the VPN and does not count towards your port limit, if you have lots of site but they're all internally interconnected NAT66 is still plenty suitable, the other option is NPt which will translate all your internal addresses to the external prefix, this however assumes you have a prefix which to many may seem like an obvious assumption right? surely every ISP that supports IPv6 will just give you at least an /64 you can delegate to your network with all ports open, surely right? no..
for NPt it will translate the 'right side' of the :: (separator) to the left side so using the example from earlier:
Example Internal IPv6 = f1:33:3:1a::1:2:3:4a/64
Example External IPv6 Network = 2001:4860:4860::/64
Example NPt Translated Address: 2001:4860:4860::1:2:3:4a/64
In Germany for instance if you call Vodafone and ask for bridged mode you will get 1x public IPv4 (not a given in this day and age.. sometimes you're stuck with CGNAT or even DS-Lite so I can't complain too much about them) but if you use a /128 your IPv6 will be fully open, as in you can route services but a /64 prefix will not be open ports, this can be on purpose to mitigate some of the problems mentioned earlier since home users are not expected to know how to design/handle their networks and they decided to silently block "all"/most incoming ports by default was a good enough solution to reduce botnets and compromised systems, by having NAT66 on your network you actually have all 65.536 ports available to you but only if you use /128 on the WAN side (single IPv6) and NAT66 so obviously here NAT66 is a no-brainer, but if your ISP allows you to use your prefix you might also consider NPt.
I have also a tutorial on how to do that for pfsense on the pfsense forums so here I will only focus on OPNsense even though it's mostly similar:
3 -- How to do that in OPNsense:
- Go to Firewall > NAT > Outbound
- Change NAT Mode to Hybrid then Save/Apply Changes.
- Add a New Map Rule as follows:
--------
Interface: WAN
TCP/IP Version: IPv6
Protocol: Any
Source Address: LAN net [or manually set the network with 'Single host or Network' if desired eg. f1:33:3:1a::/64 (this is the example from earlier)]
Translation: WAN Address (or the respective WAN interface)
Description: "F--- IANA BS I have NAT66 and I am Free" or something else of your preference
--------
- Save and Apply Changes
4 -- Additional but important things:
IPv6 handles things a little differently you have RA (Router Advertisement) and DHCPv6, DHCPv6 is a little more nerfed compared to IPv4 with fewer options but it's much of the same idea, RA works along with DHCPv6 but it assigns addresses on in a different manner to DHCPv6 you should have both enabled, some devices do not support DHCPv6 and some will take addresses from either or both you have plenty of addresses it's not a problem, it is very common for a device with IPv6 to have multiple addresses assigned to it so don't be alarmed if you see literally a single nic with 5 IPv6 addresses depending on how your network runs, I personally manage my networks with a separate DNS/DHCP server solution you can also do that which will give you way more control over things or if you want to stick to running those on OPNsense directly you can do the following:
- Go to Services > Router Advertisements:
--------
Router Advertisements: Assisted (if you have a DHCPv6 server which you should ideally this is the correct mode)
Router Priority: High
Advertise Routes: Prefix:: f1:33:3:1a:: Length:: /64 (this is the example from earlier)
DNS Servers:
1 -- f1:33:3:1a::111:1/64 (this an example Internal IP)
2 -- f1:33:3:1a::111:2/64 (this an example Internal IP)
Domain Search List: dynamic.yournetwork.yourdomain.net (if have a domain for your location/network/whatever you can set it here just like DHCP).
--------
Save and Restart the RA Service.
Important: RA by default will assign any available address within your range, but it will not assign addresses already in use, unlike DHCP you cannot block or set a range within a network (sadly) but because it will not assign anything in use and usually really random addresses it's unlikely to cause problems but something to keep in mind if you do a lot of static addressing.
- Go to Services > ISC DHCPv6
- There are many ways to configure DHCPv6, but if you have NPt/PD you'll likely have your delegated prefix range here
- You can enable/disable the server if you have a separate more capable DHCP setup the options there should be pretty straightforward so i'll not get into details it is much the same as IPv4 except for Gateway, this is handled by RA in IPv6 instead you only assign the addresses themselves via DHCPv6, easy right?
Save and Restart the ISC DHCPv6 Server.
Since not all of the IPs within f000::/4 are considered "bogon" networks technically if OPNsense is not aware to drop any attempts to connect to an external network in these addresses it will forward to the upstream gateway, this may be desired under specific configurations but if not you may also want to create a rule to block these addresses from leaving through your WAN, that way if you accidently mistype an internal ip or due to a configuration error it is not on your local network it will also protect from the exploit of having that network reachable from your ISP side the same way you have that with RFC 1918 except since this isn't a standard configuration most routers don't know to drop these addresses so you must do that yourself, to do that it's pretty simple:
- Go to Firewall > Rules > WAN:
- Add a new Rule:
--------
Action: Block
Interface: WAN
TCP/IP Version: IPv6
Protocol: Any
Source: Any
Destination: Single Host or Network f000::/4
Description: Block internal IPv6 (f000::/4) from leaving via WAN
--------
- Save and Apply Changes
- Restart your whole network, Ping and be amazed :)
- No traffic? Check your gateway settings and other rules conflicting.
- What about NAT64? That's for something else entirely and in RFC 6052 64:ff9b::/96 was assigned for that use case but this is not to be confused with NAT66 these are entirely different uses and it's beyond this tutorial.
I will also make a tutorial about multi-site vpn someday but goes without saying that by having these internal ipv6s you can obviously configure site-to-site encrypted tunnels and pretty much interconnect everything everywhere you can ping your office your datacentres everything directly using encrypted tunnels the possibilities are endless all it needs is a different left side of the /64 separator for each location and you're all set, tunnel + static routes or iBGP and your whole intranet cyberspace is here.
Just letting people know i made a little mistake here while writing the tutorial it's actually:
Source: Any
Destination: Single Host or Network f000::/4
Already edited but in case you followed it and didn't catch it you might want to edit on your opnsense box, despite being quite obvious since you're trying to block destination (which in this case means f000::/4 beyond the WAN interface) not source but anyway..
I want to clarify something some people brought up to me in private that I should've made it a little more clear while the point of the tutorial is to explain how to do NAT66 and to show that IANA/IETF could've done things better in the beginning and that giving people options is important especially keeping it mind not everyone HAS a dedicated firewall on their network and that's the point i'm trying to make here the 'default' behaviour/deployments affects the masses not people like you and me with advanced knowledge of computers and networks.
Some people may have read this and think that by not using NAT66 you're immediately in danger no matter what, if you have opensense/pfsense or any competent firewall managing your network connection the default behaviour is usually to Block any incoming connection to your routed subnet ips so yes you're "safe" even though you're using external ips but this has some caveats and downsides.
- if you change that default behaviour or create a conflicting rule you're immediately exposing your network devices to the internet including those that cannot defend themselves, which brings me to the next point.
- Not all devices can manage firewalls, so obviously having a central firewall has many advantages and can be essential on most modern networks no matter the layout you use even if you literally just use IPv4 and NAT44 you can't just trust any old potentially compromised router do it's job properly and not reset itself or have a potential vulnerability.
- You have very little flexibility in terms of your networking, so now you're stuck with external ipv6 addresses on a per device basis which you do not own this is extremely important because you can route internal ips via tunnels but external ips will cause a lot of conflicts unless you really do some static routing and isolation which is a lot of unnecessary work and even then all that for an IP prefix you most likely don't own. And don't forget the amount of flexibility you get having your entire f000::/4 subnet, 8 hextets to play with.
- Lack of segmentation, I can have many many entirely separate internal subnets which some can and some can't communicate to each other for many reasons but you can certainly have full separation between your IoT network, your Guest network, your Security network your personal Network and many others by using internal addresses.
- You have nothing to lose, the argument over having a single IPv6 only applies on cases where this is restricted by the ISP or you prefer that for maximum control over your prefixes and whatnot, NPt (Network Prefix Translation) handles the 1:1 NAT per IP seamlessly and each internal ip gets it's equivalent external ipv6 and you can have the same experience albeit with a single prefix and single internal subnet. Though you can still create other internal gateways and route the other less important devices using just regular NAT66 over a single ipv6 this would be a hybrid configuration.
- I'm not against having public ips nor am saying that you're immediately in danger if you use them (when you do have a proper firewall in between) but i'm against people being told there is no other way and that public ips are the best way to do it and that mindset has to change if IPv6 is to truly replace IPv4 otherwise people will keep using IPv4 forever anyway and the whole point of IPv6 is gone.
The whole point of IPv6 is that NAT must die. It breaks the end to end principle upon which the Internet was built and there already are lots of applications giving firewall admins headaches because of NAT - FTP (ok, deserves to die, too), VoIP, ...
Quote from: Patrick M. Hausen on September 19, 2025, 08:10:33 AMThe whole point of IPv6 is that NAT must die. It breaks the end to end principle upon which the Internet was built and there already are lots of applications giving firewall admins headaches because of NAT - FTP (ok, deserves to die, too), VoIP, ...
The whole point of IPv6 is to be better than IPv4 at the stack level curtailing that whole IP shortage problem we had and also allow for so many more addresses to the point we have enough not to worry about that for a long time.
I appreciate your opinion everyone has their own and (ideally at least) the right to it, their personal perspective can be quite hard to understand without more information and insight on what they value, think and need so please don't take this personally.
I however absolutely disagree with your statement, NAT has many use cases, all of my networks are properly segmented, most have site to site Intranets with iBGP it's absolutely beautiful and nothing goes to the public internet Unencrypted as it should be in fact the default for the world by 2025.
The internet is hostile, some oppressive jurisdictions nowadays thinking they have a say on what people do and what they should have access to it's utterly ridiculous for them to think they can control the internet and private subnets are extremely important for privacy reasons and many others.
But technology as a whole does not have to die, science is about discovery and evolution you don't have to destroy things just because you don't personally use them, not everyone has to use, not even every deployment necessarily needs or benefits from it and if it doesn't suit them it doesn't make any difference to them but it may make a whole lot of difference to someone who uses it and needs it, technology is for everyone not for the few that have a say in the matter and that's the core of the problem.
For example, I dislike 2 wheels for a choice in vehicle, but some people like them and for their personal needs can make perfect sense, but I don't like it so I wouldn't go as far as being the full Jeremy Clarkson and ban everything with less than 4 wheels just because I don't care or I don't use or I don't see the point of it.
I have never seen a single case of NAT66 or NAT44 breaking any application despite hearing about that argument before, which to me sounds like people who want something to 'just work' in a world where it takes a little more than that for things to 'just work'; if an application is so poorly written it expects public ips or port forwarding I think they need to figure out their priorities in business before hating on NAT, if it is free and open source and it requires that then the user should take that into consideration before picking the application that suits their needs. NAT or no NAT won't fix bad software or software constrained by other factors.
Also there's this 'laziness' in developers and some large companies when designing certain things, take for instance game servers a common case where instead of using dedicated servers and securing their instances many companies went for P2P and expected full port forwarding which also caused many other problems over time introducing vulnerabilities and even remote code execution (see for instance the COD Modern Warfare 3 fiasco for that one). Not to mention the ones that just completely neglect their servers altogether but the user chooses to partake, is it now the fact the devs couldn't be bothered to design things properly at fault or NAT that is at fault.
If understanding the basics of how network functions is too much for a Firewall/System Admin then they shouldn't be of managing a firewall, they may cause far more harm than they're aware especially long-term; That alone is even more of a liability for themselves or the company they're working for if they don't understand how things work NAT or no NAT will not save those people from themselves so I don't see this as a valid argument either.
FTP also has many uses, many old protocols, plain http, telnet etc again not everything has to be sent over the public internet when you have a site to site encrypted tunnel or even just a point to point tunnel then why use FTPS/SSH unless you want the double encryption on purpose, if enough file transfers or low end hardware that can be a small boost in performance and saves some time setting it up so there is a scenario where even unencrypted FTP can be perfectly fine for 2025 and if opening ports and routing them is too much work for someone setting up an FTP server even if local or even disable a firewall on a private network then once again I guess they need to reassess their priorities in life and consider other options.
Even for commercial VPNs within internal networks you can setup many internal gateways a vms with even something like opnsense instances or a linux box in your private network simply change your v4 and v6 gateways on a machine and it goes out a completely different route on any device without having to run a vpn client for that and that can run 24/7 whenever you need it, the possibilities are endless and none of that may be something you care/use but there is a use and this whole attitude of "NAT must die" is why people still use RFC 1918 addresses and sometimes even disable IPv6. Don't even get me started on some commercial vpn services that simply ignore ipv6 because "too much work/nat66 is impossible".
Site to site without having to worry about gateways? S-NAT! Yes even that.. I can completely ignore gateway configs and access a machine from another country even internally. Nonsense right? who needs NAT it should clearly die :)
Imagine being able to ping every device you own on your private Intranet fully configured fully encrypted without having to worry but no instead why not promote that people should use public ips as the "only" option and nothing else is allowed :))
Why have a clean and tidy home when we can just toss everything on the floor right, or have colour eyesight when everything can be black and white.
And for the record, "Clippy wouldn't kill NAT" for those who understand the meaning.
Internal does in now way necessarily mean NAT. You can have well segregated networks across multiple locations all connected by secure VPNs and use the same GUAs the systems use to access the Internet for internal communication, too.
You could even do this back in the IPv4 days when everybody got globally routed prefixes easily.
"Internal" and "special private addresses" are not connected. "Internal" is a qualifier of your network topology and nothing more.
Quote from: Patrick M. Hausen on September 19, 2025, 01:18:34 PMInternal does in now way necessarily mean NAT. You can have well segregated networks across multiple locations all connected by secure VPNs and use the same GUAs the systems use to access the Internet for internal communication, too.
You could even do this back in the IPv4 days when everybody got globally routed prefixes easily.
"Internal" and "special private addresses" are not connected. "Internal" is a qualifier of your network topology and nothing more.
Absolutely you're right, It doesn't have to be at all, I have my SANs setup that way it even has 9014 MTU on every device, even redundant SANs at home, work and others which are not even routed or accessible beyond their respective local sites, and still dual stack on each, fa::/64 fb::/64 perfectly fine without a gateway or internet or NAT of any kind for this specific use case.
I could in theory NAT a separate such network to another more common network for convenience/separation/avoiding more iBGP routers/static routes and your example is a perfectly fine way to do it as well nothing wrong with that if the person wants it setup with a single prefix, now if i have 3 gateways 3 uplinks 3 prefixes my LAN will keep the same local addresses and i can simply change the gateway from 1 to 2 or 3 on any local device and everything is as predictable or I can manage two separate networks my internal DNS server resolves any local resource where it's supposed to be everyone is happy, I don't see the reason why I need to do two Internal + GUA for my LAN but both are perfectly valid use cases.
I also like using isolated internal networks for IoT they have no business going to the internet either, Matter always uses the fd:: ULAs + a non standard f000::/4 subnet for everything else works fine and truly isolated.
Bridging between subnets with NAT by port forwarding or NAT 1:1 can sometimes be easier than routing entire subnets eg if I have a website on my internal network that I self host or a DB server or a linux mirror resource which i want the guest network to also have access to it though an internal domain, a 'bridge' between LAN and Guest using simple NAT66 can make that resource available on that side without having to route entire networks or go 'above' via the internet and it will still benefit both sides.
I love having options, more the better (It's why I'm not straight or monogamous) and why I want RISC-V to succeed :)
So Yes, (Internal + GUA) it can also be done that way if preferred but there is no actual factual necessity under normal circumstances, NAT66 can combine both and simplify addressing + internal routing with iBGP/OSPF which will be predictable subnets and more hextets to make it clear just by looking at the address where it is what it's for etc 2+2 vs 2x2 situation but one is better than the other depending on your preferences and personal needs, and don't forget Internal DNS servers.