NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Morganino
Jun 26, 2017Tutor
Netgear R7000 and OpenVPN for Android App
Hi, since last OpenVPN for Android App update (v.0.6.73) downloadable at the following link: https://play.google.com/store/apps/details?id=de.blinkt.openvpn OpenSSL version was upgraded to 1.1 and...
- Feb 28, 2018
Thanks everyone for feedback so far. Attached is version 1.0.1. I fixed some typos, added a suggestion to clean up your tftp folder when you're done, and made a note about the OpenVPN version that's most compatible with the document.
Some users looking to work through this doc may find that they can avoid Step 1 by visiting this hidden page:
If the debug page loads and there is an "Enable Telnet" option then you got lucky. Note that either the debug page or the option to "Enable Telnet" may not exist on your device or firmware version. Remember to check that this option is disabled after you're finished because having telnet enabled is a security risk.
kuser
Feb 25, 2018Star
This looks very promising, why is this page hidden?
Diggie3
Feb 25, 2018Luminary
Hi,
Please see attached. I hope it works for you, but it is 100% at your own risk.
It has honestly been exhausting putting this together so I hope NG will automate replacing keys through the UI in future.
Please see attached. I hope it works for you, but it is 100% at your own risk.
It has honestly been exhausting putting this together so I hope NG will automate replacing keys through the UI in future.
- huttlerFeb 25, 2018AspirantThank you for posting the fix! Hopefully I can try it out next weekend
- NG_GuruFeb 25, 2018Star
I can confirm that step 1 can be avoided (R8500) by going to http://192.168.1.1/debug.htm and select "Enable Telnet "
Can anyone else confirm that telnet can be enabled this way ?
- Diggie3Feb 25, 2018LuminaryNG_Guru: I'm open to writing in some shortcuts as long as it doesn't complicate the flow. I do know the magic packet has been around for years on all models/firmwares.
I'd love to hear from anyone who managed to replace their keys successfully so I know I didn't write in any major errors. I found a couple of insignificant typos I'll fix later in a 1.0.1 version.
Cheers, and good luck. - NG_GuruFeb 25, 2018Star
Very nice instructions!
I was able to update my NightHawk R8500 using these instructions.
For me the hardest part would have been creating the keys. Your directions were right on!
I verified old keys are dead and new keys are working.
My R8500 is hardware Ver1 and Firmware Version V1.0.2.116
- katsawFeb 26, 2018Guide
Diggie3wrote:
Hi,
Please see attached. I hope it works for you, but it is 100% at your own risk.
It has honestly been exhausting putting this together so I hope NG will automate replacing keys through the UI in future.
Hi Diggie3,Thank you very much for your useful instruction!
For my R6220 router with Firmware Version V1.1.0.64_1.0.1, I can enable telnet by select the option in http://192.168.XX.1/debug.htm.
However, the files in the directory /tmp/openvpn of your instructions are:
ca.crt
client.crt
client.key
dh1024.pem
server.crt
server.keyIn my R6220 router, the files are:
ca.crt
ca.key
client.crt
client.csr
client.key
dh1024.pem
dh2048.pem
openss1.cnf
server.crt
server.csr
server.key
varsMore files found in the mentioned directory. Do you have any idea about the other files? Especially there are 2 pem files "dh1024.pem" & "dh2048.pem".
- katsawFeb 26, 2018Guide
NG_Guruwrote:I can confirm that step 1 can be avoided (R8500) by going to http://192.168.1.1/debug.htm and select "Enable Telnet "
Can anyone else confirm that telnet can be enabled this way ?
This also work for my R6220 router. Selecting "Enable Telnet" will enbale the linux telnet server inside the R6220.
- Diggie3Feb 26, 2018LuminaryThat's interesting.
I'm not at home right now so I can't check my R7000 but one difference seems to be that on your device the OpenVPN configuration seems to be in /tmp/openvpn, whereas on my R7000 it's at a different location.
Can you please follow Step 4, then follow the part of Step 5 that tells you how to transfer the original keys from your router with tftp, but instead of sending originalkeys.zip send openss1.cnf. I would suspect looking at this file will tell us which files the router is really going to use. It might also be interesting to inspect "vars". Please check they have no confidential information before posting them, or send me links in a direct message.
It looks like some of those files are certificate signing requests that perhaps NG left on the device but I suspect don't actually need to be there (though you should leave them alone). ca.key probably is supposed to be on the key signing machine only so assuming your router is never signing new keys itself (afaik my R7000 doesn't) that probably isn't necessary either. - katsawFeb 27, 2018Guide
Diggie3wrote:
That's interesting.
I'm not at home right now so I can't check my R7000 but one difference seems to be that on your device the OpenVPN configuration seems to be in /tmp/openvpn, whereas on my R7000 it's at a different location.
Can you please follow Step 4, then follow the part of Step 5 that tells you how to transfer the original keys from your router with tftp, but instead of sending originalkeys.zip send openss1.cnf. I would suspect looking at this file will tell us which files the router is really going to use. It might also be interesting to inspect "vars". Please check they have no confidential information before posting them, or send me links in a direct message.
It looks like some of those files are certificate signing requests that perhaps NG left on the device but I suspect don't actually need to be there (though you should leave them alone). ca.key probably is supposed to be on the key signing machine only so assuming your router is never signing new keys itself (afaik my R7000 doesn't) that probably isn't necessary either.Sure, I will try my best to get all the mentioned information. If possible, I will get all these files and attached.
It may need couples of days because I am not familiar with the operation of tftp files transfer.
Anyway, thank you very much for your attention.
- Diggie3Feb 27, 2018LuminaryNo problem. Following those guide steps should give you all you need to enter the tftp commands, but another way is to type,
cat openss1.cnf
cat vars
This will dump their contents into the console, so it's a bit messy but you could then copy/paste. - katsawFeb 27, 2018Guide
Diggie3wrote:
No problem. Following those guide steps should give you all you need to enter the tftp commands, but another way is to type,
cat openss1.cnf
cat vars
This will dump their contents into the console, so it's a bit messy but you could then copy/paste.Sorry, I have made a mistake. The file name should be "openssl.cnf" instead of "openss1.cnf".
The text content of "openssl.cnf", "vars", "dh1024.pem" & "dh2048.pem" is attached in a single PDF file.
- katsawFeb 27, 2018Guide
Diggie3wrote:
That's interesting.
I'm not at home right now so I can't check my R7000 but one difference seems to be that on your device the OpenVPN configuration seems to be in /tmp/openvpn, whereas on my R7000 it's at a different location.
Can you please follow Step 4, then follow the part of Step 5 that tells you how to transfer the original keys from your router with tftp, but instead of sending originalkeys.zip send openss1.cnf. I would suspect looking at this file will tell us which files the router is really going to use. It might also be interesting to inspect "vars". Please check they have no confidential information before posting them, or send me links in a direct message.
It looks like some of those files are certificate signing requests that perhaps NG left on the device but I suspect don't actually need to be there (though you should leave them alone). ca.key probably is supposed to be on the key signing machine only so assuming your router is never signing new keys itself (afaik my R7000 doesn't) that probably isn't necessary either.I am interesting why you are curious about the location of OpenVPN configuration file (/tmp/openvpn) of my R6220 router? Actually, I followed the instruction in page 32 & 33 of your provided PDF. It also stated that we can find the configuration files in "tmp/openvpn".
It will be a problem for me since there are 2 pem files (dh1024.pem & dh2048.pem) I have insufficient knowledge to know which one the the correct Diffie Hellman parameters!
Pls let me know if you need more information of the files found in my Netgear R6220.
Thanks again.
- Diggie3Feb 27, 2018LuminaryPlease be careful which files you post, you should not post your dh params. Fortunately we are working on replacing those ;)
Okay so the files you posted (openssl.cnf and vars) are part of the easy rsa scripts to generate the original keys. I would continue to guess that unless the router itself was generating keys, which I doubt, they don't really need to be there, and we should just ignore them.
Try these commands:
cat /tmp/server_tap.conf
cat /tmp/server_tun.conf
On my R7000 the first few lines of each output will show the dh file that OpenVPN server is using.
You can probably also type this to verify which conf files are in use:
ps | grep openvpn
Unfortunately, at least on my R7000, /tmp itself stored on part of a file system that is not updatable (you can write to it but when you reboot your changes will most likely be gone). This leaves us only able to update the keys and not the OpenVPN configs themselves. If NG engineers wanted to be friendly and helpful us fix more problems ourselves in future they could think about making more writable overlays :) - katsawFeb 27, 2018Guide
Diggie3wrote:
Please be careful which files you post, you should not post your dh params. Fortunately we are working on replacing those ;)
Okay so the files you posted (openssl.cnf and vars) are part of the easy rsa scripts to generate the original keys. I would continue to guess that unless the router itself was generating keys, which I doubt, they don't really need to be there, and we should just ignore them.
Try these commands:
cat /tmp/server_tap.conf
cat /tmp/server_tun.conf
On my R7000 the first few lines of each output will show the dh file that OpenVPN server is using.
You can probably also type this to verify which conf files are in use:
ps | grep openvpn
Unfortunately, at least on my R7000, /tmp itself stored on part of a file system that is not updatable (you can write to it but when you reboot your changes will most likely be gone). This leaves us only able to update the keys and not the OpenVPN configs themselves. If NG engineers wanted to be friendly and helpful us fix more problems ourselves in future they could think about making more writable overlays :)Many thanks for your quick reply!
The 2 files cannot be found in the specified directory.
/tmp/server_tap.conf
/tmp/server_tun.confAfter executing the command "ps | grep openvpn", the follow result found in the screen:
4685 root 1520 S grep openvpn
7189 root 3904 S /usr/sbin/openvpn --config /etc/server.conf
7191 root 4196 S /usr/sbin/openvpn --config /etc/server_phone.conf - Diggie3Feb 27, 2018LuminaryOkay, your router seems to be significantly different.
Type:
cat /etc/server.conf
cat /etc/server_phone.conf
That'll let you see your OpenVPN configs. - katsawFeb 28, 2018Guide
Diggie3wrote:
Okay, your router seems to be significantly different.
Type:
cat /etc/server.conf
cat /etc/server_phone.conf
That'll let you see your OpenVPN configs.Pls find the outcome below by cut & paste of the text output. It seems the file “/etc/server_phone.conf” will be the true config of my OpenVPN server because I am currently using port 8443 (UDP).
# cat /etc/server.conf
dh /tmp/openvpn/dh1024.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/server.crt
key /tmp/openvpn/server.key
dev tap0
server-bridge
proto udp
port 12974
keepalive 10 120
verb 5
mute 5
log-append /tmp/openvpn_log
writepid /tmp/openvpnd.pid
mtu-disc yes
topology subnet
cipher AES-128-CBC
auth sha1
tls-server
push "redirect-gateway def1 bypass-dhcp"
client-to-client
duplicate-cn
comp-lzo
fast-io
push "route 192.168.11.0 255.255.255.0"
push "route-delay 5"
# cat /etc/server_phone.conf
dh /tmp/openvpn/dh1024.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/server.crt
key /tmp/openvpn/server.key
dev tun
server 192.168.2.0 255.255.255.0
proto udp
port 8443
keepalive 10 120
verb 5
mute 5
log-append /tmp/openvpn_log
writepid /tmp/openvpnd.pid
mtu-disc yes
topology subnet
cipher AES-128-CBC
auth sha1
tls-server
push "redirect-gateway def1 bypass-dhcp"
client-to-client
duplicate-cn
comp-lzo
fast-io
push "route 192.168.11.0 255.255.255.0"#
- Diggie3Feb 28, 2018Luminary
The forum seems to have lost my last post so hopefully this doesn't post twice.
Things we can see:
1. Based on your file list from /tmp/openvpn, we can see that your router uses "client" as the base name for client keys/certificates, and "server" for the base name for server keys/certificates. That's compatible with the PDF.
2. Based on the OpenVPN config files you dumped, we can see the OpenVPN server is loading dh1024.pem. That's compatible with the PDF.
As I wrote earlier, I think some of the extra files are:
- Copies of the easy rsa scripts used to create your keys originally, but I suspect unused by the router
- Certificate signing requests, which are usually part of the easy rsa key generation process, and I suspect also unused by the router
- dh2048.pem I don't know why this is here. It might be unused, but I can't say for sure. I don't know if your model has some other service that my R7000 doesn't have.
So in summary, my best guess would be that the steps in the guide should work for you. The choice to proceed and the risk involved in that is yours. There is always some risk that our models are different enough that you have a different version of OpenVPN that is incompatible with the new keys for some reason, though I wouldn't expect this. Please realize I can only provide my best guess since I don't have access to your model.
If you do decide to go ahead:
- Absolutely follow Step 5 to backup the files that will be replaced, and to know how to restore them if you need to.
- You could also do this:
zip -9 fullbackup.zip *
... to try to fully backup all the original files. Check that the zip utility lists all of the files you found in your /tmp/openvpn folder as it works.
- katsawFeb 28, 2018Guide
Diggie3wrote:The forum seems to have lost my last post so hopefully this doesn't post twice.
Things we can see:
1. Based on your file list from /tmp/openvpn, we can see that your router uses "client" as the base name for client keys/certificates, and "server" for the base name for server keys/certificates. That's compatible with the PDF.
2. Based on the OpenVPN config files you dumped, we can see the OpenVPN server is loading dh1024.pem. That's compatible with the PDF.
As I wrote earlier, I think some of the extra files are:
- Copies of the easy rsa scripts used to create your keys originally, but I suspect unused by the router
- Certificate signing requests, which are usually part of the easy rsa key generation process, and I suspect also unused by the router
- dh2048.pem I don't know why this is here. It might be unused, but I can't say for sure. I don't know if your model has some other service that my R7000 doesn't have.
So in summary, my best guess would be that the steps in the guide should work for you. The choice to proceed and the risk involved in that is yours. There is always some risk that our models are different enough that you have a different version of OpenVPN that is incompatible with the new keys for some reason, though I wouldn't expect this. Please realize I can only provide my best guess since I don't have access to your model.
If you do decide to go ahead:
- Absolutely follow Step 5 to backup the files that will be replaced, and to know how to restore them if you need to.
- You could also do this:
zip -9 fullbackup.zip *
... to try to fully backup all the original files. Check that the zip utility lists all of the files you found in your /tmp/openvpn folder as it works.
Thank you so much for your professional advice!
I understand every step we make will have certain level of risk. However, you have tried your best to help me analyse the situation. Total loss of the router will always be the worst case scenario and I am always prepared for that.
I will backup all files in the said directory to to reduce the risk.
Now, I must first learn how to generate the new certificate/key in your instructions 3b to 3e.
Is it required to change the “/tmp/server_phone.conf” file when changing a stronger encryption method?
It is because OpenVPN connect for both Android & iOS no longer support MD5 after April 30.
- Diggie3Feb 28, 2018Luminary
It should not be required to change “/tmp/server_phone.conf”, and in fact it is probably not possible to do that either.
The MD5 algorithm is used by the original certificates. Following the PDF should cause these to be replaced. The PDF has steps to produce certificates using SHA256, which is much stronger.
- Diggie3Feb 28, 2018Luminary
NG_Guru I went to investigate http://192.168.1.1/debug.htm . I found that:
* It did not exist on R7000 FW versions 1.7.x.
* It does exist on the latest FW version, 1.9.26, but the code to display and send the telnet option to the router have been commented out in debug.htm, so it's not user accessible. This FW is less than a month old.
Therefore I think this option is very likely to be dependent on which model you have and which firmware version you are using. Clearly the page doesn't always exist, and if it does exist NG may be disabling that option.
- Diggie3Feb 28, 2018Luminary
Thanks everyone for feedback so far. Attached is version 1.0.1. I fixed some typos, added a suggestion to clean up your tftp folder when you're done, and made a note about the OpenVPN version that's most compatible with the document.
Some users looking to work through this doc may find that they can avoid Step 1 by visiting this hidden page:
If the debug page loads and there is an "Enable Telnet" option then you got lucky. Note that either the debug page or the option to "Enable Telnet" may not exist on your device or firmware version. Remember to check that this option is disabled after you're finished because having telnet enabled is a security risk.
- katsawFeb 28, 2018Guide
Diggie3wrote:Thanks everyone for feedback so far. Attached is version 1.0.1. I fixed some typos, added a suggestion to clean up your tftp folder when you're done, and made a note about the OpenVPN version that's most compatible with the document.
Some users looking to work through this doc may find that they can avoid Step 1 by visiting this hidden page:
If the debug page loads and there is an "Enable Telnet" option then you got lucky. Note that either the debug page or the option to "Enable Telnet" may not exist on your device or firmware version. Remember to check that this option is disabled after you're finished because having telnet enabled is a security risk.
Thanks for the new update of your instruction guide.
I am so luck that my R6220 router still have the "debug.htm" hidden page and with the "enable telnet" option.
Thanks for answering all my questions in these days.
No matter I can successfully change the VPN key / certificate with your method or not, I will get back to this post to confirm.
- fcolMar 01, 2018Tutor
Diggie3 - I just followed your 1.0.1 instructions and successfully replaced my keys onto my R7000. Those instructions were excellent. Thank you so much for taking the time to do this!
- katsawMar 02, 2018Guide
Diggie3wrote:
Thanks everyone for feedback so far. Attached is version 1.0.1. I fixed some typos, added a suggestion to clean up your tftp folder when you're done, and made a note about the OpenVPN version that's most compatible with the document.
Some users looking to work through this doc may find that they can avoid Step 1 by visiting this hidden page:
If the debug page loads and there is an "Enable Telnet" option then you got lucky. Note that either the debug page or the option to "Enable Telnet" may not exist on your device or firmware version. Remember to check that this option is disabled after you're finished because having telnet enabled is a security risk.
Hi Diggie3,
Unfortunately the result for my R6220 is negative. I completed all the procedures described in your instructions and reboot the router. After robooting, OpenVPN cannot be connected by using the new certificate but the old certificate still function properly instead.
By enabling telnet thru’ “192.168.xx.1/debug.htm” again, I found that all the files under the directory “/tmp/openvpn” have been restored to the originals. The newly added files “originalkeys.zip” & “newkeys.zip” during the procedures have been removed.
It seems R6220 router only stored the files to /tmp/openvpn temporary but have other true location to store the actual certificates.
Also, every reboot will clear the setting of “enable telnet”.
During the discussion to this post in this week, the router have not been rebooted. Therefore I have just discovered this fact yesterday.
Remark: I have checked the updated files in “/tmp/openvpn” by “cat” command before rebooting”, all the 6 mentioned files should have been updated.
- Diggie3Mar 02, 2018Luminary
katsaw You could try this:
cat /proc/mounts
Here's some output from the R7000:
/dev/mtdblock18 /tmp/openvpn jffs2 rw,relatime 0 0
The reason we can update the keys is that /tmp/openvpn is a read-write jffs2 filesystem, which is a compressed, non-volatile file system. That was a smart move on Netgear's part. See if you have something similar. The R7000 also has /tmp/media/nand of this type, but there's no OpenVPN content there on the R7000, and I don't know how safe it would be to modify that one (I haven't tried).
- katsawMar 02, 2018Guide
Diggie3wrote:katsaw You could try this:
cat /proc/mounts
Here's some output from the R7000:
/dev/mtdblock18 /tmp/openvpn jffs2 rw,relatime 0 0
The reason we can update the keys is that /tmp/openvpn is a read-write jffs2 filesystem, which is a compressed, non-volatile file system. That was a smart move on Netgear's part. See if you have something similar. The R7000 also has /tmp/media/nand of this type, but there's no OpenVPN content there on the R7000, and I don't know how safe it would be to modify that one (I haven't tried).
Thanks for your prompt reply!Here it is:
# # cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / squashfs ro,relatime 0 0
ramfs /dev ramfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
none /tmp ramfs rw,relatime 0 0
none /media ramfs rw,relatime 0 0
none /sys sysfs rw,relatime 0 0
none /proc/bus/usb usbfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
/dev/sda1 /tmp/mnt/shares/U vfat rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp950,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0
#