9608 & 5610's rebooting over VPN

[dmaderi1]

Good Day,
I have 2 sites, connecting via a Sonicwall VPN tunnel. I'm seeing H323 extensions running over the VPN reboot, regularly but with no pattern, my SIP conference phone and intercom are not effected. Sometimes they all go at the same time, other times it's just 1 phone. I can't seem to narrow down a solid reason. Running monitor I see this event:

08:42:53 248652094mS H323Evt: GK: Unregister endpoint H323Phone_5461c6d821ed62fa for extension 6076 reason 3
08:42:53 248652097mS H323Evt: GK: Send URQ

The majority of the reasons are 3, but occasionally 2 or 4. I also can not find what these reason codes mean.

Typically, from just some simple google searching, this might be a DHCP or PoE issue. I've triple checked my DHCP server and also made sure it is the only one handing out IP addresses. I've also made sure my PoE switches are up-to-date with the latest firmware and that I am not even close to the available wattage that the switches are capable of handing out.

The switches are Netgear ProSafe GS728TP, and the remote firewall is a Sonicwall TZ215 connected via VPN to a Sonicwall NSA 2400. I do not have this issue in the local office where the IPO is, so it makes me believe it is a networking issue. Although I can ping each phone without any timeouts and also be on a phone call with one of the users in that office and the phone will reboot mid conversation.

My next steps will include, trying a different PoE switch, isolating the VoIP traffic on a separate interface on the sonicwall, and also try using the phone via the public interface on the IPO vs traversing the VPN tunnel.

System is an IPO 5v2 - 9.0.4.0 Build 965.

Any similar experiences or further diagnostics I can run would be appreciated.

Thank you,
Denny

 

[dmaderi1]

I may have accidentally stumbled upon the answer assisting another tek-tip user! I really hope this helps someone else that might be experiencing this type of issue. So here goes; At my central office I have a Sonicwall NSA 2400 with 2 WAN connections that I load balance and do simple rollover on a probe failure. Yesterday another Tek-Tip user needed assistance with SMTP setup on their IPO. So I went ahead and set it up on my IPO. After getting a successful monitor output I posted that to the thread. Now in my email, every time the phones restarted at the remote location I would get 2 emails:

1st:
The phone with id 8005 has been removed for extension 6076

2nd:
The phone type 9608 (id 8005) has been plugged in for extension 6076

I thought, perfect now I don't have to review monitor logs I can just review it in my email. An unrelated event happened later in the day that made me review the Sonicwall Logs. During the review I noticed an entry about WAN Load Balancing fail over, remember this is at my central location, I've been concentrating my efforts at the remote location to try to find the issue. So I filtering for just WLB entries and it returned quite a few results. The time stamps looked familiar, comparing them to the emails I am receiving every time a phone restarts there was a correlation. So I turned off load balancing, low and behold the reboots have magically stopped.

I need to open a ticket with Sonicwall as I am certain this is not the expected behavior since I only have a primary gateway setup on the VPN connection, it doesn't even know about the other WAN connection. The other odd thing about it is that I have cmd windows open up that are pinging each phone and the remote site's LAN IP address and even during the WLB Fail overs not a single time out request. That makes it even more baffling.

I really hope someone else benefits from this post, I've been struggling to find an answer for this as it never occurred to me that Load Balancing would have anything to do with it.

-Denny

 

[amriddle01]

Sonicwalls are the spawn of the devil. We recently proved one to be at fault bringing down a customers leased line every 30 - 40 secs, it was responding to all ARP requests for every address in it's WAN range including its own default gateway...pile of sh1t

 

[dmaderi1]

Well we will have to agree to disagree. I've had plenty of experience with Sonicwalls and although frustrating at times, as with any piece of equipment, once setup they generally perform as expected and with little intervention. It's the odd ball stuff that is frustrating and time consuming. Hopefully you or your customer worked with Sonicwall tech support to resolve the issue as I will do with this problem.

Denny

 

[amriddle01]

Sonicwall said they fixed that ARP issue in a previous release and didn't know why it was happening (after couple of days of try this/try that). Customer changed the Sonicwall out for different firewall and all was well..... Not the first time that solution has been the only one to fix odd issues in an acceptable time frame