I apologize in advance for bumping an old thread but this thread was very handy for getting a 9608 pinned through a UTM9 recently on Avaya IP Office R9.1.
This was my first experience assisting with a Sophos device and the interface was very intuitive.
I will be uploading a narrated version of the pdf to youtube with some notes before long but wanted to share some screenshots to go along with PL101's settings.
I come from the Cisco/Avaya world and figured I could shed a little light from a voice engineering perspective.
The VPN phones support all the way up to AES-256; for the test I deployed I used the pre-defined AES-128 PFS template and it worked excellent. The Avaya phones will negotiate the most secure Encryption & Authentication algorithm's that they can if you leave the setting on Any for those fields. Feel free to static to your setting but the "Any" is really simple/easy.
The UTM9 clearly defined its parameters for which DH groups it uses for phase 1 and 2 in the pre-defined templates. For the AES-128 template it used DH group 5 on both phases and this obviously must be hard-coded in the phone in order to get the VPN up.
A few quick notes (edited to add a few more):
27238 is used to access the administration pages for all 96x1 phones. This is the word "CRAFT" converted to numbers and Avaya still uses it for alot of administration codes/passwords. Depending on how the 46xxsettings.txt file of the phone is set, the code "VPN" (876) will give access to only the vpn tab of the craft menu. We often instruct users to dial 876 instead of the craft code so they get straight to the vpn tab to toggle off/on the vpn enabled option.
When setting up Avaya VPN phones, set the phone up on the "Address" tab statically as if the phone were going to be on site/local. When the VPN setting is toggled on, the proper settings that need to be changed to communicate over the VPN tunnel will automatically be adjusted for you. This allows the phone to be brought between remote sites and the office where the IP Office lives. Just the VPN enabled settings needs to be toggled in this scenario.
The destination field of the firewall rule should match what users enter in the "Protected Network" field of the phone of the IKE Phase 2 page. As mentioned above, if direct media path is disabled the phone will send all traffic through the IP Office (both h323/sip call setup signaling as well as the actual RTP audio stream). Leaving direct media path enabled allows the phones to use the phone system for h323/sip signaling but then stream the h323 stream directly between endpoints. VCM's are incredibly cheap nowadays so disabling direct media path for VPN devices is a simple way to avoid one-way audio issues.
Gateway address on the vpn tab of the phone is the public IP associated on the UTM device IPsec profile "Interface".
If the "address" tab of the phone is statically configured, users do not need custom dhcp option 242 to provide the phone it's call server and file server addresses. This is ideal because most home routers do not provide for custom dhcp strings/options. All of the "external" settings on the first page of the vpn menu can then properly be supplied by standard dhcp options at the remote site and 0.0.0.0 leaves it on DHCP for the remote site settings in case the user changes home networks or where they are plugging the phone in. This leaves the most flexibility for our users.
The "Name" field of the IPsec vpn profile on the UTM should match the IKE ID (Group name) of the Avaya phone field.
The logs shown on page 8/9 of the guide are incredibly handy for tracking down configuration errors or typos. I have entered settings into a thousand Avaya phones but happened to typo on the group name field and the live log was perfect for sourcing where my mistake was.
Last but not least here is the PDF guide for this setup:
http://cuttingedgecommunications.com/vpn/AvayaVPNPhone-SophosGuide.pdf
Hi, Jacob, and welcome to the UTM Community!
It's only a few times a year that someone provides such a handy how-to in their first post. I hope Cutting Edge decides to add Sophos to it's list of partners!
Cheers - Bob
Good post, thanks for sharing your input.
JacobHengel said:The "Name" field of the IPsec vpn profile on the UTM should match the IKE ID (Group name) of the Avaya phone field.
I have found that this may not be required, and may actually trigger a bug. When I had 2 phones behind the same NAT router, the Sophos got confused and gave them both the same IP address. According to the help, every user needs to have a static IP when they are behind a NAT router. After giving each person a static IP address, the problem persisted. It wasn't until we changed the group name to be unique did it resolve the problem. I used the username for the IKE ID (Group name).
Good post, thanks for sharing your input.
JacobHengel said:The "Name" field of the IPsec vpn profile on the UTM should match the IKE ID (Group name) of the Avaya phone field.
I have found that this may not be required, and may actually trigger a bug. When I had 2 phones behind the same NAT router, the Sophos got confused and gave them both the same IP address. According to the help, every user needs to have a static IP when they are behind a NAT router. After giving each person a static IP address, the problem persisted. It wasn't until we changed the group name to be unique did it resolve the problem. I used the username for the IKE ID (Group name).
Hi, Richard, and welcome to the UTM Community!
Again, it's great to have a member whose first post helps the Community.
I'm not familiar with the Avaya phone, but I can tell you that inexpensive home routers often cause this problem where a Remote Access server assigns the same IP to all devices behind the home router. I suspect that you might not have this problem when phoning from behind a business-class router. Still, that won't always be the case, so your suggestion will be a key to success for others configuring these phones.
Two first posts in the same thread with great info. Bravo! This is the first time I can remember such a thing happening in my 10 years participating here.
Cheers - Bob
Thank you for your reply Richard, I am very curious about the issue you ran into. I set this up behind a Cisco ASA on the far side for testing and did not run into the issue. However, not everyone will be running an enterprise class device on the remote side (most won't since this is often deployed for home workers) and if they were could realistically have the NGFW appliances handle a site to site tunnel.
Could you clarify something for me?
Did you make a unique name/profile/group for each user and match that name to the user name in the Sophos? From the logs I watched when I did this it looked like when the phone submitted it's "IKE ID", the Sophos checked it against the name field of the VPN profile; however, it has been a short while and I am not 100% sure on that now.
Traditional IPsec utilizing PSK with XAUTH would need a group name and password, as well as a username and password to authenticate through. Based on what you are saying it almost sounds like the Sophos is ignoring the group authentication portion? However, if you made a unique vpn group per user and matched it in the phone that seems like it would get around the issue you are mentioning. The unique group per user would not have to match the username as long as unique groups are present it sounds like.
Your clarification would be appreciated, cheers! :-)
JacobHengel said:Did you make a unique name/profile/group for each user
No, there is only 1 connection, happened to name it "AvayaVPNPhone". I have run a single phone on that connection for months. When I put 2 phones at a different location, I had the problem described. I thought the "Connection" name was supposed to match the group name, but as I read the help/manual for the UTM, it said no such thing, it's only a descriptive field. Since I saw the phrase "AvayaVPNPhone" appear in the logs where it said username="" I became suspicious and tried what I tried. I made no changes to the UTM, only to the phone. I had already given the phones static IPs. (The phones have unique usernames).
I believe the UTM is ignoring the Group Name. I do not know if that is "naughty", "bad" or "optional".
You can't create multiple "Connection"s without giving each "Group" a distinct PSK. I did not go down this route as I didn't wants to program 20 phones with a unique PSK :)
