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

[SAT_S]

hey mates,

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)". 

[_Val_]

If there is an overlap through VPN domains, one side should be NAT-ed.

[SAT_S]

Yeah i have thought of the same.. thanks

[Timothy_Hall]

Yep, use the handy command "vpn overlap_encdom communities -s" to get a concise list of any VPN domain overlaps, see sk40206: Is there a way to view potentially overlapping VPN Domains? for more details.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[SAT_S]

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

[Timothy_Hall]

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.

[Houssameddine_1]

The easiest solution to have one of the sites to perform the NAT, and configure only the NATed IP as encryption domain in your config.

Thanks

[Daniel_Kavan]

Thanks for the ideas.  In my case, I had to remove the manually defined network from the old Interoperable device (the remote gw).   Even though is wasn't being used, it was still being used!  🙂

[John_Perez]

Thanks Daniel. This morning I did the same thing and it fixed my issue. I just added a dummy vpn domain in the original community just to test and it worked on the community.