Yep, this is the only solution I could think of. What is the equivalent fix on CheckPoint?Ĭhange the main address on the gateway object to the public IP address Identity local address MY.EXTERNAL.IP.ADDRESS Match identity remote address .ADDRESS 255.255.255.255 Match address local interface GigabitEthernet1 On a Cisco Router, you'd correct by entering your public IP in the IKEv2 profile: crypto ikev2 profile IKEV2_PROFILE This is a pretty common issue with IKEv2 when one side is behind NAT. The problem is private IPs are being sent in the IKEv2 ID field, rather than public. The last one was suggested by CheckPoint Tier 3 support because he concluded that the CheckPoint was trying to use FQDN authentication, which it is not. Set ckp_regedit -a SOFTWARE/CheckPoint/VPN1 BestRoutingSenderIP True.Set IPsec VPN -> Link Selection -> Source IP address -> Manual -> IP address of chosen interface.
Route-based VPNs then work fine, but Policy-Based VPNs only work when the other side initiates the tunnel. With IKEv2, the other side needs to be set to accept the main/mgmt IP in as the ID in order for the IKEv2 SA to come up. The External NIC of course has an external/public IP assigned which is used to configure IPSec site-to-site tunnels. We're using the CloudGuard IaaS R80.40 standalone gateways in Google Cloud, deployed with 3 NICs: (external, main/mgmt, internal). So I've had a case open for 3 months now and it's been escalated with CheckPoint Tier 3 support, still no resolution and I'm suspecting this is a design flaw or product shortcoming.
0 kommentar(er)
