I am working on a lab setup with an ASA later this week. I've already tried to replicate the behavior with a Cisco CSR1000v and Palo Alto VM-300, both in AWS. The first interesting thing is while there were zero issues with IKEv1 regardless of NAT-T, with IKEv2, I noticed the CheckPoint always negotiates NAT-T even if it's completely disabled on the other side. If the Cisco side has no crypto ipsec nat-transparency udp-encapsulation set in IOS or the Palo Alto has Enable NAT traversal unchecked, packet captures will show ESP from the other end (198.51.100.188) but the CheckPoint (10.10.100.4) trying to reply with NAT-T and then complain of an invalid SPI.
12:57:13.022722 IP 198.51.100.188 > 10.10.100.40: ESP(spi=0x14eec13d,seq=0x6), length 148
12:57:15.136804 IP 10.10.100.40.isakmp > 198.51.100.188.isakmp: isakmp: parent_sa ikev2_init[I]
12:57:16.102397 IP 10.10.100.40.ipsec-nat-t > 198.51.100.188.isakmp: isakmp:
12:57:17.091696 IP 198.51.100.188.isakmp > 10.10.100.40.isakmp: isakmp: child_sa inf2[I]
This sounds oddly like the behavior from sk165003 which was supposedly fixed a few months ago in R80.30 Take219 or R80.40 Take83. I'll open a case now, but not optimistic it will be productive as it's the 4th case I've opened, and TAC never even matched it to that bug.
Another funny thing: the CheckPoint is sending its main address in the IKE header, even if Link Selection -> Always Use this IP address -> Statically NATed IP and Source IP Address Settings -> Manual -> IP address of chosen interface have been configured in SmartConsole. The Palo Alto shows this quite clearly:
received ID_I (type ipaddr [10.20.30.39]) does not match peers id 02/24 09:23:48
ignoring unauthenticated notify payload (NAT_DETECTION_DESTINATION_IP) 02/24 09:23:48
ignoring unauthenticated notify payload (NAT_DETECTION_SOURCE_IP) 02/24 09:23:48
The only way to fix this is set the other side to expect the private IP in the "Identification" field. FortiGates suffer from a similar bug described here. This is probably specific to standalone gateways in GCP, since Clusters use the shared public IP as the Main IP address.
What still doesn't add up is if both sides negotiate IKEv2 and NAT-T, everything should work and I've confirmed this is the case with the CSR1000v and VM-300, whether the VPN be route-based or policy-based.