FTD: When exactly "VPN Decrypt" (not SSL decrypt) happens in FTD traffic flow?

[muthumohan]

Its been bothering me for a while now. The flow charts on all Cisco documents show that 'VPN Decrypt' happens after checking for 'Existing Connections'. (see attached flow chart).

My question is, how will FTD know whether the connection is existing or not, even before decrypting the VPN traffic? Here I believe the 'existing connections' refers to the inner IP traffic and not to the outer IPSec header. Shouldn't VPN decrypt happen first, so that the inner IP traffic can be checked for 'existing connections'?

What am I missing?

Thank you in advance.

[MHM Cisco World]

[HQuest]

I thought the FastPath pre-filter policy bypassed DAQ entirely... ain't that the case any more?

From the Configuration and Operation of FTD Prefilter Policies (https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center/212700-configuration-and-operation-of-ftd-prefi.html

A Prefilter Policy is a feature introduced in 6.1 version and serves three main purposes:

* Match traffic based on both inner and outer headers
* Provide early Access Control which allows a flow to bypass Snort engine completely
* Work as a placeholder for Access Control Entries (ACEs) that are migrated from Adaptive Security Appliance (ASA) migration tool.

[Marvin Rhoads]

That picture was inaccurate with regard to the Fastpath and prefilter indications. This one from a Cisco Live presentation is a better reference: (UPDATE - please refer to the better diagram in my later reply.)

FTD Order of Operations

[HQuest]

Even yours doesn’t feel right. The Fastpath connection should only bypass the DAQ and nothing else. ALG checks and NAT are applied on Fastpath data - you can confirm with a packet tracer on a Prefilter policy.

It is worrisome even Cisco Live presenters are not fully understanding the product…

[MHM Cisco World]

thanks A lot friend, 
can you share the name of ciscolive PPT?

[HQuest]

I read the check for an existing connection as for the external layer.

The payload decryption should happen after an external new connection was identified as a tunnel. Meaning the FTD device is aware a connection exists, it found an internal session, it tagged it as a tunnel and it has to be decrypted (see Policies / Prefilter). You cannot start with the decryption right away, as you were just provided with the packet and you have no tracking of it. Also you don’t know yet if that header/payload is of a tunnel nor what the Prefilter is calling - perhaps it should not be and you just wasted resources. Unless they are doing something pretty funny on the device internals, to the point they won’t even document what or why.

[muthumohan]

Hello HQuest,

Thanks for your reply. Appreciate it. But still my original question remains; how you can examine the inner packet for 'existing connections' without decrypting the tunneled traffic first. I believe that the 'existing connections' we are referring to is for the inner IP connections and not on the IPSec tunnel headers. Right?

Thanks,

Mohan

[MHM Cisco World]

[muthumohan]

Hello MHM,

Thank you for your reply. So, based on your reply, here is what I conclude. Let me know if this makes sense.

The 'existing connection' here refer to both the outer IP header connections (IPSec) and inner IP connections. So, if IPsec tunnel is already established (i.e., connection existing) then the tunnel traffic can be fast-pathed, without decryption. If the tunnel connection is new (not existing), then do the VPN decrypt and pass the inner IP to the Access-Control Policy for further inspection. If ACP passes this traffic, a connection entry is added and all future IPSec packets can be fast-pathed without VPN decrypt.

[Marvin Rhoads]

I found an even better (and I believe more accurate) depiction - see below.Credit to Nazmul Rajib - it is from his book "Cisco Firepower Threat Defense" (Chapter 16). (I hope you don't mind me citing it @Nazmul Rajib)

It shows that, in case of VPN traffic, that we decrypt before checking the prefilter policy for "Fastpath Trust" action. That is distinct from taking the "Fast Path" which is an unfortunately similar choice of words for how an existing flow is handled (i.e., straight to DAQ for the Firepower Engine processing). The Cisco Live slide does indeed have an error (I believe) in where it shows the output of the prefilter Fastpath action. Nazmul's figure show the correct order - including the ALG and NAT sections.

[muthumohan]

Hi All, I kinda found the answer. In one of the ciscolive videos, I saw that, after VPN Decrypt, the inner-packet is again sent back and checked for "existing connections", this time for the inner-IP.