Forum Discussion
NimbostratusCorrupt TCP packet not dropped by F5
One of our customers connects to us through an F5. We had an recent incident where a packet had been corrupted in transit which was sent from our Cisco ASA to their F5 (we have packet captures from before/after each hop). This particaular connection is using the FIX protocol. The packet in question had 4 FIX messages in its payload. When the F5 recieved the packet 1 of the 4 FIX messages was corrupt and the TCP Checksum did not match hence the packet was corrupt and should have been dropped. This packet was not dropped by the F5, it was forwarded to the next hop but now the TCP Checksum looked good. So when the endpoint recieved the packet the 4 FIX messages were pass up to the application and 1 of the FIX messages was Rejected due to the bad checksum. This should have not occurred, instead the TCP packet should have been dropped and subsequently retransmitted.
Is it possible that their F5 is misconfigured and is not check TCP Checksums on the packets for FIX sessions?
JC_WDN_334248Any ideas why the F5 would ignore a Bad TCP Checksum and forward the packet?
Could it be a badly written iRule?
Leonardo_SouzaCirrocumulus
Have a look in this solution:
https://support.f5.com/csp/article/K8082
If you are using a standard virtual server, yes, F5 must check the checksum. However, if you are using a virtual server with Fast L4 profile, I am not sure if it will calculate the checksum, as the handshake and TCP processing is done by the peers and not F5.
As you said the packet arrives in the F5 with bad checksum, so it can't be something F5 did.