DT700 VOIP Phones at remote sites on NEC SV8300

[abayham]

We've got an NEC SV8300 set up at our main company site, and would like to set up a couple of DT700 VOIP phones at two remote locations off-site. While they will connect and operate normally on our local network, we've been unable to get them to connect and be recognized by the 8300 from the remote locations. The error message on the phone is "SIP Server Not Found".

We've gone through the port forwarding process on our Sonicwall NSA as outlined in some other threads (all written for the 8100, but hopefully the 8300 is similar) and we can see the network traffic when the remote phone tries to connect to the 8300, but it seems the 8300 will not or cannot respond to establish the connection. We've also tried setting up a site-to-site VPN to tunnel in to the local network, but no luck there either. It's almost as if the 8300 will not respond to attempted connections that are routed through the firewall in any way vs. simply communicating across the local network. We've tried toggling many of the NAT settings on the phone and none of them have had an effect. And since we can see the network traffic on the firewall when the phone tries to connect, and we can see the traffic get routed to the local IP of the 8300 (same as the others use locally), it seems like this is a problem or limitation on the 8300 and not the phone or the network.

I was able to find this thread thread937-1616535, but it's unclear if that poster found a resolution. Has anyone else battled this problem, specifically on the 8300? We're beating our heads against the wall here!

 

[belevedere]

SIP Server Not Found" means that it cannot see the IP address of the CPU at the main site. Can you ping it from a phone or PC at the remote site? Also check your settings in the IP phones for proper port settings.
See

http://www.nectekhelp.com/docs/8300/SV-8300 DT 700 IP Phone Set Up.pdf

for cheat sheet.

 

[abayham]

Hi belevedere,
Thanks for your quick response, and I apologize for my delay. Shortly after this post we got waist-deep in site-to-site VPN configurations while using Wireshark and consulting with our local NEC distributor and Dell.

Ultimately we were told by NEC that NAT using a public IP address is not an option with the SV8300 (though it seemed plenty of users online were able to successfully use NAT to connect remote phones on the SV8100). I'm also told Dell Sonicwall NSA's (we have a 3500) are especially complicated when it comes to VoIP traffic - they're almost too smart for their own good and they fudge up the packets using different filters and translations. To make matters worse, our networks are designed in such a way that all our local phone traffic at the main site is on its own independent network, accessible thru an interface on the Sonicwall, but not really managed by the Sonicwall, so it was a process of trial and error using NAT Policies and Firewall Rules to have the Sonicwall translate and route the traffic appropriately from/to the VPN's and the local phone network, but not "process" the traffic at any deeper level than that. You'd think that would be fairly simple, but there were some straight-forward common-sense rules and policies that didn't work, and other counter-intuitive ones that finally did the trick.

Other than the fact that the SV8300 can't handle NAT over a public IP, the issues were entirely Sonicwall-related. Once the VPN's were set up and connected in a hub-and-spokes configuration, the solution was to turn off all of Sonicwall's native VoIP options, and then add local NAT Policies and Firewall Rules to allow and properly translate traffic from the local (segregated) phone network to each of the respective VPN's and vice versa.

Hopefully this helps some other SV8300 owners out there. I doubt many will have a configuration as complicated as ours, but if the specific NAT Policies and Firewall Rules we used can help someone out there, let me know and I'll be happy to provide them. Thanks again!

 

[R8DERN8TION]

abayham,

We are experiencing the same issue here with our SV8300 and Sonicwall...Can you please provide the NAT Policies and Firewall Rules you used to resolve this issue?

 

[abayham]

Hi R8DERN8TION,
I'm happy to shoot those over to you, and Sonicwall GUI screenshots may be the easiest way to do that. But it might help if you give us a quick rundown of how your networks, VPNs and sites are set up, so I can give you some context along with the rules and policies. There may be some you need that we didn't, and vice-versa. And you'll obviously need to adapt them to your own setups, so if we have an idea how our setups differ, I can help with some insight there as well.

It its basic form, you need VPN's set up between your main and remote sites in a hub-and-spokes configuration, with multiple tunnels allowing traffic from one VPN to the other. If you need help on that front, I'll see if I can pull up the Dell walk-thru we used to set up ours. There was a NAT policy we used for each VPN that did the trick:

Source Original: X5 IP (all our VOIP traffic is segregated to the X5 interface on our system)
Source Translated: Original
Destination Original: X5 Subnet
Destination Translated: (The VPN set up for the remote site)

Since we have two VPN's for two remote sites, we have two NAT policies that are almost exactly the same, except for the Destination Translated setting which would be each VPN. Again, I can't exactly explain why this works, and the Sonicwall doesn't show any usage on those rules. But it does work, and as soon as we turn off those NAT policies, it stops working.

Then you add Firewall Rules to allow traffic from VPN > LAN, LAN > VPN and VPN > VPN. You can either allow all traffic to/from the VPN's and LAN, or restrict it to VOIP traffic using a Service Group and including all the ports that the SV8300 uses for signaling and voice traffic. Since the VPN's are secure and it's all internal company traffic, we left all traffic open, but let me know if you want to restrict it to those specific ports and I'll see if I can go back and look them up.

Again, if you're still having issues, I can send screenshots of our GUI and try to translate our rules and policies to your setup, but maybe the above is enough for you to figure it out? All the firewall rules were common sense, but those weird NAT rules were the key. Best of luck!