Fortinet has a misstep in its IPv6 settings: NAT66 is enabled by default for every policy. Not only does this make no technical sense and go against established best practices, but in my view, there’s an even bigger issue at play here:

Given the widespread use of FortiGate devices and the still limited level of IPv6 expertise among many administrators, this default setting risks creating false knowledge. Many admins may come away believing that NAT for IPv6 is just as normal as it is for IPv4 – after all, it’s enabled out of the box. And as with any default, people will quickly get used to it.

In this blog post, I’ll therefore look at a few practical workarounds to move away from this approach as quickly as possible.

Problem Description

This default configuration is fundamentally at odds with what IPv6 is meant to be – essentially the exact opposite of NAT. To recap: NAT was a workaround for IPv4, specifically to deal with address exhaustion and allow continued internet connectivity despite limited address space. The goal of IPv6, in contrast, was to restore true end-to-end connectivity at Layer 3: globally unique, routable IP addresses, with no need for NAT. (Yes, there are edge cases where NPTv6 – Network Prefix Translation – can be used appropriately.)

A single policy for IPv4 and IPv6 (“consolidated policy”) only has a single NAT switch. While this is mandatory for IPv4 to function for almost all outgoing connections, it also enables NAT66 for the same source/destination IPv6 addresses:

A forward traffic log then looks like this:

From a configuration perspective, the problem lies in the set nat enable CLI command, which does not distinguish between legacy IP and IPv6 (as the CLI *does* distinguish between both IPs when it comes to the src/dst addresses, which is not a good design as well, by the way):

Lastly tested with a FortiGate 70F and FortiOS v7.6.6. However, this topic has been around for several FortiOS releases. I first reported it in 2017, almost 10 years ago. Unfortunately, nothing has changed since then.

Workaround 1: Central NAT

From an architect’s perspective, the central NAT is a very good option. Not only for IPv6, but also for IPv4. Why? Because it separates the network/routing layer (NAT or not) from the security layer (policy allow or deny). If you have hundreds of outgoing policies, there’s no need to have hundreds of “nat enable” switches. One NAT policy per direction fits completely, e.g.: internal -> Internet: SNAT.

Since such NAT policies are configured only for IPv4, no IPv6 NAT would be applied within the same rule. 👍🏻

Enabling Central SNAT:

Or via CLI:

Building the needed outgoing SNAT policies for legacy IP (note the IPv4 selection at the top):

Your policies will then show a “Custom” in the NAT column:

Outgoing IPv6 sessions will have no NAT anymore. ✅

Workaround 2: Independent Policies for IPv4 and IPv6

As an alternative, you can split each dual-stack policy into two policies: one for IPv4 (with NAT) and one for IPv6 (without NAT). While this will work, it obviously doubles the number of policy entries, which is, unfortunately, a really bad design as well. You’ll end up with two policy sets – one covering IPv4, the other one covering IPv6 – which won’t be congruent in your daily work. This eventually leads to more security holes in your overall policy, since you will forget one or the other.

However, technically, you would migrate from this:

to that:

Workaround 3: Different Device

I don’t know whether this is a sensible workaround or not. I also don’t want to engage in unnecessary bashing here. Still, I wonder how much you can trust a product if it already gets the most basic things completely wrong. To me, it’s more than just a slightly uneasy feeling – it’s fundamental.

Another concern is the fact that Fortinet has been aware of this issue for years, yet hasn’t made any meaningful changes. And yes, I am fully aware that FortiGate is one of the most widely deployed firewall platforms, and that this topic “only” touches the networking fundamentals rather than the security features themselves.

Even so, it raises serious questions. When customers ask me in my IPv6 workshops today which product they should choose for a new deployment, I simply cannot recommend FortiGate in good conscience. And that’s not solely because of this NAT issue – there are other IPv6-related shortcomings as well. (E.g., no address groups for v4/v6 addresses at the same time; DNS64 only globally enabled with “always-synthesize-aaaa” enabled by default; NAT64 only possible with “IP Pool” and not “outgoing interface address”; NAT46 not available with Central NAT; OSPFv3/BGP only through CLI.)

What would you do?

@Fortinet: Please fix this 🙏

Fortinet, if you’re reading this: Please reconsider this default behaviour. Please align your IPv6 implementation with the fundamental design principles of the protocol and disable NAT66 by default. This is not a minor detail – it directly shapes how administrators understand and deploy IPv6 in real-world networks. By correcting this, you would not only improve your product but also help prevent the continued spread of misconceptions around IPv6.

At the same time, I would encourage everyone reading this to raise awareness of the issue. If you are working with FortiGate devices or considering them, please reach out to Fortinet – through your account teams, support channels, or public forums – and make your voice heard. Vendor defaults matter, and change is far more likely when customers clearly and collectively highlight where improvements are needed.

Soli Deo Gloria!

Photo by Vitaly Gariev on Unsplash.