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

FortiManager Rules with Virtual IP Objects - Routing Question

Hey, In FortiManager, rules have "Incoming Interface" and "Outgoing Interface" fields, which are, among other fields, used to classify if a packet for matching a rule

While the incoming interface is naturally known as a packet enters the FW, the outgoing interface is only known after a routing lookup.


Below is the FortiGate packet processing order:


I understand that the firewall rules are processed after routing, which makes sense, because only then, the outgoing interface is known.

I also understand, based on this link, that destination NAT occurs before routing, which also makes sense, because the routing must be based on the post-NAT IP.

However, firewall policy rules with VIP objects in the "Destination Address" field, still have an "Outgoing Interface" field which can be used - but since destination NAT occurs before routing, the "Outgoing Interface" isn't known yet.

So, I wonder, is the "Outgoing Interface" field ignored (even if used) for rules with VIP objects?





I am not sure if I understood the question correctly, but in case of VIP as well there is definitely an IP address as destination (In normal scenarios it is going to be a internal/private IP ) and route lookup happens for that IP to find the outgoing interface.


Destination NAT happens 1st and as a result we get the VIP used in Policy

Route Lookup to the VIP gets the Interface used in Policy

Then the Policy lookup happens.


Feel free to correct me if I have misunderstood the question.



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

Thanks for responding.

Sure there's destination IP in the rule, it's the Virtual IP object - the question was related to outgoing interface.

In order to know the outgoing interface, there first should routing lookup, but in case of destination NAT, the NAT should occur first, for the route lookup to be on the post-NAT address - and then the outgoing interface is known.

However, in this case, the destination NAT is part of the firewall policy, which happens after routing lookup. So, there's a little problem here - in the firewall policy rule, the outgoing interface is a matching criteria, but the destination NAT needs to happen first, so that routing lookup will happen, so that the outgoing interface will be known - but how the rule with the VIP object (which is the destination NAT practically) will match, if the outgoing interface will be known only after destination NAT and routing? That's why I assume that the outgoing interface is ignored, otherwise how can the FW even match the rule to perform the destination NAT based on the VIP object. Unless the rule evaluation happens twice - once the destination is performed, ignoring the outgoing interface of the rule, and then it's evaluated for the second time based on the new IP (and then another rule on the same policy might match, but definitely not the rule with the VIP object, because the packet is already with the post-NAT destination IP).

Valued Contributor

You're overcomplicating things.  The DNAT happens before any policy evaluation is done.  If a packet comes in with a destination IP of one of the VIPs that exist on the firewall, the firewall performs DNAT to get the final IP and determine the destination interface based on routing. 


Then the policy evaluation is done and assuming you have correctly configured the destination interface of the internal IP on the VIP, the policy will match.  The firewall doesn't need to read the policy to do DNAT, DNAT happens completely beforehand.  Does that help?

New Contributor

Yes, it helps - thanks!

Esteemed Contributor III



If one would use the diag debg flow  during analysis , it will show you a clear picture of DNAT "

"fw_pre_route_handler" vrs SNAT "post_route_handler" and where the policy and route looks are


Theses two function are like 100% identical in iptables  


Ken Felix