VPN Draytek policy rule

[giulitn]

Hi,
I have set up a VPN between a cluster of VPN-1 NGx rR61 with a Draytek router Vigor 2820 (firmware latest 3.3.3).
The VPN is up accoridng with several information I have found on the net but the traffic is not routerd into the VPN.
If I ping from one lan to the main LAN in the headquarter the answer is:
encryption failure: According to the policy the packet should not have been decrypted

Any idea?
Thanks,
bye

[mcnallym]

In the checkpoint interoperable object does the encryption domain behind the draytek gateway overlap with a network at the main office ?

[giulitn]

Originally Posted by mcnallym

In the checkpoint interoperable object does the encryption domain behind the draytek gateway overlap with a network at the main office ?

Thank you for tyhe right question.
I've checked it out and the lan in the headquarter are
10.21/16
172.30.19/24
The LAN behind Drayetk is
10.10.10/24

[godspeedcapri]

It looks like a case of subnet overlapping..its lame, but checkpoint has a stringent subnet overlapping check.

I would recommend checking the following:

- In Tracker, pay close attention to Phase II subnet key exchanges - insure that the masks are correctly defined for the internal networks.

- Check the domain object on the checkpoint end and check the internal network/mask object.

Also search CPUG for user.def file modifications. You can specify your local and remote subnet in that file.

[denbesten]

Just ran into the "encryption failure: According to the policy the packet should not have been decrypted" error myself. I had improperly defined the crypto domain for the remote site to not include the source address that they were using. In my case, the error message is basically warning me of anti-spoofing on a VPN level.

To check for this, open the interoperable device object for the dratec, and click on the topology tab. Make sure that the crypto domain includes 10.10.10.0/24.

Also, inspect the log file to verify that the dratec is not doing NAT in a way that you do not expect. If it is, you may need to add its xlate-src address to the crypto-domain. In this case, the trick is to use a network-object group as the crypto domain.

I actually use a group with a name similar to the interoperable device (*-gtwy and *-crypto, actually) whenever I create a VPN because it makes future changes easier.