Description
This article describes why FortiGate sends a reset to the destination in the NAT64 scenario and how to resolve the issue.
Scope
FortiOS 7.0.x and later.
Solution
Consider the scenario where the implementation is done in the cloud environment, where NAT translation from IPv6 to IPv4 must take place.
Refer to this documentation for implementation:
https://docs.fortinet.com/document/fortigate/7.0.0/new-features/157495/simplify-nat46-and-nat64-poli...
Source IPv6 : 2a02:a45c:a609:150:25c4:xxxx:yyyy:zzzz
DNAT IPv4 : 13.x.x.x
Port1 interface IP : 10.10.2.4 -> for external communication.
Debug flow will not show any error, according to this the traffic should work fine:
diag debug flow
AZ-FG-01 # id=20085 trace_id=358 func=resolve_ip6_tuple_fast line=4822 msg="vd-root:0 received a packet(proto=6, 2a02:a45c:a609:150:25c4:xxxx:yyyy:zzzz->2603:1020:
201:f::8d:443) from port1."
id=20085 trace_id=358 func=resolve_ip6_tuple line=4961 msg="allocate a new session-0011984e"
id=20085 trace_id=358 func=get_vip64_addr line=1175 msg="find DNAT64: IP-13.x.x.x, port-0(fixed port)"
id=20085 trace_id=358 func=vf_ip6_route_input line=1204 msg="find a route: gw-2603:1020:xxx:y::zz via naf.root err 0 flags 01000001"
id=20085 trace_id=358 func=fw6_forward_handler line=457 msg="Check policy between port1 -> naf.root"
id=20085 trace_id=358 func=iprope6_fwd_check line=543 msg="in-[port1], out-[naf.root], skb_flags-00000040, vid-1, app_id: 0, url_cat_id: 0"
---truncated---
id=20085 trace_id=358 func=get_new_addr64 line=1111 msg="find SNAT64: IP-10.10.2.4(from IPPOOL), port-7131"
---truncated---
id=20085 trace_id=358 func=fw_forward_handler line=879 msg="Allowed by Policy-x:"
id=20085 trace_id=358 func=ids_receive line=417 msg="send to ips"
However, sniffer shows clearly that FortiGate is sending the reset to the destination:
diag sniffer packet any "host <source IPv6> or host <destination IPv4> " 4 0 l
diag sniffer packet any "host 2a02:a45c:a609:150:25c4:xxxx:yyyy:zzzz or host 13.x.x.x" 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[host 2a02:a45c:a609:150:25c4:xxxx:yyyy:zzzz or host 13.x.x.x]
2023-05-30 19:37:27.991931 port1 in 2a02:a45c:a609:150:25c4:xxxx:yyyy:zzzz.49750 -> 2603:1020:xxx:y::zz.443: syn 1509734508 [flowlabel 0xe0800]
2023-05-30 19:37:27.991985 naf.root out 2a02:a45c:a609:150:25c4:xxxx:yyyy:zzzz.49750 -> 2603:1020:xxx:y::zz.443: syn 1509734508 [flowlabel 0xe0800]
2023-05-30 19:37:27.991991 naf.root in 10.10.2.4.63440 -> 13.x.x.x.443: syn 1509734508
2023-05-30 19:37:27.992472 port1 out 10.10.2.4.63440 -> 13.x.x.x.443: syn 1509734508
2023-05-30 19:37:27.992486 sriovslv0 out 10.10.2.4.63440 -> 13.x.x.x.443: syn 1509734508
2023-05-30 19:37:27.999862 port1 in 13.x.x.x.443 -> 10.10.2.4.63440: syn 3454839906 ack 1509734509
2023-05-30 19:37:27.999891 port1 out 10.10.2.4.63440 -> 13.x.x.x.443: rst 1509734509
2023-05-30 19:37:27.999894 sriovslv0 out 10.10.2.4.63440 -> 13.x.x.x.443: rst 1509734509
Prior to FortiOS 7.0.x, it will just work fine.
The solution is to replace the IP assigned to the FortiGate interface 10.10.2.4 with the IP that is not assigned to any FortiGate interface, but still in the same subnet, for example, 10.10.2.5 or 10.10.2.6. Be assured that the NAT device before FortiGate is aware that this IP should be routed back to FortiGate.
