cannot find matching phase-2 tunnel for received proxy ID

[a.mboukam]

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??

[TomYoung]

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

[a.mboukam]

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.

[Raido_Rattameister]

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.

[TomYoung · Accepted solution]

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

[Raido_Rattameister]

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.

[a.mboukam]

Remote side is a CISCO ASA Firewall

[Raido_Rattameister · Accepted solution]

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

[a.mboukam]

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.

[a.mboukam]

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.

[morahman]

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

[Raido_Rattameister]

Check if Palo has ProxyID with following settings.

local - 172.24.150.146/32
remote - 209.73.202.16/28

[morahman]

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

[Raido_Rattameister]

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