This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSEC with Avaya 9600 VPN phone

I am trying to connect an AVAYA 9600 IP Phone via VPN to Astaro. The phone is not connected and it is giving my an error on IKE Phase 2. On the Astaro site I am getting the attached error log.

Do you have any idea what is causing the problem?


This thread was automatically locked due to age.
Parents
  • SOPHOS -- Create a New IPsec Policy

    Sorry in advance for the formatting...  I attempted to upload a ZIP file that contained a formatted PDF file multiple times, but the file continued to get corrupt.


    **** META DATA *******

    1.  Configure Avaya 9611 IPsec VPN client 

    2.  Configure Remote IPsec on SOPHOS UTM 9.x for Avaya 9600 VPN clients


    Keywords
    Avaya 9600 VPN, Avaya 9611 VPN, Avaya IPsec VPN configuration, Configure Avaya Phone with SOPHOS VPN, Configuring Avaya 9611 IPsec VPN w/ Remote SOPHOS IPsec VPN -- IP Office 8.1


    ******** DOC ***********

    Configuring Avaya 9611 VPN for IP Office w/ SOPHOS UTM 9.x
    Overview
    Some Avaya 9600 phones, such as the 9611, have a native IPsec VPN client that can be used to connect remote workers to the corporate phone system when other options just won’t cut it.  Online documentation is poor and often differs for each firewall vendor.  Please note that this configuration is functional, but it may or may not comply with the security requirements of your business.  Please discuss them with your security team and try other settings if necessary.  
    We are testing this option now to hopefully rid our environment of softphones.  We’re also testing the “Telecommuter Option” of one-X.  This allows our remote workers to use their home phones and proxy everything through the IP Office server, but it comes with the cost of chewing up 2 SIP channels for each call.
    Don’t forget to buy power injectors!

    High Level Network Design
    Object Network/Connection Type Comment 
    IPO 8.1 DC Voice Network
    9611 Phones HQ Voice, Sat Voice, *Home Offices *This doc…
    Soft Phones HQ Data, Sat Data, *Remote Office A handful of users…
    SOPHOS Firewall DC Virtual interfaces for DC Voice and DC Data vLANs

    Sat Office Connection StS IPsec VPN ASA 5510 – SOPHOS UTM 9.x VM
    HQ Office Connection Gig Fiber – MPLS Direct Connect from HQ to DC
    DC Connection Dual 10G Fiber IP Transit secured by SOPHOS HA pair 
    Remote Workers Several Personal connections not managed by IT


    Known Issue
    The “Enable Direct Media Path” extension option must be unchecked for all extensions participating in a call.  Some Avaya documentation says to disable this for “VPN to VPN phone calls”, but we experienced the problem with ALL phone calls to/from a VPN phone.  Disabling the option for the extension associated with just the VPN phone was not enough.  Attempts were made to open firewall rules, verify routes, etc, but nothing yielded the desired result.  Talk to your phone support team and ask them if it’s okay to disable direct media path for anyone and everyone that will send/receive calls with VPN phones.  
    o 10 digit extension calls do not experience the issue above because they loop through the outside.  However, attempting this is not a good workaround and will only confuse users.
    o Every firewall/network configuration will differ.  You may not experience the issue, but if you do, try the workaround with a handful of users.

    Remote SOPHOS IPsec VPN Setup
    1.  Create a New IPsec Policy

    Description Setting Note
    Name VPNPHONE
    IKE encryption algorithm 3DES
    IKE authentication algorithm SHA1
    IKE SA lifetime 7800
    IKE DH group Group 2: MODP 1024

    IPsec encryption algorithm 3DES
    IPsec authentication algorithm SHA1
    IPsec SA lifetime 3600
    IPsec PFS group Group 2: MODP 1024
    Strict Policy Unchecked
    Compression Unchecked

    2.  Create a New IPsec Remote Access Rule

    Description Setting Note
    Name VPNPHONE
    Interface External (WAN) Depends on config, but will be the most common selection
    Local Networks *** Add all networks – IP Office & each network w/ phones
    Virtual IP Pool  VPN Pool (IPsec) Defaults to 10.242.4.0/24
    Policy VPNPHONE
    Authentication Type Preshared Key Document the key.  It will be used for the 9611 too.
    Enable XAUTH SELECTED
    Allowed Users ** Create new Users – ext01, ext02, etc.

    3.  Configure Required Firewall ACLs 
    a. Outside the scope of this document, but make sure your IPsec VPN group can minimally talk to the network where the IPO(s) server is.  Depending on your network and firewall configuration, and the requirements of your security department, one or more simple rules from the IPO network to the IPsec VPN group (and back) might be enough.  If you can get direct media access to work you may need to supply all networks where phones are located.

    4. Configure the 9611 Phone
    a. Enter the OPTIONS tab on boot up.  Our code to enter was 27238.  This may or may not be different for you.
    b. Go to the VPN setup and supply the following values:

    Phone Option Value
    VPN Enabled
    VPN Vendor OTHER
    Gateway Address The public IP address applied to the interface of the SOPHOS IPsec VPN
    Encapsulation 4500-4500
    Copy TOS Yes
    External Phone IP Address ** Typically done by your DHCP server
    External Router ** Typically done by your DHCP server
    External Subnet Mask ** Typically done by your DHCP server
    External DNS Server ** Typically done by your DHCP server

    Auth Type PSK with XAUTH
    VPN User Type Any
    VPN User The VPN user(s) account you  created above
    Password Type Save in Flash
    User Password The VPN user(s) account password

    IKE ID (Group Name) VPNPHONE
    Pre-Shared Key (PSK) The PSK you entered for the SOPHOS “IPsec Remote Access Rule”

    IKE ID Type USER_FQDN
    IKE Xchg Mode ID Protect
    IKE DH Group 2
    IKE Encryption Alg. 3DES
    IKE Auth. Alg. SHA1
    IKE Config. Mode Enabled

    IKE PFS DH Group 2
    IPsec Encryption Alg 3DES
    IPsec Auth. Alg.  SHA-1
    Protected Network.. ** See extended comments below

    IKE over TCP Auto 


    ** 9611 Protected Network Comments
    • You should supply all networks that were included in the “Local Networks” of the SOPHOS “IPsec Remote Access Rule”.  A lot of confusing documentation, partially accurate, is floating around on the Internet.  Some of it even says to use the IP Pool network associated with your VPN group.  If you don’t have one or more correct networks listed you will fail on “IKE PHASE 2”.  We were getting this error message
    o cannot respond to IPsec SA request because no connection is known for 10.x.x.x/24===209.x.x.x:4500[209.x.x.x]...4.x.x.x:4500[VPNPHONE]===192.x.x.x/32
     ***Actual addresses were removed… 

    • If you do not have “Direct Media Path” enabled on your extensions then you really only need to supply the network(s) where the IPO server(s) is located.  See the notes on “Direct Media Path” above for more info.

    • Some Avaya documentation says to use 0.0.0.0/0, which means any addressable network.  This does not work.

    • Multiple networks can be defined in the 9611.  Simply list each one with commas and do not use spaces.
    o Example:  192.168.10.0/24,172.16.0.0/16,192.168.30.0/24
Reply
  • SOPHOS -- Create a New IPsec Policy

    Sorry in advance for the formatting...  I attempted to upload a ZIP file that contained a formatted PDF file multiple times, but the file continued to get corrupt.


    **** META DATA *******

    1.  Configure Avaya 9611 IPsec VPN client 

    2.  Configure Remote IPsec on SOPHOS UTM 9.x for Avaya 9600 VPN clients


    Keywords
    Avaya 9600 VPN, Avaya 9611 VPN, Avaya IPsec VPN configuration, Configure Avaya Phone with SOPHOS VPN, Configuring Avaya 9611 IPsec VPN w/ Remote SOPHOS IPsec VPN -- IP Office 8.1


    ******** DOC ***********

    Configuring Avaya 9611 VPN for IP Office w/ SOPHOS UTM 9.x
    Overview
    Some Avaya 9600 phones, such as the 9611, have a native IPsec VPN client that can be used to connect remote workers to the corporate phone system when other options just won’t cut it.  Online documentation is poor and often differs for each firewall vendor.  Please note that this configuration is functional, but it may or may not comply with the security requirements of your business.  Please discuss them with your security team and try other settings if necessary.  
    We are testing this option now to hopefully rid our environment of softphones.  We’re also testing the “Telecommuter Option” of one-X.  This allows our remote workers to use their home phones and proxy everything through the IP Office server, but it comes with the cost of chewing up 2 SIP channels for each call.
    Don’t forget to buy power injectors!

    High Level Network Design
    Object Network/Connection Type Comment 
    IPO 8.1 DC Voice Network
    9611 Phones HQ Voice, Sat Voice, *Home Offices *This doc…
    Soft Phones HQ Data, Sat Data, *Remote Office A handful of users…
    SOPHOS Firewall DC Virtual interfaces for DC Voice and DC Data vLANs

    Sat Office Connection StS IPsec VPN ASA 5510 – SOPHOS UTM 9.x VM
    HQ Office Connection Gig Fiber – MPLS Direct Connect from HQ to DC
    DC Connection Dual 10G Fiber IP Transit secured by SOPHOS HA pair 
    Remote Workers Several Personal connections not managed by IT


    Known Issue
    The “Enable Direct Media Path” extension option must be unchecked for all extensions participating in a call.  Some Avaya documentation says to disable this for “VPN to VPN phone calls”, but we experienced the problem with ALL phone calls to/from a VPN phone.  Disabling the option for the extension associated with just the VPN phone was not enough.  Attempts were made to open firewall rules, verify routes, etc, but nothing yielded the desired result.  Talk to your phone support team and ask them if it’s okay to disable direct media path for anyone and everyone that will send/receive calls with VPN phones.  
    o 10 digit extension calls do not experience the issue above because they loop through the outside.  However, attempting this is not a good workaround and will only confuse users.
    o Every firewall/network configuration will differ.  You may not experience the issue, but if you do, try the workaround with a handful of users.

    Remote SOPHOS IPsec VPN Setup
    1.  Create a New IPsec Policy

    Description Setting Note
    Name VPNPHONE
    IKE encryption algorithm 3DES
    IKE authentication algorithm SHA1
    IKE SA lifetime 7800
    IKE DH group Group 2: MODP 1024

    IPsec encryption algorithm 3DES
    IPsec authentication algorithm SHA1
    IPsec SA lifetime 3600
    IPsec PFS group Group 2: MODP 1024
    Strict Policy Unchecked
    Compression Unchecked

    2.  Create a New IPsec Remote Access Rule

    Description Setting Note
    Name VPNPHONE
    Interface External (WAN) Depends on config, but will be the most common selection
    Local Networks *** Add all networks – IP Office & each network w/ phones
    Virtual IP Pool  VPN Pool (IPsec) Defaults to 10.242.4.0/24
    Policy VPNPHONE
    Authentication Type Preshared Key Document the key.  It will be used for the 9611 too.
    Enable XAUTH SELECTED
    Allowed Users ** Create new Users – ext01, ext02, etc.

    3.  Configure Required Firewall ACLs 
    a. Outside the scope of this document, but make sure your IPsec VPN group can minimally talk to the network where the IPO(s) server is.  Depending on your network and firewall configuration, and the requirements of your security department, one or more simple rules from the IPO network to the IPsec VPN group (and back) might be enough.  If you can get direct media access to work you may need to supply all networks where phones are located.

    4. Configure the 9611 Phone
    a. Enter the OPTIONS tab on boot up.  Our code to enter was 27238.  This may or may not be different for you.
    b. Go to the VPN setup and supply the following values:

    Phone Option Value
    VPN Enabled
    VPN Vendor OTHER
    Gateway Address The public IP address applied to the interface of the SOPHOS IPsec VPN
    Encapsulation 4500-4500
    Copy TOS Yes
    External Phone IP Address ** Typically done by your DHCP server
    External Router ** Typically done by your DHCP server
    External Subnet Mask ** Typically done by your DHCP server
    External DNS Server ** Typically done by your DHCP server

    Auth Type PSK with XAUTH
    VPN User Type Any
    VPN User The VPN user(s) account you  created above
    Password Type Save in Flash
    User Password The VPN user(s) account password

    IKE ID (Group Name) VPNPHONE
    Pre-Shared Key (PSK) The PSK you entered for the SOPHOS “IPsec Remote Access Rule”

    IKE ID Type USER_FQDN
    IKE Xchg Mode ID Protect
    IKE DH Group 2
    IKE Encryption Alg. 3DES
    IKE Auth. Alg. SHA1
    IKE Config. Mode Enabled

    IKE PFS DH Group 2
    IPsec Encryption Alg 3DES
    IPsec Auth. Alg.  SHA-1
    Protected Network.. ** See extended comments below

    IKE over TCP Auto 


    ** 9611 Protected Network Comments
    • You should supply all networks that were included in the “Local Networks” of the SOPHOS “IPsec Remote Access Rule”.  A lot of confusing documentation, partially accurate, is floating around on the Internet.  Some of it even says to use the IP Pool network associated with your VPN group.  If you don’t have one or more correct networks listed you will fail on “IKE PHASE 2”.  We were getting this error message
    o cannot respond to IPsec SA request because no connection is known for 10.x.x.x/24===209.x.x.x:4500[209.x.x.x]...4.x.x.x:4500[VPNPHONE]===192.x.x.x/32
     ***Actual addresses were removed… 

    • If you do not have “Direct Media Path” enabled on your extensions then you really only need to supply the network(s) where the IPO server(s) is located.  See the notes on “Direct Media Path” above for more info.

    • Some Avaya documentation says to use 0.0.0.0/0, which means any addressable network.  This does not work.

    • Multiple networks can be defined in the 9611.  Simply list each one with commas and do not use spaces.
    o Example:  192.168.10.0/24,172.16.0.0/16,192.168.30.0/24
Children
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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 :)

  • Hello.

    I am trying to get ourXG105 running SFOS 17.5.6 to work with 2 Avaya 9600 phones.  Your instructions are the best I have seen.  They are for an earlier version of SFOS since but most same knobs are in much the same place.  

     

    What has changed for Release 17.5.6 ?  When I try the instructions above i am getting "Exchanging Keys" and then "IKE Phase 1 no response" on the phones. 

    Also what logging do I need to turn on to see detailed IPSEC logs on the SFOS ?   In the upper right, Log View I can't see any failed VPN access attempts even when I search via Source IP?

     

    Thank you all for the help in advance.

  • The instructions found here were for a Sophos UTM. For the XG model you should be able to follow these instructions:

    https://community.sophos.com/kb/en-us/131471

     

    I have done it. It's been quite awhile since I did it though, and don't remember if I had to make any changes in the process.

     

    I highly recommend moving to a TLS H323 connection instead now.

     

    Richard

  • I have completed this and found that if you do not have access to the phone, the best way to enable VPN on the phone, is to amend the 46xxsettings.txt file this is store on the Avaya, and when the phone initially configures it self from the Avaya, this file will provide the defaults for the phone when connecting to the Avaya PBX.

    XG & UTM Architect (Systems: XG v18 & UTM 9.7 - Virtual, HW & SW)
    Curious enough to take it apart, skilled enough to put it back together, Clever enough to hide the extra parts when I'm Done!