| Description | This article describes a known limitation when attempting to perform NAT46/64 while using multiple VRFs (Virtual Routing and Forwarding) on v7.0.1+ |
| Scope | FortiGate, NAT46/NAT64 |
| Solution |
V7.0.1 and later use a new design for NAT46/64 where traffic is internally routed to a logical naf.<vdom> interface as part of the translation process (the <vdom> section is replaced with the name of the Virtual Domain/VDOM and is 'root' for non-VDOM FortiGates). The flow of NAT46/64 traffic would be as follows: Source interface -> naf.<vdom> -> Destination interface.
For more information, refer to the following new feature announcement: FortiOS 7.0 New Features - Simplify NAT46 and NAT64 policy and routing configurations
One key aspect of this design change is that there is only one naf.<vdom> interface per-VDOM. While it is possible to assign this interface to a different VRF than the default of 0, it is not possible to assign the interface to multiple VRFs. At the same time, NAT46/64 is only possible if all three of the following components are present in the same VRF:
All in all, NAT46/64 is not currently supported for multiple VRFs in a single VDOM, as the naf.<vdom> interface is required to be in the same VRF as the source/destination interfaces needing NAT46/64. Yet, it cannot be part of multiple VRFs at the same time (i.e. only a single VRF in a given VDOM will perform NAT46/64 correctly).
Example: Consider the following example, where IPv6 client 2001:db8:1234:5678::100 is sending ICMPv6 pings towards IPv4 server 4.2.2.2 (64:ff9b::402:202 being the NAT64 DNAT address). If the naf.<vdom> interface is not in the same VRF as the Source and Destination interfaces for NAT64 then the following output is observed in the FortiOS debug flow (note route-lookup failure, as there is no further output beyond that point):
id=65308 trace_id=95 func=resolve_ip6_tuple_fast line=5315 msg="vd-root:2 received a packet(proto=58, 2001:db8:1234:5678::100:409->64:ff9b::402:202:128) from port2. type=128, code=0, id=409, seq=1."
In contrast, the following output is the expected outcome when naf.<vdom> is assigned to the same VRF as the Source and Destination interfaces:
id=65308 trace_id=97 func=resolve_ip6_tuple_fast line=5315 msg="vd-root:2 received a packet(proto=58, 2001:db8:1234:5678::100:7796->64:ff9b::402:202:128) from port2. type=128, code=0, id=7796, seq=1."
Workaround: If a network requires user traffic to be segregated while also requiring NAT46 or NAT64, the current workaround is to use VDOMs instead of VRFs. Each VDOM may be assigned a pair of ingress/egress interfaces (segregating traffic even more than with VRFs in the same VDOM). The naf.<vdom> interfaces found within each VDOM may be used to perform NAT46/64 on these separated traffic flows.
Related article: Technical Tip: Configuring NAT46/NAT64 with NGFW Policy-Mode enabled (FortiOS 7.0.1 and later) |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2026 Fortinet, Inc. All Rights Reserved.