Connecting remote GXP 2170 to office UCM 6104



Hi everyone- I have an employee that just moved out-of-state and I am trying to get her setup so that her phone works remotely. I input the ip address of my ucm and opened the ports on the router here, so the phone connects and we can initially make calls. But then the phone drops off. What else do I need to do? The phone drops off after a few minutes and then her extension no longer lights up. Thank you.


Anyone know how to keep the connection alive after it is connected initially?


Hmm. Is the remote phone behind a NAT router? Try setting Accounts->Account n->Network Settings->NAT Traversal to “Keep-Alive” in the remote phone. Or open ports for the phone in the remote router. I’ve never done this so these are just guesses.

It’s probably a bad idea to open a whole bunch of ports in either router. There are lots of people running port scanners looking for open ports to exploit. Much better is to use a VPN to support remote phones, now that GXP21xx phones support OpenVPN. You can use OpenVPN support built into some routers (on the office end), a software implementation of OpenVPN on a workstation at the office end, or install a simple Raspberry Pi OpenVPN server. These are available preconfigured on eBay (search for “Grandstream OPenVPN”), or you can build one yourself. There are several threads that describe ways to set this up.



Did you figure this out?


I’ve got a couple phones setup like this. Here are my thoughts.

  1. Don’t use the default SIP port 5060 on the firewall. You could leave it as 5060 on the UCM and setup port forwarding from some random port eg. 62111 to 5060 if you like but I prefer to match them. This is for safety to help reduce hacking.
  2. Ensure fail to ban is on and configured conservatively.
  3. On the phone itself, ensure you’ve turned on Authenticate Incoming INVITE to help prevent ghost calls.
  4. Ensure the customers firewall is configured with the same SIP port and RTP ports as the UCM. There are a couple of work arounds to avoid needed to configure firewalls but, I’ve found it to always be more reliable. I’ve sure others would have a dissenting opinion and, well, they could be right.

Good luck!


Grandstream has a guide on how to set-up remote phones using STUN.

You may also want to consider using a VPN (as suggested) which will avoid much of the configuration headaches.

You did not mention the phone model, but instead used a thread from 5 months ago, so am unsure if the same situation.

There are other ways of setting up remote phones, but it depends on the situation and the following is not meant to be the definitive guide as there is more than one way in many cases -

When the UCM is communicating to phones locally behind the same NAT, the phones know where the UCM is as you told them what IP to use (the UCM) when you provisioned the phones… Conversely, as the phones are connected to the same network, they in-turn told the UCM what private IP/FQDN to use when they registered.

The challenge is how to do the same with a remote phone and how to overcome the issues of getting messages to traverse the remote firewall in order to do so. The phones still know how to contact the UCM as you populated the phone with the UCM’s public IP and (hopefully) have port forwarding in place at the firewall at the UCM side.

But what about the remote side?

The first thing to consider is how is each side setup with regard to their respective IPs? Are they static, one side static and the other DHCP, both DHCP, is DDNS being used and the FQDNS are? Each side of the connection must know how to contact the other side.

The UCM should have a static Public IP and failing that, a FQDN with DDNS. Next, is the issue of whether or not you have access to both routers. Next, how many remote phones are there behind a single firewall? And finally, the cost.

If the remote side is behind a firewall that has a static public IP, then you can consider using the NAT IP setting within the phone or perhaps a VPN (the cost issue if a new router is needed). You can use STUN, but there is no advantage to it.

If the remote is behind a firewall whose public IP is not static and no FQDN, then you can consider STUN and should follow the guide.

If the remote phone is behind a firewall whose public IP is not static, but DDNS is in use, then you can consider STUN, NAT IP using the FQDN or possibly a VPN.

No matter the case, a static IP is always preferred, but, as we all know, not always possible.

If there are many remote phones behind the same firewall, then a site-to-site VPN is preferred.

The remote phone(s) will require a private static IP if port forwarding is to be used. And it is advisable to set each remote phone with its own private static or reserved IP regardless of method if possible.

Many routers have a SIP ALG or SIP Helper and these need to be disabled in most cases. They essentially assume a lack of intelligence behind the NAT and then try to alter the messaging to what it thinks is needed in order to facilitate the external communications. Many fail at this.

Once the UCM knows the IP of the remote site, then the issue is how does the UCM messaging penetrate the remote firewall and get to the needed phone? Port forwarding is one way assuming you have control of the remote router. Otherwise, you will need to use STUN and/or keep-alives.

When a phone registers with the UCM, this will be successful as the remote phone initiated the request and the router allowed the outbound traffic and then kept the port open for the next 32 seconds or so in anticipation of a reply. So…after the 32 seconds or so, the ports close and any UCM originated messages following fall upon deaf ears. The keep-alive function will usually overcome the closure by sending a data packet every so often in an attempt to keep the ports open. There is a frequency setting by which you can set the send interval should the port closure have a different timing. So by port forwarding or using keep-alives we can now get the UCM messages to the remote phone.

When you set-up a remote phone, most will have a local SIP port and a local RTP port settings. These are the ports that you can set and it is these ports that are the ones of interest at the remote firewall as it these ports that the phone is telling the UCM to use when communicating back to the remote phone and it these ports, if you are using port forwarding at the remote site, that need to be opened and forwarded to the phone(s), not what the UCM is using ****. If you have more than one phone behind the same NAT, then it is advisable to change the ports among the phones so that no two phones are using the same ports for SIP or RTP. If not able to use port forwarding it is still advisable to use unique ports.

Some routers are better at maintaining NAT and PAT tables than others. As the phone count grows so do the odds of the router no longer being able to maintain the tables correctly; hence why setting unique ports will help. However, a VPN should still be considered.

****Some routers require rules for both inbound and outbound traffic and unless these are in-place nothing will traverse. As a result, there may be some instances where you do indeed have to set rules to allow outbound traffic for the UCM, but this is not port forwarding.

To avoid the ghost call issue, and assuming that you are not using direct IP dialing, another method is to set the phone to accept messages from the sip proxy only. The issue with the Authenticate method is that it may generate unneeded additional traffic as the phone will issue challenges to the rogue device’s INVITE which may then cause the rouge device to keep trying. The accept from SIP proxy only will only accept messages from the IP/FQDN that you entered for the UCM (SIP Server) and reject the others. There is nothing to say that this method will cause a stop, but the hope is that once they see the rejection rather than the challenge, they will move on.

The suggestion that having the private side port set to 5060 and then using 62111 (or other) on the public side is not practical (port translation) for VoIP/SIP. The devices construct messages to one another indicating what IPs and ports to use. Therefore it is not possible for a device to indicate in the contact header to use port 5060 and then expect the remote side to send to 62111. VoIP will only function correctly and reliably when using one-one-NAT(full cone). If port 5060 is the SIP port, you should forward 5060 and the same one-to-one relationship for the RTP ports. You can port translate the UCM web port if needed. Just be certain to use caution and common sense so as to protect yourself.

Finally, the remote extension needs to be examined in the UCM extension settings for NAT and can direct media. These settings may need to be adjusted in the event of one-way audio for example (Assumes SIP ALG is NOT in play).

Remote phone GXP1782

Wow. Thanks for all that information.

I have a couple of remote extensions that work fine in spite of doing a few things that are questionable. I use a standalone OpenVPN server on the same network segment as the UCM. It is behind a double NAT, both of which have a (non-standard) OpenVPN port forwarded. The IP address is handled by a DDNS, updated by the OpenVPN server machine, an arrangement that has not given trouble. The remote ends do not have fixed IPs or port forwarding of any kind; the phones initiate the VPN connection and everything just works after that.

It’s cheap and easy, and doesn’t give me any trouble. If anyone wants details, PM me.



If the phones themselves are using a direct OpenVPN connection from the phone to an OpenVPN server that feeds onto the same local LAN subnet at the UCM I would think that this setup avoids all the routere & NATing issues that would be of concern when coming in directly from the Internet.

Phone <-> OpenVPN Server <-> UCM

Am I missing something?


Nope, you’ve got it right. I might have been a little confused when I wrote that, but everything I said is true. A simple OpenVPN server is an alternative to dealing with the risks and complications of a direct connection or the expense of a router with OpenVPN support.



If you are tunneling through the 1st firewall such as with a VPN relay, and then hitting the second firewall which is also doing the same (relaying) to reach the VPN server, then NAT is not an issue.If you are indeed forwarding, then it still may not be an issue as the data is still encapsulated and encrypted until such time as you get to the server and it feeds the UCM which may still not be an issue as the firewalls have no idea about the contents and therefore cannot manipulate the data.

What I am uncertain of is if the VPN server is sitting behind two firewalls, then I do not know how it would understand the DDNS change unless there is a client side updater that is used in conjunction with the DDNS service. May routers support this function and I would, if possible, move it to the router closest to the Public Side.

The only question i have is - why two firewalls in series with one another (double NAT)?

I do assume that the VPN is generating traffic virtually all the time and suspect that because of this, the ISP sees this and as a result, the provided IP seldom changes. If it does, then you may see a problem as it will depend solely on how long it takes the new IP to propagate so that any name resolution by a device gets the “current” IP. from whatever DNS server they use and if a cached DNS then this could take some time. .


Thanks for your comments.

The DDNS uses an updater running on the VPN server (which is a Raspberry Pi running Raspbian Linux). The updater is by my DDNS provider, I assume that DDNS uses a short expiration so changes propagate quickly. In any case, I haven’t seen any problems. although I think the only IP address changes I’ve experienced have been the result of moving the VPN server to a new host – it seemed to get the new address without any delay when that happened.

Why a double NAT? The client is sharing their internet service with a couple of tenants. To keep the networks separate I put additional routers connected to the top-level (ISP) router, one for each user. There’s probably a better way to do this, but what I did was easy and seems to work fine.




Regardless of how unconventional it is, I am a firm believer in that there is usually more than one way, and if your way works and everyone is happy, then quietly sneak into the dark, don’t touch anything and let the good times roll. There is another saying that goes along with this, but really not suitable for the forum.