Technical Tip: NAT64 and NAT46 IP pools should not overlap with FortiGate interface IP addresses

[lsaroukhani]

Description	This article describes a known limitation of NAT64 and NAT46 IP pools: to process reply traffic correctly, the IP pool must not overlap with any device interface IP address.
Scope	FortiGate v7.
Solution	After configuring NAT64 or NAT46 as shown in FortiOS v7.4.7 Administration Guide: NAT46 and NAT64 policy and routing configurations, if the IP pool was misconfigured to use the same IP address as the outgoing interface, reply traffic will be dropped by the FortiGate. NAT64 Topology: Example NAT64 Configuration: config firewall vip6     edit "test-vip64-1"       set extip 2000:10:1:100::40       set nat66 disable       set nat64 enable       set ipv4-mappedip 192.168.15.2    next end  config firewall ippool   edit "test-ippool4-1"     set startip 192.168.15.15 <-- misconfiguration.     set endip 192.168.15.15     set nat64 enable   next end config firewall policy   edit <index>     set name "policy64-1"     set srcintf "internal2"     set dstintf "internal1"     set action accept     set nat64 enable     set srcaddr "all"     set dstaddr "all"     set srcaddr6 "all"     set dstaddr6 "test-vip64-1"     set schedule "always"     set service "ALL"     set logtraffic all     set auto-asic-offload disable     set ippool enable     set poolname "test-ippool4-1" end Diagnostics: With the above sample configuration, the client can send an echo request, but FortiGate drops the reply before NAT translation. A packet sniffer shows reply packets arriving on internal1, but they are not forwarded using naf.root:  diagnose sniffer packet any "icmp or icmp6" 4 0 l internal2 in 2000:10:1:100::42 -> 2000:10:1:100::40: icmp6: echo request seq 1 naf.root out 2000:10:1:100::42 -> 2000:10:1:100::40: icmp6: echo request seq 1 naf.root in 192.168.15.15 -> 192.168.15.2: icmp: echo request internal1 out 192.168.15.15 -> 192.168.15.2: icmp: echo request internal1 in 192.168.15.2 -> 192.168.15.15: icmp: echo reply Debug flow shows that the echo reply is routed to the root (local) interface: diagnose debug flow filter proto 1 diagnose debug flow filter addr 192.168.15.2 diagnose debug flow trace 100 diagnose debug enable id=65308 trace_id=201 func=print_pkt_detail line=5938 msg="vd-root:0 received a packet(proto=1, 192.168.15.2:62518->192.168.15.15:0) tun_id=0.0.0.0 from internal1. type=0, c ode=0, id=62518, seq=1." id=65308 trace_id=201 func=resolve_ip_tuple_fast line=6040 msg="Find an existing session, id-00e84271, reply direction" id=65308 trace_id=201 func=vf_ip_route_input_common line=2612 msg="find a route: flag=84000000 gw-192.168.15.15 via root" Resolving the issue: Adjust the ippool so that it does not overlap with the outgoing interface. config firewall ippool   edit "test-ippool4-1"     set startip 192.168.15.14      set endip 192.168.15.14     set nat64 enable   next end After this change, ICMP echo replies undergo intended reverse NAT and are forwarded back to the client. diagnose sniffer packet any "icmp or icmp6" 4 0 l internal2 in 2000:10:1:100::42 -> 2000:10:1:100::40: icmp6: echo request seq 1 naf.root out 2000:10:1:100::42 -> 2000:10:1:100::40: icmp6: echo request seq 1 naf.root in 192.168.15.14 -> 192.168.15.2: icmp: echo request internal1 out 192.168.15.14 -> 192.168.15.2: icmp: echo request internal1 in 192.168.15.2 -> 192.168.15.14: icmp: echo reply naf.root out 192.168.15.2 -> 192.168.15.14: icmp: echo reply  naf.root in 2000:10:1:100::40 -> 2000:10:1:100::42: icmp6: echo reply seq 1 internal2 out 2000:10:1:100::40 -> 2000:10:1:100::42: icmp6: echo reply seq 1