Connection timeout issues after migrating from ASA to FTD

[Chess Norris]

Hello,

After migrating from ASA to FTD (version 7.0.1), we discover an issue with connections being dropped. We started to get complains from remote workers using RDP to connect to their local workstations.

Looking in the FTD log and searching for the remote workers IP addresses, we saw a large number of similar log messages.

May 23 2022 08:04:52: %FTD-6-106015: Deny TCP (no connection) from 10.199.254.158/52575 to 10.199.6.130/3389 flags PSH ACK on interface Client_Net

After some more investigations, we saw that the connections were dropped after exactly one hour, which is the default connection timeout value. Changing this value to 10 hours fixed the issue, but we used the same default timeout value in the ASA without any conenction issues, so I am wondering if someting has changed regarding timeouts in FTD vs ASA?

Also this message about Deny TCP (no connection). Could this message really be related to connection timeouts?

Thanks

/Chess

[MHM Cisco World]

There are two Inspection

global with default idle tcp timeout 1 hr

and there is specific inspection for specific traffic,

here you can config tcp timeout as much as you want,

check this point I think when you migrate from asa to FTD you not config RDP tcp traffic inspection.

[Chess Norris]

@MHM Cisco World I just checked and the inspection are the same on the ASA and the FTD. I think it's the default ones.

policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
inspect icmp error
class class-default

/Chess

[MHM Cisco World]

Explanation The Firepower Threat Defense device discarded a TCP packet that has no associated connection in the Firepower Threat Defense connection table. The Firepower Threat Defense device looks for a SYN flag in the packet, which indicates a request to establish a new connection. If the SYN flag is not set, and there is no existing connection, the Firepower Threat Defense device discards the packet.

timeout conn<- are this same for ASA and FTD ?
idle connection timeout <- are this same for ASA and FTD?

if they same then there is BUG, I will take look and find bug for teardown connection.

[Jonatan Jonasson · Accepted solution]

Hi,

Do you have any SSL policies configured, or a captive portal for identity?

If so, you may be running into a bug in 7.0.1, CSCvz55395 ("TCP connections are cleared after configured idle-timeout even though traffic is present"), where the TCP idle timer works as an absolute timer instead of idle timer.

This is supposedly fixed in 7.1.0 / 7.0.2

The Deny TCP log message you see is just the client trying to send an packets after the firewall has torn down the session, and the packet is denied since there's no session associated anymore.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvz55395

[Chess Norris]

There is no SSL policy configured. However, when checking the bug that you linked to, I found that this bug could also be triggered by having the TLS Server Identity Discovery/Early application detection and URL categorization enabled and this was in fact enabled. I will disable it for now and see if that helps.

Thanks

/Chess

[MHM Cisco World]

so after disable the issue is solved ?

[Chess Norris]

It's probably a bit early to say, because the issue happened at random and . At least I no longer see connections with an idle time over 1 hour.

/Chess

[jbeach44]

We are also having this same issue, though in our situation we upgraded our 2110's from 6.7.0 to 7.0.1. Our remote workers connecting in from Citrix are reporting "blips" in their connections every hour. We also do not have an SSL policy enabled/configured but DID have the TLS Server Identity Discovery/Early application detection and URL categorization enabled. I just disabled this and deployed, so I am anxious to hear if your issue has been resolved, otherwise we are upgrading to 7.0.2. 

[jbeach44]

Well I am happy to report that disabling TLS Server Identity Discovery/Early application detection and URL categorization fixed our issue. We have gone a whole day without disconnects or drops. 

Thanks!

[Chess Norris]

No disconnects here either after disabling the TLS Server Identity Discovery. I have now changed the connection timeout back to the default value of one hour.

/Chess