Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
New Contributor II

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 and it is trying to access The destination address has a next hop to so the incomming and outgoing of the packet is on the same interface.

However I need to nat to, so that would see traffic from

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 I have virtual  ip configured so initiating traffic from to does translate to 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 


 Hi @Dallustallus 


Thank you for posting your query.


Please check the below link for the VIP and SNAT behavior. It might help you.





- Have you found a solution? Then give your helper a "Kudos" and mark the solution


Hi Priyanka,


Hank you for your response. To be honest the links you've provided hasn't made a lot of sense to me. I am very much new on Fortinet and this is my first replacement from Cisco ASA.


Am I to understand that if I have VIP and I enable nat-source-ip, I would assume I would only need to configure policy based on the VIP address and without NAT configured?


Sorry if I sound amateur with this, as I say I am very new to Fortinet and out of everything I needed to convert from ASA is done except for this


Many thanks



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,> tun_id= 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="
id=20085 trace_id=13 func=vf_ip_route_input_common line=2605 msg="find a route: flag=05000000 gw- 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,> tun_id= 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="
id=20085 trace_id=21 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw- via ssl.root"
id=20085 trace_id=21 func=fw_forward_handler line=881 msg="Allowed by Policy-28:"




Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Top Kudoed Authors