FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
pjang
Staff & Editor
Staff & Editor
Article Id 400175
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:

  • Source/ingress interface.
  • naf.<vdom>.
  • Destination/egress interface.

 

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."
id=65308 trace_id=95 func=resolve_ip6_tuple line=5474 msg="allocate a new session-00bce0b9"
id=65308 trace_id=95 func=get_new_addr6 line=1474 msg="find NAT: IP-::, port-0(fixed port)"
id=65308 trace_id=95 func=get_vip64_addr line=1401 msg="find DNAT64: IP-4.2.2.2, port-8(fixed port)"
id=65308 trace_id=95 func=__ip6_session_run_tuple line=2968 msg="DNAT 64:ff9b::402:202:128->64:ff9b::402:202:409"
id=65308 trace_id=95 func=fw6_pre_route_handler line=144 msg="VIP-64:ff9b::402:202:409, outdev-unknown"
id=65308 trace_id=95 func=ip6_route_input line=2208 msg="find a route: gw-:: via root err -22 flags 40200200"

 

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."
id=65308 trace_id=97 func=resolve_ip6_tuple line=5474 msg="allocate a new session-00bce67f"
id=65308 trace_id=97 func=get_new_addr6 line=1474 msg="find NAT: IP-::, port-0(fixed port)"
id=65308 trace_id=97 func=get_vip64_addr line=1401 msg="find DNAT64: IP-4.2.2.2, port-8(fixed port)"
id=65308 trace_id=97 func=__ip6_session_run_tuple line=2968 msg="DNAT 64:ff9b::402:202:128->64:ff9b::402:202:7796"
id=65308 trace_id=97 func=fw6_pre_route_handler line=144 msg="VIP-64:ff9b::402:202:7796, outdev-unknown"
id=65308 trace_id=97 func=ip6_route_input line=2208 msg="find a route: gw-:: via naf.root err 0 flags 40000001"
id=65308 trace_id=97 func=fw6_forward_handler line=585 msg="Check policy between port2 -> naf.root"
id=65308 trace_id=97 func=get_new_addr64 line=1336 msg="find SNAT64: IP-100.64.0.1(from IPPOOL), port-7796"
id=65308 trace_id=97 func=fw6_forward_handler line=721 msg="Allowed by Policy-1: SNAT"
id=65308 trace_id=97 func=ip6_nat_af_input line=299 msg="nat64 ipv6 received a packet proto=58"
id=65308 trace_id=97 func=init_ip_session_common line=6401 msg="allocate a new session-00638dbf"
id=65308 trace_id=97 func=__vf_ip_route_input_rcu line=2116 msg="find a route: flag=00000000 gw-100.64.0.254 via port1"
id=65308 trace_id=97 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=51, len=3"
id=65308 trace_id=97 func=fw_forward_handler line=1013 msg="Allowed by Policy-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.

 

NAT64_VDOM.png

 

Related article:

Technical Tip: Configuring NAT46/NAT64 with NGFW Policy-Mode enabled (FortiOS 7.0.1 and later)

Contributors