Custom firmware build for Orbi RBK50/RBK53 (RBR50, RBS50) v. 9.2.5.1.11SF-HW

[CrimpOn]

So near, and yet so far. Bought a spare RBR50 on eBay. Updated it to Netgear stock 2.3.5.0 and then to Voxel 9.2.5.1.11FS-HW. Saved the config file from my 'production' RBR50, loaded it to the 'Voxel' RBR50 and swapped them. HOT DAMN. Not only does it work, but all my devices reconnected, including the RBS50 satellite which I did not update. The device names/types tables were completely messed up, but that's a simple editing chore, and "who needs them anyway." HOWEVER, I have been using OpenVPN for remote management, and OpenVPN FAILS. Tried two connections that worked before (smartphone and Linux). Both would not connect. I am looking forward to seeing how great Wireguard is compared to OpenVPN, but did not realize that this firmware was going to render OpenVPN inoperable. Will try to debug by generating new OpenVPN files. DAMN. If someone has advice about OpenVPN and this firmware, I am eager to hear it. I do not want to go back!

 

[Voxel]

Saved the config file from my 'production' RBR50, loaded it to the 'Voxel' RBR50 and swapped them.

HOWEVER, I have been using OpenVPN for remote management, and OpenVPN FAILS.

I checked OpenVPN server with Orbi. Well, it was almost two months ago, but it was workable.

Few thing to note:

1. You have swapped two different RBR50. Restoring config from the first to second. But config does not store/restore certificate files for OpenVPN: they are kept on the special partition. So your previous OpenVPN client certificate and new OpenVPN server certificate are different.

2. I've changed default ciphers and compression for ORBI. To increase the speed of connection and security (CBC-AES-128, lzo to GCM-AES-128, lz4v2). So previous configs from your former RBR will not work. It is necessary to download client configs anew even if certificate files would be the same.

So try to download your OpenVPN client configs from new RBR

3. If still not working: the same procedure (1, 2) above) but before this try to regenerate certificates on new RBR from telnet/ssh:

a. Stop your OpenVPN servers
b. Enter to telnet/ssh console
c. run the command

/etc/init.d/openvpn regenerate_cert_file

d. reboot your RBR​

Voxel.

 

[Voxel]

I am looking forward to seeing how great Wireguard is compared to OpenVPN,

NOTE: different suffs. I've added WireGuard client to the firmware (to route all your devices in your LAN through remote WG server, WG provider). You are talking re: OpenVPN server (to connect externally to your home LAN).

Voxel.

 

[CrimpOn]

I checked OpenVPN server with Orbi. Well, it was almost two months ago, but it was workable.

So try to download your OpenVPN client configs from new RBR -- Did that with smartphone & Windows. No connect. (My Linux is fighting me on creating new VPN connections.)

3. If still not working: the same procedure (1, 2) above) but before this try to regenerate certificates on new RBR from telnet/ssh:

a. Stop your OpenVPN servers -- By unchecking the box "Enable VPN Service"?
b. Enter to telnet/ssh console
c. run the command

/etc/init.d/openvpn regenerate_cert_file

d. reboot your RBR​

Voxel.

Then, after Orbi reboots, return to "Enable VPN Service", download new config files for smartphone, Windows, non-Windows.

Thanks for your patience. Now, to wait until family vacates house!

 

[CrimpOn]

NOTE: different suffs. I've added WireGuard client to the firmware (to route all your devices in your LAN through remote WG server, WG provider). You are talking re: OpenVPN server (to connect externally to your home LAN).

Voxel.

Of course, thanks for clarifying. Many people want to "encrypt and hide everything" and the greater efficiency of Wireguard allows the Orbi to do that. At this time, I only want a single client to have access from outside. OpenVPN allows clients to "turn around" and access the internet from the Orbi. In that case, I guess that OpenVPN could get traffic in, and Wireguard could take it back out.

 

[CrimpOn]

I checked OpenVPN server with Orbi. Well, it was almost two months ago, but it was workable.

Few thing to note:

1. You have swapped two different RBR50. Restoring config from the first to second. But config does not store/restore certificate files for OpenVPN: they are kept on the special partition. So your previous OpenVPN client certificate and new OpenVPN server certificate are different.

2. I've changed default ciphers and compression for ORBI. To increase the speed of connection and security (CBC-AES-128, lzo to GCM-AES-128, lz4v2). So previous configs from your former RBR will not work. It is necessary to download client configs anew even if certificate files would be the same.

So try to download your OpenVPN client configs from new RBR

3. If still not working: the same procedure (1, 2) above) but before this try to regenerate certificates on new RBR from telnet/ssh:

a. Stop your OpenVPN servers
b. Enter to telnet/ssh console
c. run the command

/etc/init.d/openvpn regenerate_cert_file

d. reboot your RBR​

Voxel.

Amazing! Works fine on Android phone and Windows. (My Linux machine is engaged in a battle of wits over OpenVPN, and it remains smarter than I am.)

I had missed one tiny difference in OpenVPN between Netgear stock and Voxel's firmware: The stock firmware "Attached Devices" shows the VPN client with MAC address 00:00:00:00:00:00 and an IP address in a different subnet (192.168.2.x vs. 192.168.1.x). This firmware shows a MAC address of 00:FF:33:F9:F5:2F and assigns an IP address from the DHCP pool (in the 192.168.1.x subnet).

Appears that my original Orbi will sit on a shelf until Netgear releases new firmware.

Thank You, Voxel

 

[CrimpOn]

Amazing! Works fine on Android phone and Windows. (My Linux machine is engaged in a battle of wits over OpenVPN, and it remains smarter than I am.)

I had missed one tiny difference in OpenVPN between Netgear stock and Voxel's firmware: The stock firmware "Attached Devices" shows the VPN client with MAC address 00:00:00:00:00:00 and an IP address in a different subnet (192.168.2.x vs. 192.168.1.x). This firmware shows a MAC address of 00:FF:33:F9:F5:2F and assigns an IP address from the DHCP pool (in the 192.168.1.x subnet).

Mint Linux finally relented. Appears that the .ovpn file for "smartphone" (which is what Network Manager wants to import) has an invalid parameter on line 3. "proto udp4" instead of "proto udp". One tiny "4" and Network Manager failed with a totally bogus error message. There is a workaround using the network manager command line interface, which identified the error. Removed the "4" and now Linux connects. (Both the Windows and 'nonWindows' files contain the same "udp4", but apparently Windows and Android OpenVPN are not as picky as Mint Linux Network Manager.)

However.....

On this connection, the VPN device clearly received an IP address in the 192.168.2.x subnet, as OpenVPN had been doing before, BUT

• The device connected over OpenVPN does not appear in "Attached Devices" at all.
• Over the VPN connection I can ping some devices on the Orbi LAN, but not all of them. When connected directly to Orbi, they ping fine.

I plan to test this several more times, perhaps with a reboot between attempts.

 

[e38BimmerFN]

Hey Voxel, do you happen to know if your version of Orbi FW will work on the RBR50 v2? The v2s have less memory and no USB port. Otherwise, from the specs, there about the same in HW. Would lesser memory be of any concern with your FW? Asking for a friend.

 

[ChristianEhrlicher]

I've a question to the ethernet backhaul - is there a reason why it only works when the first (white) network port is used at the RBR to connect to the satellites? My RBR is connected to a switch which on the one side is connected to the internet router and on the other to my internal network (where also the satellite is connected). Therefore in theory there is no need to connect the first white ethernet port to the switch - but as soon as it's not connected the website says that the connect is wireless. When I plug in the second network cable which is also connected to the switch, the website correctly tells that the connection to the satellite is wired.

 

[LJ H]

Hey Voxel, do you happen to know if your version of Orbi FW will work on the RBR50 v2? The v2s have less memory and no USB port. Otherwise, from the specs, there about the same in HW. Would lesser memory be of any concern with your FW? Asking for a friend.

it works fine. i've used his FW with both v1 and v2 Orbis.

 

[e38BimmerFN]

Thank you LJH.

 

[jarvismeier]

I’ve had the same issue with the factory reset. If I perform the reset the router doesn’t boot until I re-flash with stock firmware.

Also have noticed Ethernet backhaul doesn’t work well in AP mode when connected to a managed switch (might be a STP issue). Works great once it’s connected to the back of the RBR.


Sent from my iPhone using Tapatalk

 

[e38BimmerFN]

IF you have a managed switch. Disable ALL IGMP Protocols on this switch. Also Switches with Green Ethernet features are really compatible with Orbi. This happens on stock FW as well.

Haven't seen my RBR not reboot fully if I factory reset it. I use the web page UI for doing this.

I’ve had the same issue with the factory reset. If I perform the reset the router doesn’t boot until I re-flash with stock firmware.

Also have noticed Ethernet backhaul doesn’t work well in AP mode when connected to a managed switch (might be a STP issue). Works great once it’s connected to the back of the RBR.


Sent from my iPhone using Tapatalk

 

[Hammerfest]

I’ve had the same issue with the factory reset. If I perform the reset the router doesn’t boot until I re-flash with stock firmware.

Also have noticed Ethernet backhaul doesn’t work well in AP mode when connected to a managed switch (might be a STP issue). Works great once it’s connected to the back of the RBR.


Sent from my iPhone using Tapatalk

thanks for confirming the factory reset keel over, hopefully you knew how to TFTP or my post helped recover
I have not had the time to flash the older versions to see if they cause the same issue

 

[CrimpOn]

On this connection, the VPN device clearly received an IP address in the 192.168.2.x subnet, as OpenVPN had been doing before, BUT

• The device connected over OpenVPN does not appear in "Attached Devices" at all.
• Over the VPN connection I can ping some devices on the Orbi LAN, but not all of them. When connected directly to Orbi, they ping fine.

I plan to test this several more times, perhaps with a reboot between attempts.[/QUOTE]

After more testing, I find that Android, Linux, and Windows all connect to OpenVPN on Voxel V9.2.5.1.11SF-HW. All of them seem to get an IP address in the 192.168.2.x subnet. All of them can conduct iPerf3 tests with a iPerf3 server in the 192.168.1.x subnet. However, there are differences:

• Only the Windows OpenVPN client shows up in the "Attached Devices" display. The Android (phone & tablet) and the Linux do not.
• Only the Winidows OpenVPN client is able to "ping" or print to clients in the 192.168.1.x subnet. The Android clients cannot ping and cannot print.

I looked at the ovpn files and there are differences:

• Android (my Linux also uses the "smartphone" ovpn) use "tun" to udp port 12973.
  Windows uses "tap" to 12974.
• As explained by Voxel, the stock Orbi uses AES-128-CBC, compression comp-lz0, and Voxel uses AES-128-GCM and compression lz4-v2
• Voxel has a line in ovpn that stock Orbi lacks, "remote-cert-tls server"
• Windows ovpn has a line that is not present in smartphone ovpn, and they are different: stock Orbi reads "dev-node NETGEAR-VPN", Voxel reads ";dev-node NETGEAR-VPN"
  The leading ";" makes it a comment line?

So, it appears that OpenVPN on the Orbi treats "tun" connections different from "tap" connections?

 

[CrimpOn]

On this connection, the VPN device clearly received an IP address in the 192.168.2.x subnet, as OpenVPN had been doing before, BUT

• Only the Windows OpenVPN client shows up in the "Attached Devices" display. The Android (phone & tablet) and the Linux do not.
• Only the Winidows OpenVPN client is able to "ping" or print to clients in the 192.168.1.x subnet. The Android clients cannot ping and cannot print.

Another embarrassing revelation. Orbi LAN computers did not respond to ping because the Windows Firewall blocked ICMP from other subnets. Allowed that (in File and Printer Sharing - who would EVER think to look THERE?). Now, Linux over "tun" VPN pings devices just like Windows over "tap" VPN pings them. I have used up my quota of blunders for today.

The devices which VPN using "tun" still do not appear on the Attached Devices web page.

 

[Voxel]

I've a question to the ethernet backhaul - is there a reason why it only works when the first (white) network port is used at the RBR to connect to the satellites? My RBR is connected to a switch which on the one side is connected to the internet router and on the other to my internal network (where also the satellite is connected). Therefore in theory there is no need to connect the first white ethernet port to the switch - but as soon as it's not connected the website says that the connect is wireless. When I plug in the second network cable which is also connected to the switch, the website correctly tells that the connection to the satellite is wired.

Do you face the same when using stock 2.5.1.8?

Voxel.

 

[Voxel]

• The device connected over OpenVPN does not appear in "Attached Devices" at all.
• Over the VPN connection I can ping some devices on the Orbi LAN, but not all of them. When connected directly to Orbi, they ping fine.

I plan to test this several more times, perhaps with a reboot between attempts.

You should not test a lot. Devices connected to tun OpenVPN server will not appear in "Attached Device" list. It is especially disabled by me. There was a problem with 2.5.0.40 stock I've used as a basis for my very first build. OpenVPN tun clients spoiled the list of "Attached Devices". Later NG/DBI have released 2.5.1.8 changing the scheme of processing this "Attached Device" creation but I still did not enable tun clients. Reason: no time for testing. Testing OpenVPN for me is now a bit troublesome. RBR50 is set now as a main router in my country house (serving a lot of devices, including special house monitoring system during my absence) and it is behind NAT (I can use only LTE modem connection, but it is not bad: 110-120Mbps/40-45Mbps). So reconfiguration i.e. moving Orbi to other role allowing to test OpenVPN is troublesome: I am far away of my country house.

Devices using OpenVPN tap server are included into list of "Attached Device".

Difference tun vs tap: when using tap your device is in the same subnet of your LAN. So it can easily access other devices in your LAN. For tun: it is other subnet. 192.168.2.x. So it is why firewall of your devices from 192.168.1.x "think" that it is alien device. There is possibility to allow such alien access, described e.g. for R9000:

https://www.snbforums.com/threads/c...r-r9000-r8900-v-1-0-4-38hf.61402/#post-546461

So if you want to play with this right now... It is possible to do that.

I am really extremely busy now, my main job. I had to think over this (access of home LAN using tun OpenVPN server). But not right now. Sorry.

Voxel.

 

[CrimpOn]

[QUOTE="Devices connected to tun OpenVPN server will not appear in "Attached Device" list. It is especially disabled by me. There was a problem with 2.5.0.40 stock I've used as a basis for my very first build. OpenVPN tun clients spoiled the list of "Attached Devices". Later NG/DBI have released 2.5.1.8 changing the scheme of processing this "Attached Device" creation but I still did not enable tun clients.
.....
Difference tun vs tap: when using tap your device is in the same subnet of your LAN. So it can easily access other devices in your LAN. For tun: it is other subnet. 192.168.2.x. So it is why firewall of your devices from 192.168.1.x "think" that it is alien device. There is possibility to allow such alien access, described e.g. for R9000:
Voxel.[/QUOTE]

Thank you for the explanation. Makes perfect sense. Having vpn devices appear in "Attached Devices" is not critical.

 

[Voxel]

Thank you for the explanation. Makes perfect sense. Having vpn devices appear in "Attached Devices" is not critical.

Well, should be fixed of course. In my 2do list. As well as access to LAN from the tun client (rather new feature not fix). But not right now.

Voxel.