Encryption Failure: according to the policy the packet should not have been decrypted

[Heine_Vargas]

Hello guys 🙂

We are trying to implement a site to site VPN, and we are getting the "Encryption Failure: according to the policy the packet should not have been decrypted" error message. 

I would like to know if you have some recommendations about it, and if it's rather good to open an SR to check this, 

The details are:

Error message:

Domains:

Local domain

172.18.8.0/24

Remote Domain

172.20.1.0/24

Local and remote domains on the other company side:

Recent troubleshooting details:

1.- We checked that remote network is configured on the antispoofing interface exceptions.

2.- As showed on the latest images, domain configuration matches on both sides

3.- Configured on Gaia remote network routes:

3.1.- In fact, despite the static route, a show route destination against the remote network shows de default route (Internet) as next hop:

4.- We have tried using and inbound NAT, but error message persists either with or without NAT.

5.- Some people at work said that the remote device (A linksys small business VPN router) might be incompatible with our R80.20 Security Gateway

6.- I have followed sk64060 recommendations, but, despite I have changed in many times the remote and local subnets, verified the encryption domain configurations, and also reseted the tunnel via SmartView Monitor and the vpn tu utility, we are still getting the same error message.

Thank you in advance!

Heine

[Benedikt_Weissl · Accepted solution]

Try to get rid of all routes and NAT. Please post the output of the one liner from here https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/One-liner-to-show-VPN-topology-on...

From your Screenshots it seems to me that you used the same network group "Domino_VPN..." in your local AND the remote gateway.

[Heine_Vargas]

Hello Benedikt, first of all, thank you!

In fact, our customer in its local domain had the whole class B network from 172.16.0.0 to 172.31.255.255.

I realized of that after running the script that you gave me on your reply.

So, thank you again and sorry for not notice about the main cause of my issue.

Greetings!

[Sitarz_T]

Hi, i just ran into the same error. We have a similiar setup. We checked everything like you and found no typical error.

In our case, both CPs were centrally managed. We split a giant /16 net into multiple /24's in Site A and adjusted the routing. After re-reading the Topology in Site A(Network management -> get interfaces) , pushing the policy to the gateway, the CP in Site B had this error messages, while the CP in Site A was passing it normally.

After some time, i figured out that the CP in Site B  also needs a policy installation after editing the Topology on Site A, because otherwise it doesnt seem to match. Worth to mention, in Site A we are using the "... based on routing information" Feature for Topology and VPN Domain.

Hope it helps somebody

Cheers