What's new

Custom firmware build for R7800 v. 1.0.2.23SF & v. 1.0.2.24SF

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Okay Voxel, I've loaded your new 23SF firmware over my original Netgear R7800 firmware and it started working fine for the most part.
It's been running for a couple of days with my original configuration. All the major functions I use are working solid and fine. Just one area I need to ask you about... the OpenVPN does not work for me any longer. I've tried using the standard version as well as your new v2.4.x setting for UDP and auto settings. My Android phone app which worked fine with the original Netgear firmware always connected immediately and fine. But I cannot get this 23F version to connect at all. Tried 2 different OpenVPN apps from Android playstore and they won't connect. Is there something else I need to do? Other than this quirk, I notice that the firmware does run quicker, the GUI pages appear more snappier than original firmware. So everything looks great for me except for the OpenVPN issue.


I need more details: of course I’m using OpenVPN, both TAP and TUN. But I do not have Andriod gadgets unfortunately. I connect to my OpenVPN from two remote Windows computers and it's working.

Could you check what is in your OpenVPN server logs (/tmp/openvpn_log and /tmp/openvpn_tun_log)? What CA/CRT/KEY/DH are you using? I mean that I use my own CA/CRT/KEY/DH, not generated from FW. Do you use TAP or TUN? Did you install client configs downloaded from my FW or you used what was generated by stock FW, etc. Just more detailed info.

Voxel.
 
Is it possible to block some sites, ads or similar with this firmware? Something like in this open-wrt topic: https://forum.openwrt.org/viewtopic.php?id=35023

akku from myopenrouter did something like that:

https://www.myopenrouter.com/comment/40523#comment-40523

with privoxy from Entware. I myself use privoxy with ads blocking.

It should work. Most simple way if you do not want to use Entware is to use dnscrypt-proxy with AdGuard DNS

https://www.myopenrouter.com/comment/40528#comment-40528


Voxel.
 
I need more details: of course I’m using OpenVPN, both TAP and TUN. But I do not have Andriod gadgets unfortunately. I connect to my OpenVPN from two remote Windows computers and it's working.

Could you check what is in your OpenVPN server logs (/tmp/openvpn_log and /tmp/openvpn_tun_log)? What CA/CRT/KEY/DH are you using? I mean that I use my own CA/CRT/KEY/DH, not generated from FW. Do you use TAP or TUN? Did you install client configs downloaded from my FW or you used what was generated by stock FW, etc. Just more detailed info.

Voxel.
I am using the keys that are generated by the firmware. The android apps are using TUN UDP. I transfer the client smartphone.ovpn file to my Android phone and import it into the OpenVPN client app(s). But apps get failure to connect (some error messages say no TLS session found or something).
I just looked at the two openvpn logs you asked for and see that it is looking for a /etc/openvpn/config/dh*.pem file which is not found. It does not exist on my router.
Here are cut and paste of the two logs contents (they show the same messages):
/tmp/openvpn_log file shows:
Sat Feb 18 12:08:33 2017 OpenVPN 2.4.0 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sat Feb 18 12:08:33 2017 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09
Sat Feb 18 12:08:33 2017 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Sat Feb 18 12:08:33 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Feb 18 12:08:33 2017 OpenSSL: error:02001002:lib(2):func(1):reason(2)
Sat Feb 18 12:08:33 2017 OpenSSL: error:2006D080:lib(32):func(109):reason(128)
Sat Feb 18 12:08:33 2017 Cannot open /etc/openvpn/config/dh*.pem for DH parameters
Sat Feb 18 12:08:33 2017 Exiting due to fatal error

/tmp/openvpn_tun_log shows:
Sat Feb 18 12:08:33 2017 OpenVPN 2.4.0 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sat Feb 18 12:08:33 2017 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09
Sat Feb 18 12:08:33 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Feb 18 12:08:33 2017 OpenSSL: error:02001002:lib(2):func(1):reason(2)
Sat Feb 18 12:08:33 2017 OpenSSL: error:2006D080:lib(32):func(109):reason(128)
Sat Feb 18 12:08:33 2017 Cannot open /etc/openvpn/config/dh*.pem for DH parameters
Sat Feb 18 12:08:33 2017 Exiting due to fatal error
root@R7800:/tmp$

I think there is a missing parameters dh file setup? Or did I miss some manual steps that I needed to perform to set up the new firmware for openvpn? Do I have to create this file on my own like running the command something like this:

"openssl dhparam -out dh2048.pem 2048" (got this example from openvpn community wiki web site).

I found the dh1024.pem file in /tmp/openvpn directory... should I copy all the config files the /tmp/openvpn over to the /etc/openvpn directory?

Update: I just copied over all the config and key files from the /tmp/openvpn directory to the /etc/openvpn/config/ directory and restarted openvpn... it now says it started successfully and no errors. I will check to see if I can get my openvpn clients to connect now...
 
Last edited:
The problem is that, in Voxel firmware openvpn script configs files check in the /etc/openvpn/config. Your files, automatically generated in the /tmp/openvpn.

Solving the problem, edit the script or put your files in the /etc/openvpn/config. ;)
 
The problem is that, in Voxel firmware openvpn script configs files check in the /etc/openvpn/config. Your files, automatically generated in the /tmp/openvpn.

Solving the problem, edit the script or put your files in the /etc/openvpn/config. ;)
Hi, yes, I saw that in the openvpn script... I had just tried to copy over all the files to the /etc/openvpn/config directory and restarted openvpn.
It says it succeeded now but there is still a log message that says it " Could not determine IPv4/IPv6 protocol. Using AF_INET6".
I re-downloaded the smartphone client key certificate to my Android apps and still not connecting.

I am getting openvpn_tun_log TLS errors: " TLS Error: TLS handshake failed"
 
Last edited:
Show your client.ovpn.
root@R7800:/etc/openvpn/config$ cat client.ovpn
client
dev tap
proto udp
dev-node NETGEAR-VPN
remote <myWANipaddress> 12974
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC
comp-lzo
;compress lz4-v2
verb 0
sndbuf 393216
rcvbuf 393216

Reminder: I am using tun not tap... ?
 
Comment this line

you have the port open?
The port should be open as I am getting log entries of the Android client attempting to connect.
Question for the client.ovpn file... Does # character comment out the line or does the ; character comment out the line? or both can comment out lines? I tried commenting it out with # character but still no go.
I tried to reboot the router fresh with the changed settings and still no go.
But upon a reboot of the router the /tmp/openvpn_log does have one extra message saying " WARNING: Your certificate is not yet valid!".

Question: should the key and certificate files provided straight from Voxel's firmware install work or do I need to go through a procedure to regenerate all the keys? Apparently my keys are not validating properly between client and server. This needs to be corrected in the package I guess.

Here is the message I get in the /tmp/openvpn_tun_log when the Android client is trying to connect:

Sun Feb 19 18:08:24 2017 <my_ipaddress> TLS Error: TLS handshake failed
Sun Feb 19 18:08:24 2017 <my_ipaddress> SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Feb 19 18:08:26 2017 <my_ipaddress> TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
 
Last edited:
The port should be open as I am getting log entries of the Android client attempting to connect.
Question for the client.ovpn file... Does # character comment out the line or does the ; character comment out the line? or both can comment out lines? I tried commenting it out with # character but still no go.
I tried to reboot the router fresh with the changed settings and still no go.
But upon a reboot of the router the /tmp/openvpn_log does have one extra message saying " WARNING: Your certificate is not yet valid!".

Question: should the key and certificate files provided straight from Voxel's firmware install work or do I need to go through a procedure to regenerate all the keys? Apparently my keys are not validating properly between client and server. This needs to be corrected in the package I guess.

Here is the message I get in the /tmp/openvpn_tun_log when the Android client is trying to connect:

Sun Feb 19 18:08:24 2017 <my_ipaddress> TLS Error: TLS handshake failed
Sun Feb 19 18:08:24 2017 <my_ipaddress> SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Feb 19 18:08:26 2017 <my_ipaddress> TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

OK, thanks for detailed info. Really, some problems with ca/crt/key/dh generated by firmware. I was able to reproduce. I do debug now. It is just FYI. Of course user should be able to use as own ca/crt/key/dh as generated by firmware. Bug. I need some time for fixing.

Voxel.
 
Sun Feb 19 18:08:24 2017 <my_ipaddress> TLS Error: TLS handshake failed
Sun Feb 19 18:08:24 2017 <my_ipaddress> SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Feb 19 18:08:26 2017 <my_ipaddress> TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
I checked how it works my Ovpn, got the similar Error (
I immediately checked after installing 23SF my Ovpn, and it worked just fine. Certificates I use my own generated .....
 
Voxel,

I have been using your modified firmware and it has been very stable. I do have one question. I have been unable to setup any TCP/UDP port forwarding under the Advanced Setup section. I went back to your readme file and in section five it mentioned creating a text file for port forwarding. So is that a trade off for using your modified firmware?

Phantom
 
So is that a trade off for using your modified firmware?
No, this is only for the router address (192.168.1.1) . All open ports for other addresses (192.168.1.100 - 192.168.1.150) work fine for me.
Example:
Using a text file, I have opened a port for Transmission 192.168.1.1:51413 and ssh 22.
Using a port forwarding, I have opened a port for WD EX2 Transmission 192.168.1.105:51928.

P. S. I suppose that Netgear uses multiple ports for their needs. Therefore, they do not work from WAN.
 
Last edited:
OK, thanks for detailed info. Really, some problems with ca/crt/key/dh generated by firmware. I was able to reproduce. I do debug now. It is just FYI. Of course user should be able to use as own ca/crt/key/dh as generated by firmware. Bug. I need some time for fixing.

Voxel.
Okay Voxel. I just remembered that I had returned a R7000 router a couple of years ago because of Netgear's poor openvpn implementation which does not allow users to generate their own unique certificates and keys. A very huge and serious security exposure. I hope the updated openvpn mods you are putting in will allow us to secure this router much more securely and let us be able to generate our own unique config certificates and keys. There is talk on Netgear forums for the R7000 router about their poor openvpn. Some are wondering if every Netgear router is generating the same exact key for everyone so that anyone else with a Netgear certificate key can access anyone elses Netgear openvpn! Wow! if so what a security leak exposure! I hope your openvpn mods fix this security exposure otherwise Netgear routers are not good for openvpn use. turn it off then.
 
Okay Voxel. I just remembered that I had returned a R7000 router a couple of years ago because of Netgear's poor openvpn implementation which does not allow users to generate their own unique certificates and keys. A very huge and serious security exposure. I hope the updated openvpn mods you are putting in will allow us to secure this router much more securely and let us be able to generate our own unique config certificates and keys. There is talk on Netgear forums for the R7000 router about their poor openvpn. Some are wondering if every Netgear router is generating the same exact key for everyone so that anyone else with a Netgear certificate key can access anyone elses Netgear openvpn! Wow! if so what a security leak exposure! I hope your openvpn mods fix this security exposure otherwise Netgear routers are not good for openvpn use. turn it off then.
Well, as I wrote in my readme.docx that it is possible to use own CA/CRT/KEY/DH files for OpenVPN. I use my own files for OpenVPN (security reasons) so it is why I did not detect this problem with such files generated by firmware. It is enough to copy your own files to /etc/openvpn/config directory (or in /root/openvpn directory) and they will be used instead of generated by Netgear. Files mask should be:

Code:
*ca.crt    CA file
*.crt      CERT file
*.key      KEY file
dh*.pem    DH file

Of course you also should generate and use corresponding client keys/certs.

Currently I am satisfied by functionality security and speed of OpenVPN in my build. I use both TUN and TAP.


P.S.

Anyway I have to release new version with fixing this bug. Users should be able to run keys/certs generated by firmware.


Voxel.
 
root@R7800:/etc/openvpn/config$ cat client.ovpn
client
dev tap
proto udp
dev-node NETGEAR-VPN
remote <myWANipaddress> 12974
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC
comp-lzo
;compress lz4-v2
verb 0
sndbuf 393216
rcvbuf 393216

Reminder: I am using tun not tap... ?

On my R7000 (with DD-WRT, new openvpn ver 2.4) I use:

proto udp4

this fixed the connection problem
 
On my R7000 (with DD-WRT, new openvpn ver 2.4) I use:

proto udp4

this fixed the connection problem

There is a bug in init script in my build. Problem is not in client, but in server. Although this "dev-node NETGEAR-VPN" is obsolete line for old versions of Windows.

Voxel.
 
Voxel,

I have been using your modified firmware and it has been very stable. I do have one question. I have been unable to setup any TCP/UDP port forwarding under the Advanced Setup section. I went back to your readme file and in section five it mentioned creating a text file for port forwarding. So is that a trade off for using your modified firmware?

Phantom

It is strange: I use about 20 port forwardings rules set from WebGUI. As TCP as UDP. I know other people use port forwarding. Do you use IP addresses reservation to forward?

My readme describes how to open ports, not forwarding.

Voxel.
 
Okay Voxel, I've loaded your new 23SF firmware over my original Netgear R7800 firmware and it started working fine for the most part.
It's been running for a couple of days with my original configuration. All the major functions I use are working solid and fine. Just one area I need to ask you about... the OpenVPN does not work for me any longer. I've tried using the standard version as well as your new v2.4.x setting for UDP and auto settings. My Android phone app which worked fine with the original Netgear firmware always connected immediately and fine. But I cannot get this 23F version to connect at all. Tried 2 different OpenVPN apps from Android playstore and they won't connect. Is there something else I need to do? Other than this quirk, I notice that the firmware does run quicker, the GUI pages appear more snappier than original firmware. So everything looks great for me except for the OpenVPN issue.

I created fix version 1.0.2.24SF. Please check it with your Android and default key/crt. Should be OK now.

https://www.mediafire.com/folder/tyj61i5uc610w/voxel-firmware

Voxel.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top