Processing logic for return traffic in stateful inspection

[KenjiKang]

Hi teams

I am using a FortiGate firewall with stateful inspection enabled, and we'd like to understand the packet processing logic for return traffic.
Could you please share any information you have on this?

Specifically, I am looking for an explanation of return traffic similar to the one provided in the following URL: https://docs.fortinet.com/document/fortigate/6.0.0/parallel-path-processing-life-of-a-packet/478386/...

I am currently considering whether to address return traffic by adding a policy route or by adding a less-preferred static route. Our main question is whether the routing table is consulted at all for stateful return traffic.

Thank you 
Kenji

[AEK · Accepted solution]

Hi Kenji

The firewall checks the routing table for both request and return path. No need for policy route.

Check this tech tip and you should understand more the logic.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Reverse-Path-Forwarding-RPF-implementation...

[ebrlima · Accepted solution]

Yes,  routing table is check at the first packet starting the session and the first reply packet. 

If there's a routing change during the session ttl, the routing table is checked again to confirm if the change affects the session.

[Toshi_Esumi · Accepted solution]

You need to drop/forget your obsession "need to use policy routes". Unless you're using like a 25+ year old device or from the last century. Most of modern NGFWs handle all traffic as "sessions" or "flows", which includes initiation, returning, termination/time out. 

Unless you want/need to "initiate" a session toward a specific outgoing interface while multiple outgoing interfaces/routes for the traffic are available, you never need policy routes.
I feel like you're trying to do what those NGFWs are already taking care of at least for last 25 years or so.

Toshi

[ebrlima · Accepted solution]

@KenjiKang I understand what you are looking for, but I don't think such document exists, because return traffic will be handled differently, based on setting. You have the default behavior, the behavior with asymmetric routing enable, with auxiliary sessions enabled, with FGSP over FGCP. For the default behavior, I believe we made it clear here how it works. For other topologies and settings, you gonna have to check other docs, and if possible, I recommend execute lab testing.

[AEK · Accepted solution]

Hi Kenji

The firewall checks the routing table for both request and return path. No need for policy route.

Check this tech tip and you should understand more the logic.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Reverse-Path-Forwarding-RPF-implementation...

[ebrlima · Accepted solution]

Yes,  routing table is check at the first packet starting the session and the first reply packet. 

If there's a routing change during the session ttl, the routing table is checked again to confirm if the change affects the session.

[Toshi_Esumi · Accepted solution]

You need to drop/forget your obsession "need to use policy routes". Unless you're using like a 25+ year old device or from the last century. Most of modern NGFWs handle all traffic as "sessions" or "flows", which includes initiation, returning, termination/time out. 

Unless you want/need to "initiate" a session toward a specific outgoing interface while multiple outgoing interfaces/routes for the traffic are available, you never need policy routes.
I feel like you're trying to do what those NGFWs are already taking care of at least for last 25 years or so.

Toshi

[KenjiKang]

Thank you all for the kind advice.
You have greatly accelerated my understanding.

I have one last request. Could you please let me know if you know of any packet flow documents for return traffic?

I'm looking for a return traffic version of the packet flow explained in the following URL:

https://docs.fortinet.com/document/fortigate/6.0.0/parallel-path-processing-life-of-a-packet/478386/...

Thank you
Kenji

[ebrlima · Accepted solution]

@KenjiKang I understand what you are looking for, but I don't think such document exists, because return traffic will be handled differently, based on setting. You have the default behavior, the behavior with asymmetric routing enable, with auxiliary sessions enabled, with FGSP over FGCP. For the default behavior, I believe we made it clear here how it works. For other topologies and settings, you gonna have to check other docs, and if possible, I recommend execute lab testing.

[AEK · Accepted solution]

You may check this doc explaining routing concepts on FGT.

https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/139692/routing-concepts

Hope it helps.

[granelbo1]

Would the constant ping still be the same session? Maybe that isn't the best example. The main thing I am trying to figure out is how firewall changes are applied to existing sessions. Or in other words how existing sessions are blocked when the policy that allowed them to exist in the first place is removed.

[ebrlima]

Take a look at this documentation regarding the "dirty" flag.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dirty-session/ta-p/197748