When SDF is enabled, an additional hash is applied to each sync'ed connection table entry indicating which cluster member should handle all packets associated with that connection in both the forward and return direction. You can see a passing reference to this here: sk65133: Connections Table Format
This extra hash ensures the same cluster member always handles all packets associated with a connection. In a Load Sharing scenario asymmetric handling of packets associated with a single connection is not the end of the world, but will cause a slight delay upon new connection initiation. An example of how a Load Sharing cluster successfully deals with asymmetrically handled traffic is Flush and ACK: sk100226: Cluster Flush and Ack (FnA) mechinism support for ICMP
While workarounds like FnA can be used with most types of traffic asymmetrically traversing a Load Sharing cluster, certain connections/tunnels that "terminate" at the firewall itself pose a special problem which SDF is designed to solve. At its most basic level, there can be a race condition between Load Sharing cluster members in which asymmetric return traffic for a new connection "outruns" the state sync update between cluster members. When an outrun occurs SDF ensures the packet is always handled by the same cluster member and not dropped.
I'd speculate that SecureXL cannot be used at all with SDF for at least one of the following reasons:
1) SecureXL does not support the additional SDF hash info in its separately-maintained connections table (i.e. fwaccel conns)
2) There is a chance of a race condition "outrun" in the notification mechanism between the "main" connections state table in INSPECT/F2F and the SecureXL connections table on the same cluster member.
3) SecureXL separately calculates its own tables on each cluster member; these SecureXL tables are not directly sync'ed between cluster members
Just to be clear when I use the term "race condition" in this context I mean a traffic handling problem and NOT a security vulnerability; felt the need to throw that in there due to all the Meltdown/Spectre hand-wringing.
Edit: SDF is gone in R80.20+ with the rework of SecureXL, and been replaced with the "Cluster Correction Layer" mechanism which is fully compatible with SecureXL as described here: sk169154: Asymmetric Connections in ClusterXL R80.20 and Higher
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
Updated 2023 IPS/AV/ABOT R81.20 Course now
available at maxpowerfirewalls.com