topic Re: FMC managed FTD HA pairs running 7.0.1.1 TCP issues in Network Security

FMC managed FTD HA pairs running 7.0.1.1 TCP issues

andrew.butterworth — Wed, 29 Jun 2022 18:28:23 GMT

I'm looking at an issue with some FMC managed FPR 4115's in HA pairs, all running 7.0.1.1. The FMC is also managing other FPR 4115's & 4112s.

The FPR 4115's currently have just an inside & an outside interface (port-channels). The layer-3 interfaces are 802.1q sub-interfaces, but currently there is just one sub-interface per port-channel. Behind the inside interface is a link into an ACI environment with eBGP connections to the spine switches over the same VLAN. Outside is a connection to a C9500 switch, again with an eBGP peering configured. There is more to the network as its a highly resilient design, however we've stripped it back to a single path in and out of ACI through this FTD.

MTU's are configured as 9100 everywhere, however all the hosts are standard 1500-byte.

There is a simple policy currently applied that permits various access to some servers deployed in ACI (only a handful at the moment). There is no NAT configured. We've hit an issue with TCP flows that looks like asymmetric routing, however we've stripped everything back now and we are still seeing the same issue. As a workaround we have enabled TCP bypass for selected flows with an Extended ACL and a pre-filter policy to 'fastpath' the connections.

This shouldn't be happening though - there is no asymmetry as we've stripped it back so its one (HA pair) firewall with an inside interface and an outside interface, eBGP to directly connected peers either side and a simple policy.

The symptoms we see without TCP Bypass configured are a normal TCP 3-way handshake and then it all falls apart just after that. I can SSH to a Linux host, successfully login and the welcome screen appears, however press the return key seven times or type a couple of characters and it locks up.

I fear this is something incredibly obvious, however we've been looking at it for 2-days now.

Re: FMC managed FTD HA pairs running 7.0.1.1 TCP issues

MHM Cisco World — Wed, 29 Jun 2022 21:04:21 GMT

https://www.thepacket.net/asaha/

need stat-full TCP for HTTP.

Re: FMC managed FTD HA pairs running 7.0.1.1 TCP issues

andrew.butterworth — Wed, 29 Jun 2022 21:16:07 GMT

Its any TCP connections. We don't have any HTTP/HTTPS traffic allowed. Testing with RDP & SSH shows the same behaviour. It looks like an asymmetric path issue, however there is only one path into and out of the ACI environment where the servers are. Its the enabling TCP bypass that is doing me in - its there for asymmetric path issues and we don't have one. I can't understand why that fixes it. We have taken packet captures on the originating device (RDP client), on the C9500 and on the FTD. When it doesn't work the FTD appears to show missing packets, however if we enable TCP bypass for the TCP flows it all kicks into life.

Re: FMC managed FTD HA pairs running 7.0.1.1 TCP issues

MHM Cisco World — Wed, 29 Jun 2022 22:00:51 GMT

asymmetric path in HA
OK, since this is active-standby so
INSIDE of both ASA must share same subnet and Default GW in client connect to Inside must be point to Active Inside IP address

Outside of both ASA must share same subnet and the L3 device connect to outside will point to active Outside IP.

here I think you config Outside with two different Subnet and L3 device use load share and hence asymmetric and hence TCP failed (or slow).

Re: FMC managed FTD HA pairs running 7.0.1.1 TCP issues

andrew.butterworth — Wed, 29 Jun 2022 23:52:54 GMT

HA is configured and working correctly - there is L2 adjacency between all interfaces and the HA/state interface is directly connected between the two devices.

What you replied with is nonsense. HA wouldn't have established if any of the interfaces weren't L2 adjacent.

Please only reply if you have valid suggestions.

Re: FMC managed FTD HA pairs running 7.0.1.1 TCP issues

MHM Cisco World — Thu, 30 Jun 2022 00:12:53 GMT

from cisco doc.

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118050-config-bgp-00.html#anc7

""-Only the Active unit listens on TCP port 179 for BGP connections from peers.

-The Standby unit does not participate in BGP peering, and hence does not listen on TCP port 179 and does not maintain the BGP tables.""

if for any reason see the standby establish eBGP session with C9500 or ACI then your config is wrong and you get asymmetric routing.

anyway good luck with your issue