Forum Discussion

JC_WDN_334248's avatar
JC_WDN_334248
Icon for Nimbostratus rankNimbostratus
Sep 21, 2017

Corrupt 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?

 

application delivery
BIG-IP
security

2 Replies

Sort By
  • JC_WDN_334248's avatar
    JC_WDN_334248
    Icon for Nimbostratus rankNimbostratus
    Sep 25, 2017

    Any ideas why the F5 would ignore a Bad TCP Checksum and forward the packet?

     

    Could it be a badly written iRule?

     

  • Leonardo_Souza's avatar
    Leonardo_Souza
    Icon for Cirrocumulus rankCirrocumulus
    Sep 25, 2017

    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.