My telco just started offering Netvanta 7100 PBX's. Our Nortel BCM was hit by lightning and is end of life so I went with the Netvanta. I have a Sonicwall TZ 205 at this particular branch office. The couple 7100's my telco has installed used the 7100 as the router. I like some of the features the Sonicwall provides but it's proving to be a bit difficult for us to get worked out. As it stands right now, I have a double NAT with the Sonicwall and the Adtran. I have a NAT translation and access rule configured for adtran public IP to adtran private IP. I've also defined a group of ports to forward. I am able to dial out and receive calls but the inbound voice cannot be heard.
I'm not opposed to changing my network configuration but I will need to keep a VPN tunnel to our corporate office, which is on a Sonicwall NSA3500. I have 3 options here; figure out why it's blocking inbound calls when behind the Sonicwall, set up a bridge port on my Sonicwall to utilize the gateway antivirus / antispyware features and give the Adtran a true public address, or scrap the Sonicwall all together and set up the VPN tunnel on my Sonicwall.
Beginning with option 1, what are the specific ports I will need to forward on the Sonicwall?
If a different option is the most reliable in this situation, I'm open to suggestions.
Thanks. Upgrading the firmware did resolve the issue. However, a combination of issues and resolutions brought me to the point where 2-way audio is now working. My first issue was double NAT. 2-way audio was working at one point during this then a network change brought back the 1-way audio. In the meantime, I upgraded firmware on the 7100 without upgrading phone firmware. The network issue was resolved then it didn't make sense as to why I still had 1-way audio. The firmware fixed that.
Technically, I should really mark a couple of these posts as correct answers, hah. In any case, thanks for the help. I hope to have this system integration completed by the end of the week.
Hello,
Here are a couple ways to test to see what is going on,one way is to see if you run a packet capture with Wireshark between your sonicwall and the router or modem it is connected to. YOu want to look at the From field IP in the SIP message and the C=IN attribute in the SDP to make sure they are the public IP on the Sonicwall and not the Private IP of the 7100 0/0 interface.
Another way to test this is to move the 7100 to a X1 or X2 port on the Sonicwall and configure it as a DMZ and give the 7100 a Public IP on the Eth 0/0 port. This will rule out if NAT is problem in the Sonicwall.
Regarding your question above, the only port you need to open on your sonicwall is UDP 5060 for sip traffic. I would specify a source IP of your remote site so that the port is not wide open.
Hope that helps, let me know if you have any questions.
-Mark
I won't have a chance to try those suggestions until this evening. I can't knock them offline so I have to wait until everyone in that office leaves for the day. If I decide to get rid of the Sonicwall and use the Netvanta 7100 as the router, I'll still have to configure a VPN tunnel to our corporate office Sonicwall. Is there a definitive guide to configuring VPN tunnel between the Netvanta and Sonicwall? I've looked through the options but have not messed with them yet. I'll need to bypass the Sonicwall to configure the VPN on the 7100.
I am not aware of a document between the 7100 and a Sonicwall VPN gateway.
Here is a good document for configuring VPN with the NV 7100:
https://supportforums.adtran.com/docs/DOC-3455
Here some some posts where other people have configured a NetVanta to VPN to Sonicwall:
https://supportforums.adtran.com/message/2152#2152
hope that helps.
-Mark
Thanks. I'll check out both of those. I'll be digging into this more this evening or tomorrow. I tried to work on it last week but they worked late the only day I was available.
Historically we have had very poor luck with VoIP behind Sonicwalls, and double NAT is asking for trouble. If you have sufficient public IPs or ideally a /30 with a routed block behind it, I'd use the 7100 as the edge router and create a public interface for the Sonicwall behind the 7100. Now the 7100 can handle QoS, etc.
Use the 7100 to NAT your voice VLAN directly. Have the Sonicwall deal with VPNs and antivirus to your data VLAN.
You may want to firewall the voice VLAN on the 7100 from general web surfing to prevent a computer that "accidentally" lands on the voice VLAN from bypassing the Sonicwall antivirus.
I am now able to send/receive calls with the Adtran behind the Sonicwall. I'm using the Adtran basically as a switch and passing all DHCP requests to the Sonicwall. I am having one small issue though. I have the WAN interface configured with a public IP and it's plugged directly into my ISP's router. I have a route defined on the adtran for traffic from it to use next hop of x.x.x.233 which is my ISP's router. My ISP did a packet capture and my voice traffic is still traversing over the Sonicwall. I would hope to send all voice traffic over the WAN then lock it down to receive only traffic from my ISP's controller. Any idea on why this is the case? The phones are set to use the Sonicwall as the default gateway. Could that have something to do with it?
I'll readily admit that I'm not a networking person. I can set up basic networks, wireless bridges and the like but when it gets into advanced NAT and routing, I'm lost.
I could not use the Adtran as the edge router. I'm integrating this into a network and using existing network cabling. The PC's will be plugged into the switch port of the phone so I had to leave the Adtran behind the Sonicwall. This network has a total of 50 nodes, including phones, so I'm not too concerned with VLAN.
sasiki wrote:
I am now able to send/receive calls with the Adtran behind the Sonicwall. I'm using the Adtran basically as a switch and passing all DHCP requests to the Sonicwall. I am having one small issue though. I have the WAN interface configured with a public IP and it's plugged directly into my ISP's router. I have a route defined on the adtran for traffic from it to use next hop of x.x.x.233 which is my ISP's router. My ISP did a packet capture and my voice traffic is still traversing over the Sonicwall. I would hope to send all voice traffic over the WAN then lock it down to receive only traffic from my ISP's controller. Any idea on why this is the case? The phones are set to use the Sonicwall as the default gateway. Could that have something to do with it?
Yes, absolutely. If the phones have the Adtran's IP as the gateway they'll traverse the Adtran.
I could not use the Adtran as the edge router. I'm integrating this into a network and using existing network cabling. The PC's will be plugged into the switch port of the phone so I had to leave the Adtran behind the Sonicwall. This network has a total of 50 nodes, including phones, so I'm not too concerned with VLAN.
You'll want to use VLANs. Best practice for QoS, and essential if the phones themselves will have a different policy than the PCs behind them. Create a voice VLAN, have the phones use it with DHCP from the Adtran. Use a different native VLAN for data, and the computers including those behind the phones should be on that, with the Sonicwall as their gateway.
Use different RFC1918 subnets for voice and data.
I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post to unmark it and select another in its place with the applicable buttons. If you have any additional information on this that others may benefit from, please come back to this post to provide an update. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
Thanks,
Matt
I was able to set up the VLAN's and have VoIP traffic traverse the Adtran while PC traffic traversed VLAN1. However, I still had 1 way audio issue (I couldn't hear the incoming caller). The fix for that was enabling Simple Remote Phone. I don't feel like I should have to enable that though when the PBX is handling all routing and data for the IP sets. I feel like something in the Adtran is not quite right. Any ideas on a configuration change I can make so I don't have to use that option?
You should not have to enable Simple Remote Phones to get bi-directional audio. If you can submit your configuration and a network diagram to the FTP server with the instructions below, I would be happy to take a look.
Open Internet Explorer web browser on their PC
Type the following URL: ftp://ftp.adtran.comPress the Alt key, click View, and then click Open FTP Site in Windows Explorer
Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer windowReply to this post with the exact filenames used so we can retrieve the files
Thanks,
Matt
filename is adtran7100dip.txt
After reviewing your configuration, here are some suggested firewall configuration changes:
!
ip policy-class Private
allow list MATCH_ALL self
nat source list MATCH_ALL interface eth 0/0 overload
!
!
interface vlan 2
ip address 10.10.20.1 255.255.255.0
ip access-policy Private
media-gateway ip primary
no shutdown
!
!
ip access-list extended SIP
remark allow SIP from provider
permit udp host x.x.x.x any eq 5060
!
ip policy-class Public
allow list SIP self
allow list Admin self
!
interface eth 0/0
ip access-policy Public
!
!
interface vlan 1
ip address 10.1.2.2 255.255.255.0
ip access-policy Private
no shutdown
!
Also, I wanted to mention the VPN configuration was incomplete as the peer statement was missing from ike policy 101.
Thanks,
Matt
VPN is fine as incomplete. I ended up not having to go that route. I'll get that cleaned up though. I'll also try these suggested changes. I will let you know if this takes care of it.
That did not seem to fix the problem. I re-enabled simple remote phone and it worked. I'm uploading the new config called adtran7100dip2.txt. This has simple remote phone disabled. My test extension is 242 if you want to look at the config of the set. I'm new to AOS so I hope I edited the config properly. It appears to have reflected the changes you suggested.
It looks like the policy-classes have duplicate entries:
!
ip policy-class Private
allow list self self
allow list MATCH_ALL self
nat source list MATCH_ALL interface eth 0/0 overload
allow list MATCH_ALL self
nat source list MATCH_ALL interface eth 0/0 overload
!
ip policy-class Public
allow list SIP self
allow list Admin self
allow list SIP self
allow list Admin self
Try taking out the duplicates. If that does not resolve the issue then upload a new copy of the configuration and in a separate file include the output from a debug sip stack messages and debug voice verbose both enabled at the same time while you make a test call.
Thanks,
Matt
Remove duplicates did not work. I'm uploading 3 files.. current config, test call with simple remote enabled which does work, then simple remote disabled which has 1 way voice. They cannot hear me when i call but I can hear them. file names are "FW simple remote disabled.txt", "FW simple remote enabled.txt" and "FW config.txt"
It looks like this issue is related to the IP 700 firmware the phone is running (v1.3.13). In the NetVanta 7000 release notes for each version of AOS there is a section that details minimum phone firmware requirements. For the , page 6 specifies that R2.3.0 or later is required. You can download it from this page and use the guide. If that does not resolve the issue let me know.
Thanks,
Matt
Thanks. Upgrading the firmware did resolve the issue. However, a combination of issues and resolutions brought me to the point where 2-way audio is now working. My first issue was double NAT. 2-way audio was working at one point during this then a network change brought back the 1-way audio. In the meantime, I upgraded firmware on the 7100 without upgrading phone firmware. The network issue was resolved then it didn't make sense as to why I still had 1-way audio. The firmware fixed that.
Technically, I should really mark a couple of these posts as correct answers, hah. In any case, thanks for the help. I hope to have this system integration completed by the end of the week.