We have a site to site VPN setup that was allowing one IP. On the ipsec tunnel sec proxy-id allow local (10.1.2.1/32) which was working just fine.
We had to recently allow two more IP's 10.1.2.20 and 10.1.2.75. I Changed the ipsec tunnel sec proxy-id local to 10.1.2.0/32 to allow a range. When we made this change the VPN is enabled, but we are seeing the following error from the external site trying to access these IP's.
'IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local id: 10.1.2.75/32 type IPv4_address protocol 0 port 0, received remote id: 10.x.x.x/22 type IPv4_subnet protocol 0 port 0."ot see a matching encryption"
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 user connecting is on a cisco firewall. Before these changes one thing I had to do was set no-pfs on the DH-Group. I'm wondering since this is a range and not a single IP is this different now?
Solved! Go to Solution.
Could you please try below mentioned steps ( assuming that, currently the tunnel is not passing any production traffic).
>show vpn ipsec-sa tunnel <tunnel name>
> show vpn ike-sa gateway
> clear vpn ike-sa gateway XXXXX
Delete IKEv1 IKE SA: Total 1 gateways found.
> clear vpn ipsec-sa tunnel XXXXXX
Delete IKEv1 IPSec SA: Total 1 tunnels found.
> test vpn ike-sa gateway XXXXXX
Initiate IKE SA: Total 1 gateways found. 1 ike sa found.
> test vpn ipsec-sa tunnel XXXXXX
Initiate IPSec SA: Total 1 tunnels found. 1 ipsec sa found.
> show vpn flow
>show vpn flow tunnel-id x << where x=id number from above display
Let us know the result.
As usual thanks for the great help Hulk. I ran through these procedures and cleared the keys. The connection is active and up. The remote site is still getting the error:
'IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local id: 10.1.2.1/32 type IPv4_address protocol 0 port 0, received remote id: 10.x.x.0/22 type IPv4_subnet protocol 0 port 0.
admin@PA-500(active)> show vpn flow tunnel-id 21
gateway id: 4
local ip: 69.x.x.x
peer ip: 216.x.x.x
inner interface: tunnel.4
outer interface: ethernet1/1
tunnel mtu: 1428
lifetime remain: 3405 sec
latest rekey: 195 seconds ago
monitor packets seen: 0
monitor packets reply: 0
en/decap context: 226
local spi: BFD74292
remote spi: B750B977
key type: auto key
auth algorithm: SHA1
enc algorithm: AES128
proxy-id local ip: 10.1.2.0/32
proxy-id remote ip: 10.x.x.x/24
proxy-id protocol: 0
proxy-id local port: 0
proxy-id remote port: 0
anti replay check: yes
copy tos: no
authentication errors: 0
decryption errors: 0
inner packet warnings: 0
replay packets: 0
when lifetime expired:0
when lifesize expired:0
sending sequence: 0
receive sequence: 0
encap packets: 12005877
decap packets: 14018067
encap bytes: 2596966960
decap bytes: 1891762952
key acquire requests: 236118
owner state: 0
owner cpuid: s1dp0
Could you please confirm the local subnet as: 10.1.2.0/32. I think it would be 10.1.2.0 /24 to allow the entire subnet. Also, need to configure the same proxy ID's on the other end device as well.
I am trying to establish a succesful VPN connection between my Palo Alto firewall and a Check Point firewall. The VPN tunnel on the Palo Alto side shows all green for phase 1 and 2, however on the Check Point side I keep getting a failure per the log "IKE failure no response from peer".
In the "Monitor" > "System" log of the Palo Alto the message I am seeing is "ike-nego-p2-proxy-id-bad" "IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local ID 10.30.30.0/24 type IPv_4_subnet protocol 0 port 0, received remote id: 10.10.10.0/24 type IPv4_subnet protocol 0 port 0.
On the Check Point side the local network is the 10.10.10.0/24. I am using a "encryption domain" on the Check Point.
I do not have any Proxy ID's configured on the Palo Alto side. I am under the impression that routing the traffic for destination 10.10.10.0/24 to the tunnel interface as a static route is all that is needed to identify the remote private network.
On the Palo Alto for the IKE crypto profile I am using Suite-B-GCM-128, and IPSec Crypto Profile Suite-B-GCM-128.
I have tried a proxy ID on the palo alto side with local being 10.30.30.0/24 (the local Palo Alto private network) and remote 10.10.10.0/24 (the Check Point side private network) and that brought the tunnel on the Palo Alto side down. After this I only have a green light for IKE Info under status of the IPsec Tunnels area.
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 Live Community as a whole!
The Live Community thanks you for your participation!