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

SNAT doesn't work when incomming/outgoing interface is the same

Hi

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 

3 REPLIES 3
pgautam
Staff
Staff

 Hi @Dallustallus 

 

Thank you for posting your query.

 

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

https://community.fortinet.com/t5/FortiGate/Technical-Tip-VIP-configured-with-Any-interface/ta-p/189...

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Mapping-VIP-outbound-connections/ta-p/1934...

 

 

 

Regards
Priyanka


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

Dallustallus

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

Dale

Toshi_Esumi
SuperUser
SuperUser

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:"

 

Toshi

Labels
Top Kudoed Authors