We have a Grandstream UCM1064 behind our Balance One. We have no issues making or receiving calls to the handsets within the network. We have many handsets outside of our network. They can get voicemail, make and receive calls. However, there is no sound on the calls in either direction.
The handsets in the office worked with the default configuration. We added an outbound policy with enforcement to a single WAN. We also configured 2 inbound forwarding rules for 5600-5604 UDP and 10000-2000 UDP. Is there any thing I may be missing?
I suspect you might have not entered the external IP address of the WAN you have allocated to the Grandstream in the Granstream settings. Check to see if the “External IP address” under PBX\SIP Settings\NAT is missing.
Thanks for the response. We do have the external address filled in. We were using a Netgear 4 WAN router previously with the same ports forwarded and the handsets were able to connect without issue.
Larry, I have dealt with this issue as we are a long time SIP user. When the remote handsets try to connect to the server, they are initiating an inbound connection to your SIP server. You have correctly forwarded the ports, but you have not yet opened the firewall for those same ports.
You need to make an inbound firewall rule to open ports 5060-5064 (not 5600-5604, maybe you mis-typed here), and 10,000-20,000.
The problem is that by doing this you have exposed your SIP server to all the bad people in the world. At some point they will figure out you are operating a SIP server and they will attempt to log in as a phone. Your choices are to tolerate the attempts (which puts a load on your server), or restrict the inbound rule to certain IP addresses where you have remote phones. If your remote phones are only operated at a small number of IP addresses it is practical to write rules restricting access to those locations. If you intend that remote phones can be operated from anywhere, you’ll have to leave the rules open that way and deal with what may happen.
If your remote phones are operated only from remote locations which are already connected to home via VPN, you can program the phones to use the LAN address of the server instead of the WAN address. We are able to use that method for security, which means we don’t need inbound firewall rules at all.
Thanks, I’m still banging my head here. I see that the default inbound firewall rule is to allow Any to Any, so I don’t think that is the issue. I did put in the specific rules to see if that helped, but no luck. On one remote handset I changed the Audio to G.729(A/B) and it worked, but not for other people, Also, none of the soft phone apps (Zoiper or Grandstream) can connect at all.
As a side note, it seems that the firewall inbound rules are meant to be an secondary filter on the port redirection and not the first line of defense, do you agree?
VoIP can be a real pain the butt. The only way to really know whats going on is to grab a network capture on the support.cgi page of the balance one when a remote handset makes a call and then trawl through the SIP messaging to see what isn’t configured properly.
As for your question about the firewall. By default the firewall is set to allow Any to Any within the restrictions of NAT and PAT. So if you haven’t opened any ports / services then inbound traffic is blocked - unless that inbound traffic forms part of the session communications between a LAN device and the WAN (over NAT).
I am trying to get this working now myself, and can’t get it to work. I have inbound 5060-5065 and 10,000-20,000 pointed to the server LAN address. I have those same ports open on the firewall.
When I connect with a remote phone, the device registers but there is no audio, same problem. Looking at Status > Active Sessions, I can see the inbound registration on port 5060. I should also see an RTP audio stream on a port somewhere between 10,000 and 20,000, but that session is not shown. Its clear that is the problem.
Just to test, I changed my default firewall rule to Allow any to any inbound. No change in the problem so the firewall is not the problem. I changed it back, would definitely not want Allow Any to be the default. Martin I"m curious, maybe you typed it wrong above. If the default is Allow Any to Any, why would that block traffic? I would have assumed Allow Any to Any means completely open inbound flow.
I still don’t know if this is a port forwarding problem, or a firewall problem, but its clearly one or the other. Its not an Asterisk server problem, because if it was the phone would not register and the session on 5060 would not be active. On the remote side I’ve tried it through both wifi and cellular, same result, so I don’t think its being blocked at the remote side.
Martin, I did try compatibility mode, but that made no difference. What exactly does compatibility mode do?
SUCCESS, I was able to get this working. Port forwarding and firewall as described above, PLUS Service Pass Thru > SIP Compatibility Mode
At one of our locations we have an Untangle firewall behind the Balance router. The SIP server is listed as bypass in the firewall. The bypass works fine for all other SIP communication, but for some reason will not allow the RTP 10,000-20,000 to work. I went to one of our other locations which does not have the Untangle firewall, got it to work there.
Ok, so after setting up everything and reviewing it every which way, I finally found out that I transposed numbers on the Port Forwarding, Now the remote handsets are working, but we can’t get the Grandstream or Zoiper app to work from mobile devices. Does anyone have any ideas?
Larry, I’ve had the remote handsets working for a few days now. Looking at my inbound sessions on the Balance, I can see constant multiple SIP registration attempts from all over the world. Germany, Netherlands, Canada, and some countries I don’t know where they are! These people will do anything to make free phone calls, who knows where they are actually being routed from. They may not be able to actually make call but their constant attacks will put a huge drag on our phone server.
I’ve turned off the open ports. The alternative is to set up an L2TP VPN remote access for your users. Even the iPhone natively supports L2TP. If they leave the VPN active, the SIP software will register using the LAN address of the phone server. Meanwhile the phone server doesn’t get attacked all day long because the Balance firewall blocks the attempts. You really should consider changing that inbound firewall default rule to Deny, instead of Allow.
They aren’t just doing it for free phone calls, they mostly do it to dial 900 numbers which they are affiliated with. Those charges come from the 900 provider to the telco and then are passed on to you. That’s when the telco says “sorry, should have secured your PBX better, here’s your whopping bill that you owe now.”
)