openVPN GXP21xx to UCM


Hi, ive posted this here but might move it to the GXP Phone forum…

I have a number of working UCM’s who want remote phones, i am going to be testing openVPN on the GXP21xx series, it appears in 2016 openVPN wasnt working, however there have been quiet a few updates since.

SO the openVPN server (separate appliance) gives me a certificate file and ovpn file, not sure of the upload locations, however it appears the opvn file cant be uploaded to the phone (at least i cant see a location).

Has anyone got this to work with openVPN? My goal will be to put both files on the UCM, connect a phone with zero config, push the settings to the phone the take it offsite, and presto VPN connects and phone works.


@SFX_Group, I have been looking at OpenVPN on the phones for the same purpose, but using a GWN7000 as the OpenVPN server. Haven’t done it yet (on my to do list when I return from overseas), but my understanding is that the Grandstream devices don’t use an “ovpn file”, they use 3 certificate files instead.

Hope this helps.


I opened a ticket, Grandstream seem to be saying (or hinting VERY strongly) that the phones will not work with “any standard” openVPN server, needs to be a “SIP” version… go figure!!! Why on earth would they not make this standard to “openVPN” ???

I have a working openVPN server, i cant seem to get it to connect with just a username / password and the certificate as yet. It does however work with a Windows desktop PC (with the openVPN client)


I would love it if you could share how you configure a Windows 10 OpenVPN client to work with an OpenVPN server (especially if it was the GWN70000. I have never been able to find something to help me figure it out.


I list here step by step… any more info contact me offline…

QNAP (QVPN), setup for openVPN only, create a user (in QNAP), then in the QVPN make sure this user is listed for openVPN only (i removed admin, paranoid level 15).

Download the openVPN config file from QVPN (it has a download button on that tab), this is likely where the problem happens, i tried with the Windows openVPN server and it was total guesswork, the QNAP app does it all for you).

Open the *.ovpn file and change the IP address to the local one (QNAP puts your external IP address in it, for logical reasons, but for testing its internal).

Install the free openVPN client on a PC, drap the .ovpn and crt file in to the config folder, at this point once you run the openVPN on that Windows machine it will read the config (.ovpn file) and have ALL the details it needs (with the internal IP address as you changed it in the file), it will ask for a username and password (which i assume can be specified in the file but it says to ask you), put in the username / password of the user you create in QNAP and QVPN that you assigned it it should just connect (mine did), got te IP address from the pool setup in the QVPN app… the app is super simple, its NOT web managed (log in the QNAP box, clicking the app loads the window in the QNAP console).

Ive not tested by moving data, but it got the IP address. The phone didnt even attempt a login, i have a ticket open with Grandstream.

I seriously hope these phones are fully openVPN compliant but so far they seem to indicate NOT which is totally pointless as cant even use another VPN client now (as the phone only has what appears to be a seriously broken openVPN client).


Thanks. Something I will look more into when I get back to Canada.

I have seen this setup and working using a GXP21xx and GWN7000 in a demo from Grandstream. I’m pretty sure the phone does not use an *.opvn file, but three cert files instead.

And I believe someone on the forums built a raspberry pie (and then put it up for sale) with an OpenVPN sever that he got to work with the phones as well.

So it is doable and works. However, so far it’s a big black box to me as to how to do it myself. :frowning:

Wishing you luck.

I look forward to your future posts on this.


This issue i have with this, if you read openVPN the whole point was IT WAS EASY, 1 config file, 1 crt file… nothing about getting 3 crt files that you cant get from an openVPN server. It seems to elude thats its “loosely based on openVPN” but isnt really openVPN.

The firewalls from watchguard support openVPN, nothing about getting 3 crt files though, so its no good making this propriety as it means the phones cant be deployed in huge sites when watchguard $5000 firewalls are in place.

Unless i get different information of which i will update here.


Hey @SFX_Group, I’m not disagreeing with you.

I think a lot of folks would use it for remote phone connections if it was easier to implement.


Ive been looking at this most of the weekend, and a few “design” issues have cropped up which makes this really sticky unless the VPN connection is on the primary firewall (which will also be the gateway address of the UCM,so getting traffic to those phones real easy).

If the openVPN server is an appliance on the LAN and not on the gateway then routes need to be added to the UCM, and the openVPN appliance needs to be set to ROUTE mode (not looked at this enough yet), NAT would mask the IP address of the phone resulting in the UCM not knowing the real IP address of the phone when it makes contact with the UCM over the VPN tunnel.

I have no idea why Grandstream did not put a openVPN server INSIDE the UCM, this makes way more sense and clears up all of these issues, plug it in, open port 1194 on the firewall and BOOM VPN working.

Cisco used to have a VPN server in the PBX, real easy life (although real clunky, it did work)

I have a feeling there are licensing issues though with openVPN as its not “free” when it comes to the servers (see

We have external PCs able to access the LAN through QVPN (via QNAP), however again there will be 2 way issues with regards the NAT/ROUTE problem, so ive stopped testing it for now, until the below rolls outs

I have contacted Watchguard today (they have responded as we are a partner) to check out there VPN as its openVPN compliant in the hopes it works with the phones, it does have 3 certificates in it, not sure i can get them out of it though.



I now have a test Watchguard firewall (my current one was too old to get the later firmware), the current firewalls are openVPN server compliant.

The firewall has to be firmware is 11.7.4 or later (and version 12.2.1 to use the Wizard), Mobile SSL VPN is used in Routed Mode, i changed the port to 1194 (easy to do) once configured with a DHCP pool and a user is added (all real simple stuff, has a wizard if needed), the firewall will allow download of the below

  • MAC client (Watchgaurd branded)
  • Windows Client (Watchguard Branded)
  • openVPN settings file (*.ovpn), this file contains ALL 3 certificated keys inside it.

I imported this file to a genuine openVPN client and instant connection WITH routed data… I will be testing a phone in the next month or so as it appears the whole thing can be configured from the UCM (including the certificates as P-Codes), once the phone is configured it can be sent off site and its all working as expected, this would make it REAL easy to just configure then post to the end user.

This assumes you have a UCM on a LAN and a Watchguard Firewall on the permiter as security, no major IP configurations will be needed other than adding the VPN DHCP pool of IP addresses to the NAT section of the UCM.

I have already configured phones locally then sent them to other countries (Barbados) to connect back to the UCM and this works perfectly (down a site generated VPN line), so adding openVPN shouldn’t be a major issue once the correct P-Codes are included in he template of the phone.

Will update once i have more info.


This thread reinforces my sense that all this VPN stuff is insanely complicated to get working.

One time I got it working using a $70 TP-Link router.

I haven’t looked at the support in the latest firmware, but I think I remember seeing that now you can upload *.ovpn files instead of having to edit the *.ovpn file to separate out the certificates. Small improvement if true.

Yes I’m the guy who set up OpenVPN on a Raspberry Pi and got it working. I have one of them in use every day at a client site with no trouble. I’m also trying to sell them on eBay, and have sold exactly zero so far. So much for paying for the months I spent figuring out all this stuff.

The moral is: yes you can get it working, but it’s not fun and you’ll spend a lot of time fussing with it. Anything that will help make it easier is worth it.



I commend you for getting the PI working with this, i agree VPN is difficult, i have to admit though the watchguard Mobile SSL VPN with the *.ovpn file worked instantly with the openVPN client installed… i was real impressed with that.

I have a GXP2135 phone arriving this week, so will be looking in to Zero config for that phone with a VPN setup.

I have to agree, i have created many things you would “think” would sell but actually do not… its surprising.


I look forward to hearing your results.



So ive started to test the openVPN, ive had success so far with the testing with regards the P-Codes and getting the needed info to the phones (using GXP2135 on firmware 121), below P-Codes seem to work.


  • P7050 = 1 (openVPN active)
  • P7051 = x.x.x.x (openVPN server IP address
  • P7052 = 53 (openVPN port (i am testing 53, more on this below)
  • P2912 = 1 (openVPN protocol to be used (1 = TCP)
  • P8396 = 2 (openVPN cypher 2 - AES-256)
  • P8394 = username (openVPN username)
  • P8395 = password (openVPN password)
  • P9902 = CA cert (oenVPN CA certificate)
  • P9903 = Cert (oenVPN certificate)
  • P9904 = Client key (oenVPN Client key)

Using the above P-Codes has pushed ALL the VPN settings to the desk phone.

P-Code certificates
To get the 3 certificates in to the UCM, they are copied as text in to the P-Code field in the UCM, open the certificate in NOTEPAD++ (do not use Windows Notepad), ive tested this working in the GXP2135 (more on this below)

P9902 = -----BEGIN CERTIFICATE-----[hash code]-----END CERTIFICATE-----

At this point you will notice i am using port 53 (DNS), the reason for this, is so far places ive been are blocking port 1194 (openVPN), however 53 generally isnt blocked AND generally are not controlled by the captive portal, they allow traffic on that port freely (depending on the site). Clearly using port 443 is better, however i have reasons i cant use this port locally on my site.

I am testing on a WP820, however it has Zero Config issues (have a few tickets open about this), it doesnt seem to be pulling any of the “new” P-Codes, so am using a GXP2135 for UCM Zero Config and a WP820 for openVPN remote testing (configured manually in the web GUI).


We have managed to get a phone to openVPN to a watchguard firewall, however the phone then logs off seconds later. This appears to be a bug, i have opened another ticket again (second one).

However due to past issues with time spent on Grandstream support i am no longer allowed to spend more than an hour on a confirmed bug (already spent 45 mins with Watchguard to get the logs). Grandstream have the working *.opvn file, they have the confirmed log from the firewall saying it logged IN then logged OFF (by the phones request) so if they dont come back with an answer, then the openVPN client in the phones will be deemed not working with no fix provided and we wont offer then for any remote use (i have a client already saying they want to have them replaced as the openVPN isnt working).



I have spent about 40 man hours on this (Accounts will go ballistic if they find out). It doesnt work… heres my findings

GXP21xx will connect but doesnt build the route table correctly so generally will be bumped off the openVPN server, which then results in it connecting again, we then going around these circles indefinitely.

GWN7000 DOES connect to the VPN server (which is real ironic) however again it deoesnt build the route tables correctly inside the router so cant actually use the tunnel outside of the GWN7000, you can however use the diagnostic PING to get to ANY IP addresses the other end of the tunnel, so not working for a totally different reason HOWEVER it DOES connect and remain connected (this confirmed its a BUG in the phone, as the GWN7000 WILL connect and remain connected to the openVPN server.

Side note we have tried uplifting all the config from the GWN7000 and manually inputting in to the phones, doesnt work, so its an existing bug

DDWRT, ive put this in as this has the same issue as the phones, so it MIGHT be a config issue, but considering the GWN7000 does work, also ANY Windows PC with the openVPN client also works, i assume its possible to be both a BUG in the phone and a config issue as well (ts NOT a TLS auhentication issue, he phones do authenticate, they are then bumped as they dont finsih something after connecting).

Another item to understand, openVPN is END POINT, not really a routing system (assigned to a firewall as a client), clearly openVPN has a routing method (TUN over TAP setting), but when it comes to the PBX you need to know the IP subnet of the end phones, so having the phones assigned an IP address by the firewall next to the PBX clearly gives you way better control on getting RTP traffic to them (which itself is problematic at the best of times).

With the above, we have (just) stop testing firewalls (Wathcguard, Grandstream and DDWRT firmware) with openVPN being the client used inside them (the Watchguard openVPN server works well well with Windows, its scary good).

We have also written off the remote phones, due to the VPN issue as confirmed by me AND Grandstream in a ticket, i have however told Grandstream (with the config) that the GWN7000 works as an openVPN client, but as i said thats only the tip of a HUGE iceberg to get it working.

I have no idea (STILL) why Grandstream has not put a VPN server inside the PBX as this clearly would solve ALL issues, as long as the server is TLS / SSL based then your likely to have that working in all public locations.

They can call it openVPN if they want, but it clearly ISNT openVPN as no one would be asking how to get it work as openVPN works perfectly on Window with the config.opvn file and openVPN client (it works so well its scary fast to set up !

What are we doing now?
Well we have abandoned the use of all Grandstream phones remotely until Grandstream fix the “VPN client” in the phones, clearly using something “called” “openVPN” isnt working as they dont seem to work with ANY 100% openVPN compliant server (that doesnt have Grandstream on the lid). Knowing that, just put the VPN server in the PBX and be done with it, then everything work, everyone’s happy, YOU SELL MORE PRODUCTS.


@SFX_Group, a couple of us (myself, @lpneblett & @costwisewpg) have been doing some testing with the OpenVPN client with a remote GXP21xx (2170 in my case) to a GWN7000 with a UCM62xx.

[GXP21xx with OpenVPN client <-> Internet <-> OpenVPN server with GWN7000 <-> UCM62xx]

Our limited experience has shown this works and the audio quality is excellent.

The only problem we’ve really had with the GXP21xx has been the fact that for some reason it seems to take a bit of time before the RPT is fully functional, but once it start working the first time that problem disappears.

We started testing this with WP800, but ran into issues which are now with GS development to resolve. Our plan is to move onto other phones once the WP800 issues are resolved.

If you will be at tomorrow’s (Tuesday, April 9th) Gentek GSP training session I’d be happy to discuss this with you in person. Otherwise, PM me if you want to discuss.

What I have not been able to figure out (per previous posts) is how to configure a Windows OpenVPN client to connect to the GWN7000 OpernVPN server.



I would expect the Grandstream phones to VPN to a Grandstream firewall. However my clients do not use Grandstream firewalls as they are just not large or designed in a corporate way to use or sell. All my firewalls i sell and install are over $2000 each. They are however fully openVPN compliant where as the Grandstream firewall is not, it uses some control code that goes outside of the openVPN standard.

I have no issue at all getting Windows PCs to work with a standard openVPN compliant server using the config.ovpn file (as to be expected).

From my findings i would not consider any Grandstream product “openVPN compliant” if it were i would not be getting an issue connecting them to an openVPN compliant server. As you have found you are unable to get a Windows system with an openVPN client to connect to a Grandstream firewall as it is not fully openVPN compliant so doesnt work (as expected).

Brings me back to my original suggestion to Grandstream a few years ago, just put an VPN server INSIDE the PBX and remove the whole problem !

We will not be at the training, we will never buy hardware for training as Grandstream request, if they want training they provide the hardware to be trained on like all the other industry giants have (Intel, Vivotek etc) who we are all Gold Partners with.

Thanks for the offer, i hope you get Windows working with the Grandstream firewall, however unless you stumble over a settings i fear you could be down for many 100’s of hours research work…


Actually, I haven’t attempted it. I haven’t had the time to try to figure this out, so I really don’t know if it will work or not.

Have you thought about using the GWN7000 just as an OpenVPN server for the phones? Only traffic on the OpenVPN port would be going through it.


To do that would mean something called “multi home” the gateways which is not something you want on any LAN, other than its not good practice to have 2 firewalls on the same LAN. However after looking in the GWN7000 its not a “nice” router to use, i found other bugs in it as well which resulted in the decision internally to not deploy them on any site for any reason.

However deploying a openVPN server was the first thought process until deeper analyses of the LAN methods are taken in to account, the VPN termination needs to happen on the primary gateway OR directly on the “in use” appliance (in this case the PBX). Comes back to putting a VPN server INSIDE the PBX, its the easiest solution and would allow the sale of way more hardware as ALL firewalls are removed from the situation as its just TLS (or UDP) traffic from the phone to the PBX

Once a system fails or doesnt work, we never throw money at the solution to get around the issue, for this particular client we are using a standard site to site VPN locked down which we had working in about 10 minutes as its a knowing working system, the phone thinks its on the same LAN with 30ms ping times (between sites).

I just wish manufactures would create hardware that works in the first place, again a learning curve, we will be testing ALL features before selling any hardware like this again.