ASA FirePower - stateful or stateless

[muthumohan]

Hi,

I am trying to understand how the state information is kept in firepower module running on ASA. I know ASA is stateful and keeps track of connections and automatically allow return traffic to pass.

What about the firepower module? Does it maintain state information to allow the return traffic?

Also, in active/standby mode, I know the ASA fails over statefully, but firepower does not failover. the new firepower will start inspecting the traffic from that point onwards. If this is the case, what happens to the connections maintained in the firepower before failover? As they are not transferred to the new firepower, will the connections going via firepower will disconnect?

I could not find any Cisco document on how firepower maintains state information to process the corresponding return traffic.

Would appreciate any help. And I need some help as soon as possible.

thanks in advance,

Mohan

[Philip D'Ath]

Firepower needs to maintain huge amounts of state information about connections.  Far more than the ASA itself.  The state is not so much as to "allow" the return traffic, but for statistics and to decide what to drop.  It's tracking things like initiating users, url categories, threat risk, and a million other things.

Firepower predominantly drops traffic when there is a "definite match".  If it comes in half way through a conversation and there is no match then there is no match to act on to drop traffic.

Correct, Firepower does not mirror state to a standby unit.  On the whole, the new Firepower will simply see transactions part way through, and wont be able able to do much, so everything will just continue on.  It is just like turning the service policy on the ASA for Firepower on and off.  Everything just keeps going.

[muthumohan]

Thank you all and Thanks Philip for the details.

So, just to be sure, there will not be any impact to the user traffic during the sfr failover, right?

I write an access control policy rule to permit traffic from one subnet (10.1.1.0/24) to another subnet (172.16.1.0/24) on the sfr module. There is no explicit rule in access control rule to permit the return traffic. So, I believe, the SFR module keeps a connection table to allow (subject to IPS, file policy etc.) the return traffic. Is this correct?

If so, when the failover happens, this connection information is not available on the new sfr module. Now, if the return packet is coming through the new sfr module, will it allow this traffic to pass or drop it? This is my question.

Would appreciate any help here...

thank you,

Mohan

[Barrett Cowan]

I couldn't really find the answer, to this, in Cisco documentation either. It would be nice to know in the case of FirePower. Although, I believe in the case of FTD, there is stateful tracking of connections.

[mile.ljepojevic]

Short answer is: it doesn't. I don't think there is concept of return traffic and opening TCP/UDP ports dynamically, especially for example if you allow SIP from INSIDE TO OUTSIDE, you will have to allow return traffic as well (you can't just put first rule to be "DENY OUTSIDE TO INSIDE" it will block all the traffic coming in).

[Massimo Baschieri]

Old firewalls had ALG's, which inspected some applications in order to cope with asymmetric protocols.

Firepower natively inspects all applications, so why it doesn't have to be stateful and it doesn't have to behave like old ALG's?

Firepower network analysis policy seems there to rule exactly that behaviour.