:::: MENU ::::

Avaya IP Office 412 & 5610IP & Sonicwall VPN

Recently several new initiatives have caused us to look into extending our Phone system beyond the physical location of our main campus.  We have an Avaya IP Office 412 with 150+ digital extensions.  As part of the IPO you can do VOIP extensions but we haven’t had a large need to deploy those since our building was already wired for a phone and data network separately (Major PROS & CONS to this but not in this post). 

We do have however a couple handsets in locations where we can’t get a pair of copper for the digital phones so we have  a couple VOIP extensions on campus.  Those have worked great, plug the phone into the network, configure the IP and the VLan and your making calls.  So it should be that easy over our VPN right?  Wrong. 

After several hours of searching to figure out the issue we learned it was both a IPO Issue as well as a configuration issue in the Sonicwall Firewalls.  Since there was little documentation about this specific combo I have documented it here as well as the nuggets of info we learned along the way.

Hardware Used:
- IPOffice 412
- Avaya 5610sw IP-Handset
- Sonicwall TZ100 at remote location and Sonicwall EClass 5500 on main campus.


- Configure a new IP Extension on the IPO, Enter Only the Extension ID and Base Extension
- Configure the User for the Extension and Program Buttons Etc.
- Create an Incoming call route for the DID
- Connect the 5610 to the local network to make sure the phone is working locally. 
- Boot From DCHP, Enter IPO IP address (Phone Server) and Enter Voicemail Server IP (FIle Server)
- After the phone talks to the IPO it updates Firmware updates and the the phone is functional

At this point all was well and we were able to make and receive calls from the IP handset and it was time to take the phone to the remote site.  The remote site is where we started having connectivity issues and the phone wouldn’t boot completely.

-Plug in the phone and choose DHCP and it fails to connect to the server.  Do  a phone reset to clear out all networking gremlins from local network settings: Press Hold then 25327#
-Phone reboots and grabs DHCP address but cannot talk to the TFTP server.
Note: Workstation running the IPO Manager software runs a TFTP server when the application is open but not editing a config file.  If Manager isn’t running IP Phones will not update.

In the troubleshooting we could ping any device on the core network from the VPN except the IPO.  You could ping the Voicemail Server but no response from the IPO.  This was because the IPO requires you to  manually add an IP route for each subnet that is not the subnet of the IPO’s LAN1 Interface.

Some discussion forums noted that you would have to have a license for VPN or Remote IP Handsets but that is not the case.
To Configure the IP Route in the IPO:
- Open the IPO Config Manager and navigate in the tree to: IP Route
- Right Click and Choose New.
- In the new Route Config enter the IP Address of the Remote Router, IP Mask of the Remote Location
- The Gateway IP address should be the LOCAL IP of the Gateway on the Local network
  (Don’t enter the Gateway IP that you entered above in the IP Phone)
Choose the Destination of LAN1
- Save and Merge the Config. (Values shown have been modified and will not work with live config)

After this we should have seen the IP Handset boot, talk to the TFTP server and then work…. but that wasn’t the case.  When the phone would boot it would not show up as an extension in the IPO System Status nor would it check in with the TFTP server.  It would however appear to have booted and have a base extension without any call appearances.  Trying to use the phone resulted in a bunch of beeps.

After we were finally ready with the IPO configuration it now appeared something was blocking traffic over the VPN link from the remote location to the main campus. 

A call to Sonicwall reveled that in the latest firmware 5.5.x there are default settings enabled that should not be enabled to allow H.323 packets to travel from remote to local sites over VPN.  These settings should be enabled if you are NATing VOIP traffic via the WAN but not enabled if your VOIP traffic is traversing via VPN.
(Leads me to ask the question, can you not have a combination of VOIP Over VPN and VOIP via NAT, but that question can remain unanswered since it doesn’t impact us).
To disable these settings in the Sonicwall Admin interface go to VOIP and the ALL of the following should all be DISABLED on BOTH routers (Local and Remote).
- Enable Consistent NAT
- Enable SIP Transforms
- Enable H.323
It is important to note these setting changes require a reboot of both routers to take effect.

After a reboot of both routers and a reboot of the handset it registers with IPO as an extension and calls can be made and received.

It is important to note, this VOIP extension is not in the same physical location and it is the PBX operators responsibility to notify your dial tone provider of the physical location of that handset for E911 (PS/ALI Compliance).


  • Reply Chris Green |

    Consistent NAT should always be enabled, but we always disable H.323 and SIP transformations. I find it interesting that any of these settings affect VPN traffic at all though. That sounds like a bug.

  • Reply Jim D |

    Do you think this method will still apply today? We have an IPO 9.0 with 1616 phones at two home offices. The main office has a TZ210 and the remote homes have TZ100′s.


So, what do you think ?