- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
11-06-2012 11:34 AM
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!
Thanks,
Steve
First Annapolis
11-06-2012 12:14 PM
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.
11-06-2012 01:35 PM
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.
12-11-2012 11:18 PM
Hello,
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.
Regards,
Aditi
12-12-2012 10:01 AM
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?
04-22-2013 04:08 PM
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?
04-23-2013 05:31 AM
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 name@domain.com
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
06-11-2013 03:49 PM
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.
06-11-2013 06:18 PM
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?
06-17-2013 02:16 PM
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.
06-18-2013 06:51 AM
We currently have 5 or 6 9611G models operating without issue. What model are you working with?
On the phone itself, our settings of note are:
VPN Vendor is set to Other
Encapsulation is set to 4500-4500 (this caused issues if set otherwise)
IKE ID is KEY_ID
We never had any success with the 4600 series IP phones, so if you are using these, you may be out of luck. As long as you have the VPN version of the firmware on the 9600s, you can navigate the settings by pressing * to program and then VPN for the access code, or the default Avaya security code of 27238.
06-18-2013 07:19 AM
I got you, I was more or less suggesting that just to see if it'd work at all, I understand that's not really a palatable long term solution.
06-18-2013 07:50 AM
Thanks for the response and the help. That's good to hear you have some working. I was beginning to think it wasn't possible. We are using the 9620L model. I changed the Encapsulation to 4500-4500 as you suggested. It wasn't previously set that way though. Didn't seem to do the trick unfortunately. The firewall shows me the error I have attached. I am not sure how to configure the KeyID in the PA's Global Protect configurations to match the phone. How did you handle that?
07-03-2013 01:33 PM
Well, I finally threw in the towel. After many days (probably more like weeks) of troubleshooting and testing we just decided to purchase a firewall from a different vendor. From firewall install to working phone was about 3 hours. Too bad I couldn't get this working on Palo Alto, that's one of the reasons we bought them. Thanks to those who offered help.
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!