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:
https://docs.fortinet.com...k-processor-offloading
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?
Thanks.
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.
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).
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?
Yes, it helps - thanks!
TIP
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 FelixPCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1735 | |
1107 | |
752 | |
447 | |
240 |
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.
Copyright 2024 Fortinet, Inc. All Rights Reserved.