Has anyone had success connecting Avaya IP phones via VPN to PA devices? I am able to complete IKE Phase 1 authentication, but fail Phase 2 due to local/remote proxy IDs not found:
'IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local id: 192.168.50.0/24 type IPv4_subnet protocol 0 port 0, received remote id: 172.16.33.2/32 type IPv4_address protocol 0 port 0.' )
I'm not sure where to configure the phase 2 parameters as the phase 1 connection occurs using a Global-Protect Portal/Gateway. The remote ID matches the address received by the client from the G-P Gateway pool.
If you have had any success with these devices, please help!
I did not quite get what you meant by"the phase 1 connection occurs using Global-protect Portal/Gateway". The errors that your are seeing are due to IPSEC tunnels and you can get rid of those errors by configuring Proxy IDS in the IPSEC tunnel configuration. Let me know if I am missing something.
Above is an image of our G-P gateway settings. The Group Name = IKE ID for phase 1, Group Password = Pre-shared Key.
The G-P gateway with these settings is processing phase 1 authentication successfully. I cannot setup an ipsec tunnel config associated with the G-P gateway as it is not recognized as an IKE gateway on the PA-500. So my question is, what Phase 2 settings is the PA-500 looking for (DH Group, Encryption Algorithm, Authentication Algorithm), and where are they set?
Hopefully that adds some clarity.
Currently Avaya's VPN client is not supported with Global protect yet, based on 'Section 10' of this document: Troubleshooting GlobalProtect, PAN-OS 4.1
You may try configuring an site-to-site IPsec tunnel for dynamic remote peer IP's to see if that helps.
Maybe I am using an older version of firmware than you but my GP Gateway configuration window doesn't show fields for Group Name and password. I am using 4.0.8. Any ideas?
I can't even get my Avaya 9602L unit to complete phase 1. I've configured the IKE ID as Group Name and the PSK as Group Password, but which VPN Vendor are you using, auth type, and IKE ID type?
These are the settings we use in our 46xxsettings.txt file (see the Avaya config doc for code translations and note some values are set generic as they cannot be shared publicly):
SET NVIKECONFIGMODE 1
SET NVIKEDHGRP 2
SET NVIKEID firstname.lastname@example.org
SET NVIKEIDTYPE 11
SET NVIKEP1AUTHALG 2
SET NVIKEP1ENCALG 1
SET NVIKEP1LIFESEC 43200
SET NVIKEP2AUTHALG 2
SET NVIKEP2ENCALG 1
SET NVIKEP2LIFESEC 43200
SET NVIKEPSK psk
SET NVIKEEXCHGMODE 1
SET NVMCIPADD callserverip
SET NVPFSDHGRP 0
SET NVSGIP GPgatewayip
SET NVVPNAUTHTYPE 4
SET NVVPNMODE 1
SET NVVPNPSWDTYPE 1
SET NVVPNSVENDOR 4
SET NVVPNUSERTYPE 1
SET NVXAUTH 1
SET VPNPROC 2
To date have you been able to successfully connect?
My problem seems to be with the "SET NVIKEIDTYPE". The PA logs show a mismatch key ID when my Avaya phone tries to connect. Where is that configured on the phone and more importantly, within Global Protect? Is it possible? I know where in an IPsec tunnel.
It's kind of disappointing that phones that are so widely used like Avaya are not supported on these firewalls.
I'm hoping these posts and thoughts will help others successfully connect so the knowledge can be shared. :smileyhappy:
Did you ever try to change over to a Site-to-Site IPsec tunnel style config on the PA? I would think the Avaya might need to support X-Auth in order to be a "normal" IPSec client.
Try building an IKE Gateway and an IPSec tunnel on the PA, and configure Proxy-IDs as well.
Have you seen this thread by the way?
I've thought of doing this but building an IPSec tunnel for each remote user would be unmanageable. This is why we have been attempting to go the GlobalProtect route, but I'm losing hope that it will ever work. The firewall is trying to match a KeyID. The Avaya seems to be sending this KeyID to the PA and I think the PA isn't sure what to do with it. I don't configure a KeyID on my Mac when setting up a VPN or within the GlobalProtect software, so I think this is more of an issue with how Avaya manages the connectiong and not the Palo Alto.
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!