Certain packets are being dropped. This is happening because the local VPN gateway is receiving packets in the clear while the current configuration states they should be encrypted.
Note that indeni automatically identifies this issue as resolved when a log appears in the SmartView Tracker with the same destination IP address and a Decrypt action (instead of Drop) OR if sufficient time has passed since the error has appeared.
Affected Source IPs:
Manual Remediation Steps:
Review the VPN configuration on both sides of the VPN tunnel. If the packet should not be encrypted, modify the VPN configuration of the local VPN peer to reflect this (either update the encryption domain or update the list of services for which traffic should not be encrypted). If the packet should indeed be encrypted, update the VPN configuration of the remote peer to ensure it sends the packets through the VPN tunnel.
How does this alert work?
indeni loads the VPN configuration from the management servers (CMAs, for example) as well the current VPN status from the gateways (‘vpn tu’ command, for example). indeni also listens to the logs coming out of the firewalls that indicate possible VPN issues (such as “encryption failure: cleartext packet should be encrypted”). In the case above indeni tracks the logs for dropped/rejected connections under the IPSec VPN blade to identify when there are drops due to a misconfiguration on either side of the VPN tunnel.