Can't get WFH phones working over VPN



I’ve been sending workers home with their phones to use over newly setup VPN connections, so that they can work from home during this virus outbreak. VPNs are IPSec gateway to gateway and all seem to be working for filesharing, RDP, and to a degree VOIP.

That is to say, users that I’ve sent home with Linksys and Yealink phones are having no problems making and receiving calls. Users with Grandstream phones (GXV3240 & GXV3275) are not working. I was skeptical at first, but I now have a 3240, 3275 and Yealink T58V sitting on my desk at home. All are using POE. Only the Yealink is connecting to my Asterisk box in the main office. In my case the Asterisk server is running behind a Watchguard M270, and the three phones on my desk are running behind a Cisco RV325.

I have done hardware resets on both Grandstreams, and installed the current firmware on both. Configuration is vanilla basic - SIP server IP, user and authentication id (the same), and SIP password. Under account network settings I’ve tried NAT Transversal as follows:

NAT No: Unknown NAT
STUN: Port Restricted Cone NAT (STUN)
Keep Alive: Port Restricted Cone NAT
UPnP: Port Restricted Cone NAT
Auto: Port Restricted Cone NAT
VPN: Port Restricted Cone NAT

The Asterisk server is on a subnet, and my phones are on a subnet. The Yealink has NAT disabled, and works perfectly. What’s the secret to getting these up and running over a VPN connection?

Thanks for your help,



usually stun settings if no vpn… works…


If using a VPN…then nat should be no or keep-alive if the VPN requires packets to maintain the connection. Stun should not be used. The issue is most likely that the remote subnets are either not set in the pbx or the remote subnets are set to the same as the local ucm lan and the VPN does not know how to handle. Add the remote subnets into your pbx so it thinks the remote phones are local and will message them as such.


Don’t you think that it’s odd that you’re saying add the subnet to the VPN to make the Grandstream work when the Yealink already works without the subnet in Asterisk? Regardless, I tried adding the subnet, and went through all of the NAT Transversal options again but it’s still not working.


Looks like it’s a bug with Grandstream, as the competitors all function normally. I opened a support ticket.


It is not a bug. I did not indicate to add to the vpn. I indicated add to the pbx. And no, I do not think it odd at all. There is no NAT when using a VPN. If using IPsec, you should have already defined the remote subnet on each VPN capable router. I have the phones operating across numerous IPsec VPNs across the country without issue. I have them on Draytek, Mikrotik, Barracuda, Cisco and other routers. I have Watchguards on a site-to-site with a PBX on each end exchanging phone traffic.

Just because one make may work or even two or more, means nothing. If you factory reset the phone,as I have no idea of the other settings, and then simply hook it up the remote network and allow it to get an IP, can you get to the web interface and log in?


I apologize, I typed add to the VPN but I really added (as you suggested) the subnets to the PBX - despite the fact that both Yealink and Linksys were already both connecting to the PBX without having the remote subnets explicitly defined in the PBX. You’re right, it may not actually be a bug - perhaps it’s just a feature that hasn’t been implemented. Regardless, there are now Grandstream engineers working on the problem and I’ve been supplying them with additional information. Hopefully it will get resolved soon as it makes these phones useless to me in remote office scenarios.



GS need to make the VPN secure as well or it is not viable.


It is not a GS issue. GS does not do the IPsec tunnel, the routers do. The phones are nothing but a client that sends data across the tunnel to the defined SIP server and providing the SIP server is sending back the correct connection and contact headers to the phone, the phone will respond to the internal local IP of the UCM.


@lpneblett we need an SBC similar to the other vendors for GS handsets…


Why? There is no NAT. What does an SBC bring to the table for a closed network already? I have IPsec site-to-site all over the place and I am at home now with a GXV3275 sitting on my desk and I can reach any extension I so choose as my office or at my other location in Dallas and the others can reach me equally well.


Musnt be with GS Phones direct… which Firewall are you using for those style connections? GWN7000 ???


Draytek, Barracuda, Cisco and why not, you have not answered that aspect yet. The phones look local.
Here is one site that has GS at each location and all work just fine.

Just a sample of the extensions from one of the above, note the IPs.


What have I not answered? My Asterisk box sits behind a Watchguard M270, and the VPN tunnel that I’m testing with sits behind a Cisco RV325.


Can you reach the web gui of a remote GS phone?


From the Asterisk side of the pipe I can configure the remote GS phone. From the remote side of the tunnel I can configure the Asterisk box.


@lpneblett larry, re the SBC - I think that GS need to help those that are not as tech savvy as you or others here on the forum with equipment that will safely and securely allow the device they are placing on the network to gain access to the internet instead of them opening up firewalls and allowing the myriad of issues that occur when that happens.

1 x box is all that is needed from GS to be able to recognise and deploy correctly. Or a sheet of paper inside warning the user of opening the internet connections or some other warning…

You are better at writing than I, Larry why not offering GS advice to overcome things like this and limit the countless hours in documentation that is written by the likes of yourself, unless you get paid as a donation/payment of some description by the end user which is fine also.


While it might be nice for GS to consider some form of an SBC, one is not currently available.

Additionally, no matter which method one chooses to employ when trying to remote a phone, there is always some setup to be done and an SBC is no different, but you are correct in that it would overcome some of the issues with folks having to mess with SIP ALG and security. But then a VPN does this as well.

In this case, there is a tunnel, it is established and it should be working, but for some reason it is not. The issue is, that we do not understand why it is not and the only way to understand that is to get a capture and see what the messaging is telling the devices to do. We have little idea of the settings on the phone or the PBX. What we do know is that he had tried every NAT setting in the account network settings on the phone to no avail and that he apparently has both Yealink and Cisco working, and he can reach the Web Gui of the phone. Comparing one make of device to another in a given situation with no understanding of how either is set, is pointless. While it is nice to know that a given make does indeed appear to work, that does not help me understand why the other make does not, when I know it should.

I have suggested and offered to examine the pcap files to see if there is something in the messaging, but so far, this has yet to happen.

The 3CX SBC runs on a Raspberry Pi and can currently support up to 30 phones with 10 BLF each. I am somewhat surprised that someone else has not done something similar (maybe they have), but my guess is that it’s a pricing issue as this is a very low cost solution, but it may come with very high support costs. OpenVPN should also resolve much of this, but it too seems to have challenges in the complexity of how it needs to be configured.