HOWTO configure GL-AR750S to connect to home OpenVPN server

I have a Raspberry OpenVPN server at home for which I have set up a server.ovpn file and built the following files, all with 4096-bit strength: ca.crt, server.key, server.crt, dh4096.pem, tls-auth.key.
I have created a client.ovpn file and, also with 4096-bit strength, and created the client.key, client.crt, and tls-auth.key files.
When I set up an OpenVPN client on another Raspberry with those client files, I can establish a VPN tunnel between client and server.


  1. Does the GL-750S support keys and certs with 4096 bit strength?

  2. What is the maximum key length which I can use with the GL-AR750S? Is 4096 bits within the permissible range?

  3. I know that Diffie-Hellman parameters are used at the server side. There is a factory Diffie-Hellman file name dh1024.pem in /etc/openvpn/cert; I figure it is there in case one wants to configure the GL-AR750S as an OpenVPN server. If the GL-AR750S functions with higher strengths than 1024 bits: How should the Diffie-Hellman file be named when it is not for a 1024-bit key, for instance for a 2048-bit key or for a 4096-bit key? Is dh2048.pem or dh4096.pem correct? Or do I need to change a reference to this file somewhere else?

  4. Question: How do I include the certificates and keys in a ZIP file so that the AR750S will accept it?My working client.ovpn for the Raspberry looks like this:

dev tun
proto udp
remote my-secret-dyndns-domain 443 # DynDNS domain name
resolv-retry infinite
nobind # don’t enforce a fixed port number
ca /etc/openvpn/cert/ca.crt
cert /etc/openvpn/cert/client.crt
key /etc/openvpn/cert/client.key # this must be kept secret
remote-cert-tls server
tls-auth /etc/openvpn/cert/tls-auth.key 1 # server: 0; client: 1
log /var/log/openvpn.log
cipher AES-256-CBC
auth SHA512
verb 1
mute 20 # silence repeating messges

When I look for instance at the sample from NordVPN, I notice that there are more sections in the client.ovpn file with begin and end tags (example , , ,

[certificate binary data]
key-direction 1		# can this option be listed above, or is this position mandatory?
# 2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----
[key binary data]
-----END OpenVPN Static key V1-----

(a) What are the begin and end tags for a client key and client certificate?
(b) Does the option “key-direction 1” have to occur between ca.crt and tls-auth.key block, or can it be listed above with the other options?
(c) Does the “V1” in -----BEGIN OpenVPN Static key V1----- have any significance?
The easy-rsa utility surrounds the Diffie-Hellman data with
What does the GL-AR750S expect? Should I edit the easy-rsa lines to match the NordVPN sample?

Are thes client key and certificate blocks position-dependent or can they just be appended in any sequence?

  1. I tried to copy the client .ovpn file, the client key and certificate files into the respective directories under /etc/openvpn. This alone did not suffice that GL-AR750S added a new OpenVPN configuration. Is there a manual way to add a configuration and not use a ZIP file?

I think you have to try to tell.

As far as I know, options doesn’t have sequence.

For certificates in zip file, here is what you should do, taking ca as example.
in ovpn
ca ca.crt
then there must be a ca.crt file in the zip file. Then it works fine. Don’t use /etc/openvpn etc as the router will change these automatically.

You mean, I am on my own here with trial-and-error? If not even GL-iNet support can tell, then my first attempt would be to create an OpenVPN server in the GL-AR750S and let it create a client export file itself. Maybe it would show me the basic client file structure. But then I still need to work with key material which an external PKI has generated and apply this knowledge. And in order to do that I must know with which key lengths the AR750(S) is able to work.

Sorry, I don’t understand what you are saying here. Could you please give an example how a client import file looks with the tags for the binary blocks before it has been ZIPped? There must be tags for the ca.crt, for the client.crt (unknown tags), for the client.key (unknown tags), and for the tls-auth.key.
Another reason why users need this information are scenarios where they may want to configure several client devices, each with its own client keys and certs. Then they cannot import one and the same client.ovpn into a number of GL-AR750(S) devices for their road warriors but have to create these files individually for each device. However, the ca and server blocks would of course be the same for all clients.
Could you please answer my questions about the permissible key length? This helps me to adjust my PKI program accordingly.

And while we are at it, the initial questions about block tags apply also to a server configuration.

  1. Can users create an import file for an OpenVPN server, or is this not part of the design?
  2. What are the permissible key and certificate strengths, and how do I select one if I create an OpenVPN server in the AR750S?
  3. What are the tags for ca.crt, server.key, server.crt, dh.pem block and what is the dh.pem file name if it is not 1024 bits, and last but not least the tag for the tls-auth.key?

I followed your suggestion to try a couple of things. CAUTION: I am still in the process of gaining a more thorough understanding of your product; some of my conclusions may not be right on the mark. But I appreciate your insightful comments.
OK, I have set up an OpenVPN server in the GL-AR750S and have exported a client file. I am glad to assist iNet support with the following information:

Internal file format of the client.ovpn

dev tun
proto udp
remote 443
resolv-retry infinite
auth SHA1 
cipher BF-CBC
comp-lzo adaptive
nice 0
mute 5
verb 3
[CA certificate binary data]
[client certificate binary data]
[client key binary data]

So, now I have some but not all of the relevant block tags.

Server configuration options on the admin panel
“Access local network” is off by default; the user can turn it on and receives an appropriate warning if he does.
The VPN network address and netwmask can be modified.
The port number can be modified.
The only option for the encryption parameter is SHA1 which is no longer considered strong. I cannot see how this can be modified to SHA256 or SHA512.
The user can select the UDP or TCP protocol.

Going to /etc/openvpn/cert and looking deeper
The GL-AR750S creates a certification authority (CA) certificate with 2048 bits which is valid for 10 years. I did not see any options to change either one of these parameters. Conclusion: The public key length=2048 bits and validity begin and end dates cannot be changed.

       Version: 3 (0x2) 
       Serial Number: 
   Signature Algorithm: sha1WithRSAEncryption 
       Issuer: CN=OpenVPN CA 
           Not Before: Nov  6 07:15:04 2018 GMT 
           Not After : Nov  3 07:15:04 2028 GMT 
       Subject: CN=OpenVPN CA 
       Subject Public Key Info: 
           Public Key Algorithm: rsaEncryption 
               Public-Key: (2048 bit)

The GL-AR750S creates a server certificate with a 2048-bit public key and a validity period of one month (!). I cannot see how the user could modify these parameters. Conclusion: Customers need to create a new server certificate every month and distribute it to all of their clients. This is not a viable solution. Besides, I did not see how customers can delete or replace an existing OpenVPN server configuration, see below.

       Version: 1 (0x0) 
       Serial Number: 
   Signature Algorithm: sha1WithRSAEncryption 
       Issuer: CN=OpenVPN CA 
           Not Before: Nov  6 07:15:10 2018 GMT 
           Not After : Dec  6 07:15:10 2018 GMT 
       Subject: CN=OpenVpn client 
       Subject Public Key Info: 
           Public Key Algorithm: rsaEncryption 
               Public-Key: (2048 bit)

The GL-AR750S creates a client certificate with a 2048-bit public key and a validity period of one month (!) I cannot see how the user could modify these parameters. Conclusion: Customers neet to replace/update their client configurations every month. This is not a viable solution.

       Version: 1 (0x0) 
       Serial Number: 
   Signature Algorithm: sha1WithRSAEncryption 
       Issuer: CN=OpenVPN CA 
           Not Before: Nov  6 07:15:10 2018 GMT 
           Not After : Dec  6 07:15:10 2018 GMT 
       Subject: CN=OpenVpn client 
       Subject Public Key Info: 
           Public Key Algorithm: rsaEncryption 
               Public-Key: (2048 bit)

I do not see that the OpenVPN server configuration would create a tls-auth key by default and I don’t see how I can make it do that.
I do not see that the OpenVPN server configuration would create a Diffie-Hellman file dhxxxx.pem and how the user can control this.
I do not see that the server and client certificates validity period of one meonth is useful for your customers.
And finally: Once I have created a server configuration (like for my trial-and-error session which you suggested), I don’t see how to delete it or replace it with a version for real work or when the server certificate validity period has expired. What is a customer supposed to do in that case – maybe reset the device to factory status and recreate everything from scratch?

To sum it up:
A better description about the VPN functions in your router would greatly help your customers. Your product could be of great value also in a commercial environment if you would let your customers configure some important parameters like the key strength and validity period. If you could then also consider to make your product useable in an environment which uses its own PKI, you could definitely enhance the usefulness of your product in a commercial setting.

Nevertheless, I am looking forward to your answers and comments.

1 Like

There are many topics regarding OpenVPN configuration, with embedded certificates too.
The UI server interface is for a basic configuration for most users.
For advanced users, they usually set up a test server using a VM or on their own server, and then just migrate everything to the GL router.

How? Just a little bit more explanation could help. As I wrote, copying the config and key/cert files to /etc/openvpn/ovpn and /etc/openvpn/cert did not establish a new server (or client, if I recall this correctly)

You can make a default OpenVPN configuration using the UI, then edit the generated files to get the configuration more as you want.

Anyway, for a new server i would recommend that you use Wireguard instead. With OpenVPN and any of the GL routers you will get around 20mbit/s max, while Wireguard will happily max your internet connection (i have seen 100mbit so far).

Wireguard is not an option for me.
Johnex: My problems are not with OpenVPN configuration files. I can create and edit those with no problems. My questions are about server and client credentials (ca.crt, server.key, server.crt, client001.key, client002.crt, client002.key, etc., dhxxxx.pem, tls-aut.key) and how to get them into an iNet device when they have been created by an external PKI.

I have succeeded today to take the internally generated client and server credentials and extended their expiration date. I’ll copy them bakc into the device and try if everything works. One month is definitely a useless proposition.
I suggest that the iNet developers familiarise themselves with the creation of signed certificates and how to set their expiration date. Hint: The one month is an openssl default unless someone who knows how to use openssl tells it otherwise. The openssl documentation tells how.

It is very unfortunate that the developers don’t envision the use of their product in a commercial environment where multiple roadwarriors (traveling employees) could each have an OpenVPN client device with its own keys and certs; the current concept which generates ONE client key inside the device does not lend itself to such a usage.

It is also unfortunate that the developers offer only SHA1 which is considered a weak digest since around 2005. In the meantime there are stronger digests like SHA256 and SHA512 in use.

It seems to me that the dh1024.pem file is copied from the ROM which makes it immutable. For better security it should be created different for every device. Yes, it is a time-consuming calculation to generate such a prime.

The usage of tls-auth.key is totally undocumented.

In short: This closed design where everything is created inside the GL devices and there are no documented procedures how keys and certs from an external PKI (which users could easily set up even with a Raspberry) can be imported, together with the fact that the device creates credentials for only ONE client and the one-month expiration time make this device essentially unusable for anything else but a VPN client to connect to a public VPN service from your hotel room. It is not designed to connect to a home server.

The answers from iNet folks to my specific questions here in this thread were too vague to be helpful. Thank you anyhow for your time. The questions can possibly highlight where the documentation can be improved.

1 Like

Thanks for your advise. Yes we will improve this according to your suggestions, nearly all of them.

Currently you cannot do too much about the configuration. But for sure you can generate these configuration using your pc or Raspberry Pi and put on the router.

I am glad to see your positive and constructive response and am looking forward to an improved firmware and some necessary documentation. aTdHvAaNnKcSe (thanks in advance) !

Thing is, it’s all about “market niche” with any product; where does GL-iNet draw the line between being a “cheap but good” product and an “expensive Enterprise” product? There’s routers with your desired features, but they’re more expensive and not (really) portable. (Plus, let’s face it- the hardware, while nice, isn’t “Enterprise grade” at all.)

Ironically enough, I was turned onto their line of products on a “Road Warrior” website where their products were featured for their small size and portability (important when you’re living out of a backpack and carry-on, as I do sometimes) and the feature set works for that market, IMO. I used to have to lug around a full-on router with cords and such.

(I won’t bring up the “… and it’s open-source!” point, as that’s really out of reach for most users- but that just means it could probably be done if one wanted it hard enough :slight_smile: )

Hi kennethrc,

I am acutely aware that manufacturers have to weigh effort and cost of features against perceived gain for their customers. However, my example of the commercial world only takes the typical user family with sons, daughters and parents who all want to connect to one home VPN server a step further. Consider their disappointment when they discover that they can connect only with one mobile device to their home server. Well, maybe they’d try to use several client devices with exactly the same credentials; but that is not how a public key infrastructure works. I am aware that the GL-AR750S as an OpenVPN server does not have the horsepower (‘enterprise-grade’) to provide secure connections to a LARGE number of clients. I am all with you in that respect. However, it would IMHO perfectly suffice for the above mentioned family and small businesses, in other words to a probably sizeable customer population.

I stand by my assertion that the GL-AR750S is not usable in a private OpenVPN network the way it works now. Why? Sorry if I repeat myself: It may be great to connect to a public VPN providers but I do not need this.

  1. The internally created credentials for an OpenVPN server and ONE (!) client expire after one month. This is ‘unusable’ in the real sense of the word.
    The validity period of certificates MUST be user-definable, preferably with a sensible default duration.
    More than one client which can connect would definitely improve the value for many customers.
  2. Cipher algorithms which are no longer considered secure must not be used by default, especially if the customer cannot even change them. The cipher algorithms should be selectable, again with sensible defaults.
  3. The closed design with internal credential creation helps the technically challenged customers, a consideration from the manufacturer’s point of view which I can fully understand. However, I do not believe in locking all customers into this one scenario which allows only one server-client pair. The family with several members is one example which already exceeds the limits of this device.
  4. What are customers supposed to do when they have configured the GL-AR750S as a VPN server and the server and client certificates have expired? I guess they have to factory-reset the device and create a new set of credentials in the GL-AR750S. This is not a workable proposition.
  5. What are the customers supposed to do when they find out that they need to use the GL-AR750S no longer as an OpneVPN server but as a VPN client instead? Is there a button to switch between server and client configuration? Apparently not. Is it time for a factory reset again?

From here on it becomes quite technical.
6. I have to give the manufacturer credit because they save the ca.crt and ca.key and all the other credentials in /etc/openvpn/cert/ and allow ssh/scp access to it. I configured the device as an OpenVPN server, extracted the ca.key and ca.crt files and went on to set up my external scripted PKI. Now I can create as many different client.ovpn files as I want, create individual dh1024.pem primes if I want (does the device work with a foreign dh file?), and individual tls-auth.keys. THE AVERAGE USER CANNOT RESORT TO SUCH MEASURES. Because there is no documentation about the use of Diffie-Hellman primes and tls-auth keys, technical savvy users are left in the dark there. Can one overwrite the whole certificate/key chain in the /etc/openvpn/cert/ directory with externally created key and cert files and the device will from then on work with those? That would obviate the need for a factory-reset.
7. I looked at the client.ovpn file which one of the commercial OpenVPN providers supplies; I noticed that they specify SHA512 and AES-256-CBC. Good! but undocumented. This is something THE MANUFACTURER should document. The GL-AR750S as an OpenVPN server uses SHA1 (cannot be changed) and BF-CBC. The manufacturer should document which algorithms and key lengths this particular device supports.
8. The same OpenVPN provider includes a data block for tls-auth in his client.ovpn file. Without this insight one would not know that the GL-AR750S device somehow supports it. Since there is no option line ‘tls-auth ’ as in in other OpenVPN implementations, customers are left to discover this by chance and to guess how to enable it on the server and client side. Another point where documentation is needed because this differs from other OpenVPN implementations: Which files in the /etc/openvpn/cert/ directory does the GL-AR750 recognize without dedicated option lines which refer to the files? This brings me to the tags for the data blocks in the .ovpn files which are also nowhere documented as far as I can see. Which data block tags can be used in a server.ovpn, which tags can be used in a client.ovpn?

I have many different clients who can connect to my OpenVPN server I’m running at home simultaneously (and they often do); all my OpenVPN clients share the same (passwordless) .ovpn file. For as you’d said, home users getting to their home network, what’s the harm?

But I think GL-iNet have positioned themselves well in their own niche that works well for its customers; it’s just MO that your needs are outside of it, and I worry about the effort/benefit(/sales) curve trying to add the things you want to the product would entail.

… but it never hurts to ask.

GL has configured everything so that it will work for most of their customers. If a customer needs something more advanced, they can ask nicely here on the forums, or try to do it themselves. For advanced configurations they can visit the OpenVPN forums where the experts live.

If one of my user’s device is lost or stolen, I can revoke that user credential without affecting others.

I mentioned at least once that I believe that I understand the rationale behind some of your design decisions. I know that my criticism about several points was harsh, certificate expiration and less secure choices of crypto algorithms being two examples where I uphold my reservations.
I have looked at the device some more and admit that it can work for many customers as is (even as a VPN server for the first month) Peace?
I would prefer to take any further dialogue off-line.

OK. Nice talk guys. Everyone is correct.

We will make advanced option more complete and at the same time, keep the default configuration as simple as possible. This only takes time, effort and careful thinking.

OK, I’m back with some news.

First, I got the GL-AR750S to connect to a vanilla OpenVPN server on one of my computers. It was quite a bit of work but the end justifies the means. A second device, a GL-AR750, is now waiting to be configured. That requires only to run a script which creates and signs another client key, and a script which creates the import file client002.ovpn.

Unfortunately, there is no documentation about the client.ovpn and server.ovpn file content and syntax. Much of the configuration options can of course be taken directly from the standard OpenVPN documentation. But there are some options which differ from the standard, and then there are proprietary options which iNet needs for their slightly different concept. And there may also be some undocumented and never seen options. These are minor differences (but which warrant documentation nevertheless and even more so).

To make a long story short: Once you have figured out how to set up a syntactically correct import file for the GL-AR750 family of devices, and if you are able to create your own CA, server, and client credentials: Then you are all set and can connect to any of your own OpenVPN servers. You can also select cipher suites which are stronger than the defaults, apply some hardening concepts which OpenVPN describes, and so on.

Well, yes, there were times when I was ready to throw that thing into a corner or return both devices to the online shop where I bought them. One area where I was missing some thoughts from the manufacturer is troubleshooting. The OpenVPN ‘log’ statement is still there as I found out.

There are only a few (!) things where I believe iNet must do better. Overall I have come to appreciate some of their thinking. It’s all about customer convenience - and that sometimes is incompatible with best practices. And then there is the huge field of things which are debatable and/or depend on the perception of customer demands. I am looking forward to see what happens. I do hope that they document some technical details for those who can benefit from it and especially that they don’t lock up the currently open design. This would preclude the usage of the devices in all those other fields which they did not originally have in mind. With other words: It is now still possible that customers apply iNet’s products in markets which iNet had never envisioned for their products. These technical users deliberately go beyond the realm of “customer convenience”.