From Checkmates: In this case the first packet of a NATted new connection C2S flow arrives at SGM1 based on the hash calculation done on the MHO, so SGM1 becomes the connection owner (starred). SGM1 runs a predictive hash calculation simulating what would happen if SGM1 itself was to fail and calculates SGM3 would then get the C2S connection, so it Hypersyncs the connection info to SGM3 (BC2S). SGM1 also runs a predictive hash calculation to determine where the return traffic will come back (S2C), and based on that Hypersyncs the connection to SGM2, who will correct the return traffic to SGM1 the connection owner for handling. SGM2 now runs a predictive hash calculation and determines that if it fails SGM4 would get the S2C return traffic, and Hypersyncs the connection info to SGM4 (BS2C). All 4 SGMs are consuming a connection table slot for the single NATted connection. All of this is in the new Maestro Expert R81.10 course offered by various ATCs, and is where the "divide connection table capacity by 4" rule came from when dealing with NATted traffic in a Maestro Security Group. So I would be tempted to say actually the correct answer is between 2 and 4.

2 for single site and 3 for dual site.

sorry meant. Single site - 2 (Active connections table and backup on another SGM). Dual site = 3

Whether NAT or not, its the connection table so for local site its 2. if dual site its 4. From CheckMates: > Each connection is synchronized to two Security Group members (Active and Backup). In case of Dual site – there’s a second Backup on Standby site > Provides guaranteed redundancy > Provides scalability for large scale deployments by reducing Sync traffic overhead