Do you use a Dynamic Domain Name Server (DDNS) service?
Whether you use a free or paid DDNS service, a user name, domain name, and password is required. These items are part of your VPN configuration in the router you set before generating the VPN files for the client device.
Go back to the DDNS service and change the password or better yet, create a whole new account with a new domain name and password.
Reconfigure your router VPN server and use the new DDNS information. Then create a new set of VPN configuration files for the client device. The old configuration files will no longer work with the new router configuration.
Thank you for taking the time to respond! I don't have DDNS (and I don't need it, afaik). I only have a fixed IP. The router has its own VPN server which has the security certificates I download for the clients to connect. I am talking about generating new certificates that the server would recognise. Hopefully it makes sense.
Thank you for taking the time to respond! I don't have DDNS (and I don't need it, afaik). I only have a fixed IP. The router has its own VPN server which has the security certificates I download for the clients to connect. I am talking about generating new certificates that the server would recognise. Hopefully it makes sense.
Thanks again!
I understand what you are asking for. The series of generated certificates encrypt the router serial number and the DDNS password.
You cannot change the serial number and if you don't use DDNS, it is going to be difficult. As far as I know, the Netgear Open VPN implementation makes no provision for username and password protection for access to the Open VPN server.
I have created a netgear ddns account and hostname and seems configured. When I download the certificate, it seem to be the same as the old one (based on the signature and public key), so it doesn't seem like it's been re-generated. I can't find an option to re-generate it manually.
I am not sure if we're talking about the same thing, so please bear with me a bit more.
The router offers a VPN service, which means I can remotely connect to my private network using this vpn service. In order to connect to the VPN service, the router has an SSL certificate (private + public key pair) that I use remotely to authenticate. So that private/public key pair is in fact the certificate I am talking about.
The keys are plain text files and contain hashes, i.e. generated string characters that make up the keys themselves. So, no binary file involved.
I just download the keys (the configuration file is optional, I can create it manually on the client side, since it's about the ports that are used and some other settings that I see in the configuration file), copy them on the client/remote computer and connect to my routers vpn service using them.
Now, I can either have a fixed IP or a DNS name (be it dynamic or not), I imagined I should be able to connect either way, since from this perspective, DNS is just a translation from a name to the (same fixed) public IP that I have. I understood from your previous message that, on the router, the public/private key pair (the certificate) is generated using the hostname of the DDNS, so I created that DDNS account, although it seemed a bit weird to me that the security guys at netgear are using such a "strategy" in order to generate a certificate, but hey, maybe they have their good reasons, I can already think about at least one.
When I download the configuration again (i.e. the public/private key pair), I see that they are the same as the previous ones, although this time I do have a DDNS name. This means that the router did not generate a new configuration (a new certificate, i.e. a new private/public key pair). So, as I would have expected previously, having a DDNS or just a fixed IP doesn't seem to matter from this point of view.
Did you run the old key file through a hash algorithm to compare it to the new key file?
Like I recommended previously, you will have to test the old client file against the new configuration in the router to confirm whether it will or will not allow access.
No, didn't have to run it through any algorithm. Since they are plain text files, I just looked at them and they contain exactly the same characters in exactly the same order. A file comparison utility like notepad++ or meld confirm that.
Also, I can still connect with the "old" keys, so indeed, problem not solved.
No, didn't have to run it through any algorithm. Since they are plain text files, I just looked at them and they contain exactly the same characters in exactly the same order. A file comparison utility like notepad++ or meld confirm that.
Also, I can still connect with the "old" keys, so indeed, problem not solved.
