IPSec VPN Error: IKE Phase-2 Negotiation is Failed as Initiator, Quick Mode

Printer Friendly Page


A site-to-site IPSec VPN  between a Palo Alto Networks firewall and a firewall from a different vendor is configured.

Phase 1 succeeds, but Phase 2 negotiation fails.


A look at the ikemgr.log with the CLI command:

> tail follow yes mp-log ikemgr.log


shows the following errors:

( description contains 'IKE protocol notification message received: INVALID-ID-INFORMATION (18).' )


IKE phase-2 negotiation is failed as initiator, quick mode. Failed SA:[500]-[500] message id:0x43D098BB. Due to negotiation timeout




The most common phase-2 failure is due to Proxy ID mismatch.



To resolve Proxy ID mismatch, please try the following:

  1. Check the Proxy ID settings on the Palo Alto Networks firewall and the firewall on the other side.
    Note: Proxy ID for other firewall vendors may be referred to as the Access List or Access Control List (ACL).
  2. Also, check the IPSec crypto to ensure that the proposals match on both sides.


See Also

For more info on IPSec, please see the:

IPSec and tunneling - resource list


owner: vvasilasco


Is there a way I can look at the incoming IPSec crypto proposals to see if they're matching up with the one configured on the PA firewall?


You can use this command to see a more detail logs regarding the IPSec.

>tail follow yes mp-log ikemgr.log

Also System (monitor tab) logs are very useful when it comes to proposal mismatch etc. 

Thanks, I figured out my issue.

I was testing out a site to site IPSec VPN between a PA 200 and a Windows 2008 R2 server. I wasn't getting much information from the logs when I initiated the connection from the PA firewall side. However when I initiated the connection from the Windows server side, I got an additional message:

"2013-05-05 16:22:02 [PROTO_ERR]: pfs group mismatched: my:2 peer:0" 

It turns out windows server doesn't use pfs for Phase 2. After setting 'no-pfs' on my IPSec Crypto profile it started working fine.

thank you for the update, i am glad this worked.

Is there a way to match or filter on the mp-log?

@Gun-Slinger, yes, you can easily view any log file with the less command, and then use "/" to "search" for something.


CLI command:

> less mp-log ikemgr.log



2016-09-07 22:17:55.451 -0700 cfgagent register failed in try 4/25. sleeping for
5 seconds...


If you then type "/" and then let's say we want to search on all instances of "failed", type that and hit enter, and it will return where it finds that word in that log file. ( I only use red because I cannot replicate it here what it looks like on an SSH session):


2016-09-07 22:17:50.450 -0700 Error: pan_cfgagent_write_sysd_boolean_sync(pan_c
fgagent.c:168): sync modify <sw.mgmt.runtime.clients.ikemgr.register> failed: NO
2016-09-07 22:17:50.450 -0700 cfgagent register failed in try 3/25. sleeping for
5 seconds...


Then you can navigate through with normal keyboard commands.. you can page up and page down, you can arrow up and down. You can use "n" to go to the next instance of the word or phrase you are looking for, or shift-n to go backwards through the search.

And to exit the search, just use "q" to quit.


I hope this helps!


That is great, thanks for the response jdelio

I am getting the below. Any idea what the message 17: INVALID-KEY-INFORMATION relates to?


2017-04-19 10:44:17 [INFO]: received Vendor ID: FRAGMENTATION
====> Established SA: x.x.x.x[500]-y.y.y.y[500] cookie:a45d144d06e1d3df:5021cd7d22289092 lifetime 86400 Sec
2017-04-19 10:44:19 [INFO]: the packet is retransmitted by y.y.y.y[500].
2017-04-19 10:44:21 [INFO]: the packet is retransmitted by y.y.y.y[500].
2017-04-19 10:44:23 [INFO]: the packet is retransmitted by y.y.y.y[500].
====> Initiated SA: x.x.x.x[500]-y.y.y.y[500] message id:0x2C200FC7 <====
2017-04-19 10:44:23 [PROTO_NOTIFY]: notification message 17:INVALID-KEY-INFORMATION, doi=1 proto_id=3 spi=e6874dfb(size=4).
====> Failed SA: x.x.x.x[500]-y.y.y.y[500] message id:0x2C200FC7 <==== Due to negotiation timeout.


The message "invalid key information" could mean many different things.


I would start with the peer, and confirm all Phase 2 - IPSEC information. 

Make sure all of the settings match.. timeout, aes, etc.

Thanks. Solved the issue, it was a setting that was different on the other end.

Hi adrili


Seems like the Phase I is using Main Mode and Phase II is using Quick Mode.  Was that the mistach with was causing the issue for you.

I have a similar situation but on my case (globalprotect VPN), the log says that my peer has no DH configured:


pfs group mismatched: my:2 peer:0


But all the options I have has a DH configured.