SNAT doesn't work when incomming/outgoing interface is the same
Sorry to bother but I have been struggling with a policy on a 100F.
In essence, I have a device say 10.10.10.100 and it is trying to access 192.168.1.100. The destination address has a next hop to 10.10.10.200 so the incomming and outgoing of the packet is on the same interface.
However I need to nat 10.10.10.100 to 192.168.100.100, so that 192.168.1.100 would see traffic from 192.168.100.100.
This does not work at all and I tried multiple variations to get it to work but the nat just doesn't work.
It is always presented as 10.10.10.100. I have virtual ip configured so initiating traffic from 192.168.1.100 to 192.168.100.100 does translate to 10.10.10.100 and traffic works as expected.
How can I make the reversal to work? Nat pool doesn't work.
Am I missing something? Any help would be appreciated
I tried to set this up in my LAB with three FGTs (60F, 40F and 60E-POE) and one Cisco SW to connect them together. The 40F is the one that has hairpin routing on the same interface.
Looks like the initial packet actually comes in the 40F but it forwards the packet without checking the policy I set up with SNAT. The flow debug output is below:
id=20085 trace_id=13 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=1, 10.10.10.98:6912->192.168.20.100:2048) tun_id=0.0.0.0 from lan2. type=8, code=0, id=6912, seq=0." id=20085 trace_id=13 func=init_ip_session_common line=6023 msg="allocate a new session-0001b2ea, tun_id=0.0.0.0" id=20085 trace_id=13 func=vf_ip_route_input_common line=2605 msg="find a route: flag=05000000 gw-10.10.10.97 via lan2"
Then after that, when the source router/FGT(60F) sees the returned packet from the 40F toward the destination router (60E-POE), it doesn't send the subsequent packets to the 40F but directly to the 60E-POE. I observed this with Packet Capture on the 60F based on the DST MAC address of the packets.
Probably other routers might behave the same like this 60F bypassing the GW router.
So your setup probably wouldn't work for two causes: 1. if the packet comes in one physical interface and routed toward the same interface, the FGT wouldn't look up the policies.
2. the source router might bypass the GW when it sees the same packet was bounced back from the GW and sent to another router.
A similar same interface in/out policy works for SSL VPN interface (ssl.root) and I can control traffic between SSL VPN clients by the policies. Probably because it's a logical interface and no MAC address/L2 ARP resolution is involved. Flow debug out put for this situation is blow. It's looking up and found Policy-28 I created for ssl.root->ssl.root:
id=20085 trace_id=21 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=1, 172.31.254.253:1->172.31.254.252:2048) tun_id=0.0.0.0 from ssl.root. type=8, code=0, id=1, seq=5362." id=20085 trace_id=21 func=init_ip_session_common line=6023 msg="allocate a new session-007de0cb, tun_id=0.0.0.0" id=20085 trace_id=21 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-172.31.254.252 via ssl.root" id=20085 trace_id=21 func=fw_forward_handler line=881 msg="Allowed by Policy-28:"
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.