'Encryption Failure: according to the policy the packet should not have been decrypted' log in SmartView Tracker for VPN Tunnel Test packet
The Remote Access VPN user has a private IP address on his local computer that is on the same subnet as one of the subnets in the encryption domain, AND the Gateway is not configured to assign an Office Mode IP address to the user.
Excluded services are configured in the VPN Community settings on one of the connecting Gateways, but are being encrypted on the other Gateway.
- User A is hiding behind a router on the Internet with private IP address 172.16.1.32/24.
- User A successfully connects to a Gateway somewhere on the Internet.
- Gateway has the following subnets defined in the encryption domain: 192.168.1.0/24 and 172.16.1.0/24.
- Gateway is not configured to assign an Office Mode IP address to user A.
Thus, when the encrypted Tunnel Test packet arrives at the Gateway, the Gateway decrypts the packet (strips the outer IP layer of the packet and maintains the inner IP layer, which contains the user's private IP address).
When Gateway attempts to reply to the Tunnel Test packet, it detects that the Source IP address of the packet is on the Gateway's inner/local network, and therefore, the packet should not have been decrypted in the first place, since there is no matching rule in the policy that would encrypt it. This causes the Gateway to drop the packet with the above-mentioned error.