Did you ever find a solution for this? We are seeing the same thing - I think I know what is happening.
1. Remote Check Point gateway sends tunnel test packet (destination port UDP 18234) to central Check Point gateway.
2. Central Check Point gateway receives packet, and NATs destination to a different interface/IP on the central gateway (as described in sk102729).
3. Central Check Point gateway replies to the tunnel test packet, using source of NAT'd interface
4. Remote Check Point gateway receives the reply to its tunnel test packet, but from different IP address - the IP address of the NAT'd interface on the central gateway - and drops the packet.
Our logs are filled with dropped traffic with source port of UDP 18234 and destination port of random high UDP port (which correspond to source port of the original tunnel test packets).
I don't know if this is impacting anything other than my sanity and perhaps status of tunnel as shown in SmartView Monitor, but it is annoying.
Dave