This section provides a list of common VPN error messages and their corresponding
troubleshooting steps. It covers issues related to IKE phase negotiation, proposals, proxy
IDs, and maximum proxy ID limitations.
Where Can I Use This?
What Do I Need?
No license required
The following table lists some of the common VPN error
messages that are logged in the system log.
Syslog Error Messages for
If an error is this:
IKE phase-1 negotiation is
failed as initiator, main mode. Failed SA: x.x.x.x-y.y.y.y cookie:84222f276c2fa2e9:0000000000000000
due to timeout.
1 negotiation is failed. Couldn’t find configuration for IKE phase-1
request for peer IP x.x.x.x
Verify that the public IP address
for each VPN peer is accurate in the IKE Gateway configuration.
Verify that the IP addresses can be pinged and that routing issues aren’t causing the connection
Received unencrypted notify
payload (no proposal chosen) from IP x.x.x.x to y.y.y.y, ignored...
phase-1 negotiation is failed. Unable to process peer’s SA payload.
Check the IKE Crypto profile configuration
to verify that the proposals on both sides have a common encryption,
authentication, and DH Group proposal.
pfs group mismatched:my: 2peer:
IKE phase-2 negotiation
failed when processing SA payload. No suitable proposal found in
peer’s SA payload.
Check the IPSec Crypto profile configuration
to verify that:
PFS is either enabled or disabled on both VPN peers
the DH Groups proposed by each peer has at least one DH Group
IKE phase-2 negotiation failed
when processing Proxy ID. Received local id x.x.x.x/x type IPv4
address protocol 0 port 0, received remote id y.y.y.y/y type IPv4
address protocol 0 port 0.
You must have reached the maximum proxy IDs supported on your
firewall. Check the maximum proxy IDs supported on your firewall
before establishing an IPSec tunnel.
We recommend you to check the maximum proxy IDs supported on your
firewall before configuring proxy IDs for the VPN peers. If you have
a use case where you want to implement an IPSec VPN tunnel with more
than the maximum proxy IDs supported on a firewall, follow these
Configure another tunnel with the same phase 1 and phase 2
SuperNet the IP address for the proxy IDs. For example,
instead of using 10.1.0.0/16, 10.2.0.0/16, supernet the
range to 10.0.0.0/8 for avoiding multiple entries.
Proxy ID mismatch
Proxy ID mismatch will result in failure to
establish the site-to-site IPSec VPN tunnel. Therefore, configure
identical Proxy IDs on both VPN peers to establish the site-to-site
IPSec VPN tunnel successfully.
For example: In a site-to-site IPSec tunnel configuration, if one VPN
peer is configured with an IP address for a netmask of /32 and the
remote VPN peer is configured with the same IP address but with the
different netmask of /16, it will result in failure establishing the
Proxy ID for other firewall vendors are
referred to as the Access List or Access Control List (ACL).
Proxy IDs in the VPN peers should be exact mirrors of each other (that
is, be opposite), but not match.
Example proxy ID configuration for VPN peers to establish an IPSec
If VPN firewall 1 is configured with 192.0.2.0/24 as local ID and
192.0.2.25/24 as peer ID. Then, VPN firewall 2 must be configured
with 192.0.2.25/24 as local ID and 192.0.2.0/24 as peer ID.