cannot find matching phase-2 tunnel for received proxy ID

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

cannot find matching phase-2 tunnel for received proxy ID

L1 Bithead

Hello,

 

We have a site to site VPN setup between our PALO ALTO and a firewall of our customer that was allowing one IP. On the ipsec tunnel sec proxy-id allow local (172.18.23.61/32) and remote (172.21.88.191/32) . When we made this the VPN is enabled, but we are seeing the following error from the external site trying to access these IP's.


Error

( description contains 'IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local id: 172.18.23.61/32 type IPv4_address protocol 1 port 0, received remote id: 172.21.88.191/32 type IPv4_address protocol 1 port 0.' )

 

For some reason now the connection does not see a matching encryption? Any ideas where to pinpoint this issue? I checked our crypto setting to make sure they match on the other end. The customer is using a cisco firewall. I had set no-pfs on the DH-Group. the tunnel is UP but the ping or any service on cisco firewall can be done.

Any advise please??

2 accepted solutions

Accepted Solutions

Cyber Elite
Cyber Elite

Hi @a.mboukam ,

 

That is a tough one.  If the tunnel comes up, then the algorithms are fine and connectivity is fine.  However, initial connectivity to the remote end fails (timeout = no response).

 

  1. As  mentioned below, make sure the Proxy IDs match on both sides.
  2. Check to see if your NGFW is blocking the initial outbound IKE packets.  You may have a rule allowing inbound, but not outbound.  You should see the packets in the traffic log.
  3. Check to see if the remote side firewall is blocking the initial IPsec inbound packets.
  4. Check to see if the remote device has initiator only or originate only in the IPsec configuration.
  5. If you have ECMP, check the packets are going out the correct interface (Thanks @Raido_Rattameister !).
  6. Check to see if the NGFW is blocking it because of a LAND attack -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGbCAK.
  7. Check for something else?  😊

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

View solution in original post

Cyber Elite
Cyber Elite

With ASA as peer you need to match ProxyID on Palo with encryption domains on ASA.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

View solution in original post

13 REPLIES 13

Cyber Elite
Cyber Elite

Hi @a.mboukam ,

 

The encryption is fine.  The error is stating that the Proxy IDs don't match.  Best practice is to match Proxy IDs exactly on both sides.

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

Hello,

well received. I will fix that and revert.

 

When I initiate the traffic behind our Palo alto to the remote side, I have this error:

 

( description contains 'IKE phase-1 negotiation is failed as initiator, main mode. Failed SA: 129.0.25.116[500]-41.205.83.218[500] cookie:58cb247a9c9db2d8:0000000000000000. Due to timeout.' )

 

But when I initiate the traffic on remote site to our Palo Alto, Phase 1 and 2 work well.

 

please can I have some advise about this.

Thanks.

 

Best regards.

Cyber Elite
Cyber Elite

Remote side is also Palo?

Then just leave ProxyID empty and Palo will send over 0.0.0.0/0 

Palo does not use ProxyID for traffic routing. It is just to make remote peer happy if remote peer is using policy based VPN and encryption domains.

 

 

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Cyber Elite
Cyber Elite

Hi @a.mboukam ,

 

That is a tough one.  If the tunnel comes up, then the algorithms are fine and connectivity is fine.  However, initial connectivity to the remote end fails (timeout = no response).

 

  1. As  mentioned below, make sure the Proxy IDs match on both sides.
  2. Check to see if your NGFW is blocking the initial outbound IKE packets.  You may have a rule allowing inbound, but not outbound.  You should see the packets in the traffic log.
  3. Check to see if the remote side firewall is blocking the initial IPsec inbound packets.
  4. Check to see if the remote device has initiator only or originate only in the IPsec configuration.
  5. If you have ECMP, check the packets are going out the correct interface (Thanks @Raido_Rattameister !).
  6. Check to see if the NGFW is blocking it because of a LAND attack -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGbCAK.
  7. Check for something else?  😊

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

Cyber Elite
Cyber Elite

One thing to add to @TomYoung is if you have ECMP and multiple ISPs you need to have static route towards peer IP to make sure it takes correct path.

Otherwise remote side sees your incoming traffic from IP it does not have IKE configuration for.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Remote side is a CISCO ASA Firewall

Cyber Elite
Cyber Elite

With ASA as peer you need to match ProxyID on Palo with encryption domains on ASA.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Sorry @Raido_Rattameister  I forgot to update this but thank you for the information, I found out what the encryption domain/proxy id where. Thank you for responding and sorry about.

Sorry @TomYoung I forgot to update this but thank you for the information.

I found out what the encryption domain/proxy id where and the remote side firewall was blocking the initial IPsec inbound packets.

Thank you for responding and sorry about.

Hello @Raido_Rattameister 
I'm experiencing the same issue:

2023/11/01 17:06:47 info vpn Foresi ike-neg 0 IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local id: 172.24.150.146/32 type IPv4_address protocol 0 port 0, received remote id: 209.73.202.16/28 type IPv4_subnet protocol 0 port 0.
I wanted to confirm the proxy id number on PA FW and the ASA FW, however I found that the Cisco ASA FW doesn't have any proxy id numbers. Is there any other way to confirm proxy ids on ASA FW. In my scenario, there are multiple proxy ids for individual IPs(local and remote) on PA and on ASA there are only 2 ip subnets in proxy

Mohammed T. Rahman

Check if Palo has ProxyID with following settings.

 

local - 172.24.150.146/32
remote - 209.73.202.16/28

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Hello @Raido_Rattameister 
Palo does not have the ProxyID with following settings:

local - 172.24.150.146/32
remote - 209.73.202.16/28

Palo has all proxy ids with local and remote IP as a IPv4 only NO subnet. Here are the proxy IDs:

local- 172.24.150.146

remote- 209.73.202.19

remote- 209.73.202.24

remote- 209.73.202.20

remote- 209.73.202.25

remote- 209.73.202.21

remote- 209.73.202.22

remote- 209.73.202.23
Note: There is no Proxy ID with local- 172.24.150.146 remote - 209.73.202.16

Mohammed T. Rahman

Cyber Elite
Cyber Elite

You get those errors because encryption domain at other side is configured with 

remote - 172.24.150.146/32
local - 209.73.202.16/28

 

So you need to match it on palo side as

local - 172.24.150.146/32
remote - 209.73.202.16/28

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011
  • 2 accepted solutions
  • 4659 Views
  • 13 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!