Wrong peer gateway for decrypted packet (VPN Error code 01)

I have come across one more issue in checkpoint...i have configured 2 vpn for one of our client for 2 different location with similar lan ips. they are able to connect through one tunnel, but when they try to connect through another tunnel iam getting this error " Wrong peer gateway for decrypted packet (VPN Error code 01)".

hi tim thanks ..i can see the overlapping encryption domain after executing this command ..but how to get rid of this as customer is using same lan ip range on both side of the vpn tunnel and has refused to nat his network

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)

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: