Technical Tip: FortiOS v7.0.1+ does not support NAT46/64 with multiple VRFs
| 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) |

