You can double-NAT on one side of the tunnel to avoid any NAT whatsoever on the other side when an IP overlap is present, but it is difficult to set up and will involve configuring policy-based routing (PBR) and messing around with antispoofing to make it work with NAT. Let me illustrate, let's assume you are Site A and it initiates connections to Site B through the VPN tunnel, here is the setup:
Site A:
internal network 192.168.1.0/24, interface eth0
external network (some ISP routable block), interface eth1
NAT overlay network: 172.16.1.0/24 (This is a made-up network that does not exist anywhere in Site A's internal network and does not conflict)
Site A FW VPN Domain setting: 192.168.1.0/24, 172.16.1.0/24
Site B FW Externally Managed Gateway/Interoperable Device VPN Domain setting: 172.17.1.0/24
Network Policy Rule:
Source: 192.168.1.0/24
Dest: 172.17.1.0/24
Service: whatever
Action: Accept
Manual Static NAT (mask lengths much match precisely between Original & Translated fields or you will get a NAT verification error):
Orig Source: 192.168.1.0/24
Orig Dest: 172.17.1.0/24
Orig Service: Any
Translated Source: 172.16.1.0/24 (Static)
Translated Destination: 192.168.1.0/24 (Static)
PBR Policy Rule on FWA:
Source: 192.168.1.0/24
and
Destination: 192.168.1.0/24
PBR Next Hop: Internet GW, interface eth1
To reach systems at Site B through the VPN tunnel, users at site A must attempt to connect to the host at Site B's overlay IP address. So if the Site B system to be reached is 192.168.1.222, user at site A must attempt the connection to a destination IP of 172.17.1.222.
Site B:
network 192.168.1.0/24
NAT overlay network: 172.17.1.0/24 (This is a made-up network that does not exist anywhere in Site B's internal network and does not conflict)
Site B must be expecting traffic to arrive in the tunnel from Site A sourced from 172.16.1.0/24
You will also probably have to define some antispoofing exceptions on the Site A firewall to make this work. SecureXL also sometimes doesn't play nice with PBR based on your firewall version, you may need to manually turn on PBR support in SecureXL:
sk109741: Packets are not routed correctly when PBR is configured and SecureXL is enabled
This is from memory so I may be off on a detail or two but hopefully you get the idea. Not simple.
--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.
Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com