NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
RBE970/RBE971 Routing Issues
I have an Orbi RBE970/RBE971 mesh environment that was set to auto-upgrade, but I noticed it was still running 9.12.4.16 even though the firmware update page said that upgrades were available. I used the online upgrade to the offered 12.1.10.12.
After the upgrade, I am seeing some LAN to LAN network connections appear to the server on the connection (HTTP, SSH, etc.) to come from the internet interface. This prevented connections due to firewall rules on my servers that only allow connections from my internal LAN network IP range.
Oddly, some connections between internal hosts do not exhibit this behavior.
Additionally, connections from internal hosts to my internet facing IP address are no longer forwarded to the configured port forward host. And again, this is inconsistent depending on what host I initiate the connection from.
I manually updated to 12.1.11.15, but that did not change any behavior.
The Protection Engine was enabled, but I disabled it and rebooted all devices, and there was no change.
The only pattern that I can find is that the different and unexpected/undesired behavior is to/from virtual machines on a VMware ESXi server. But it's not for all services.
To make this real, I have an internal subnet of 172.x.x.0/24. Let's call that network $A. Here are my hosts and ip addresses:
Orbi router: $A.254
MacBook1 Ethernet directly connected to Orbi router: $A.8
MacBook1 Wireless: $A.9
MacBook2 Wireless: $A.111
Linux Server in VMware: $A.1
Windows 11 in VMware: $A.138
Internet network interface: $B
Linux iptables firewall only allows connections from $A.0/24 and a handful of trusted internet hosts.
Port forwarding is configured on the Orbi router for several services including SSH, HTTP, HTTPS, etc. to $A.1.
ssh from MacBook1 and MacBook2 to $A.1 fails because the Linux server ($A.1) sees it as coming from $B.
ssh from MacBook1 to MacBook2 works just fine.
ssh from Windows 11 to Linux server (both in VMware environment) works fine.
HTTP connections from MacBook1 and MacBook2 to $B (which is port forwarded to $A.1) work just fine.
HTTP connections from $A.1 to $B (which is port forwarded back to $A.1) timeout. This is not a firewall issue.
As soon as I open SSH in the Linux firewall to allow connections from $B, all works. netstat and who confirm the connection is coming from $B even though the client connections started on same subnet.
I pulled the debug logs from the router, but I can't see anything that looks out of place in the routing or interface definitions. I may not know exactly what to look for.
I thought I would downgrade to see if the problem went away, but it seems you can't go back to 9.x from 12.x.
Any thoughts on how best to diagnose this further would be more than welcome.
11 Replies
After the upgrade, I am seeing some LAN to LAN network connections appear to the server on the connection (HTTP, SSH, etc.) to come from the internet interface.
What is the switch and firewall topology?
The Orbi is my firewall. I have a Netgear GS108 switch directly connected to the Orbi that handles the rest of the ethernet traffic in the house, but none of the hosts described above are connected to it. They are all either wireless to the router (not a satellite) or direct ethernet to the router.
The Orbi is my firewall. I have a Netgear GS108 switch directly connected to the Orbi that handles the rest of the ethernet traffic in the house, but none of the hosts described above are connected to it. They are all either wireless to the router (not a satellite) or direct ethernet to the router.
Thx. So when you talk about the "linux firewall", are you actually talking about the iptables config in your $A.1 linux server?
HTTP connections from $A.1 to $B (which is port forwarded back to $A.1) timeout.So hairpinning from $A.1 to $A.1 doesn't work.
Do HTTP connections from $1.138 to $B work ok?
ssh from MacBook1 and MacBook2 to $A.1 fails because the Linux server ($A.1) sees it as coming from $B.
Does traceroute give any clues?
Maybe take a packet trace on whatever physical server is hosting $A.1, and take a look at the source addresses.
Yes.
Does this happen when using the default 192.168.1.1 subnet?
There is newer FW up as well:
New - RBE970 Series v12.1.11.15 Firmware Release - WW Region | NETGEAR Communities
Sorry for the delay in engagement. It took a while before I had the time to re-IP my network.
I am running the 12.1.11.15 firmware. The auto-updated didn't take me all the way there, but when I started having issues on 12.1.10.12, I manually updated to 12.1.11.15.
And now for something strange ...
I re-IP'd to 192.168.1.0/24 and kept all the host addresses the same (most are static IP assignments, but some are DHCP serviced by $A.1 - I don't use the Orbi DHCP server). I saw no change in behavior.
But after putting everything back to the 172.29.x.x/24 network, internal network connections all show as coming from internal hosts and not the internet host. The hairpinning still doesn't work with a "network is unreachable" message from a telnet client, but I'm happier to live with that than remove all the host- and service-based configuration that restricts network connections to my internal networks.
I even powered everything off (laptops, VMware server, Orbi router and remotes) and let it settle for a while. And I'm still in the spot of internal routing seeming to stay internal.
I am good with this state for now. Thanks for the guidance!
Interestingly, I just realized that while network connections (HTTP, HTTPS, SMTP, etc.) do not work from an internal host to my internet IP address, ping/traceroute do.
Well, I figured it out. Quite by accident.
While re-IP'ing and reverting the re-IP'ing seemed to make more things work, I just now realized that the process of doing that messed up the Port Forwarding tables. The internal start port and internal IP address were changed. Originally, they looked like
HTTPS 443 443 $A.1
I didn't check to see what it looked like when I re-IP'd to 192.168.1.x/24. But after putting the network back to 172.29.x.x/24 ($A), all of the port forwarding entries looked ike
HTTPS 443 172 $A.172
For all the port forwards that are a direct port match (e.g. internet port 443 to internal port 443), connections from the non-destination hairpinning to the destination (e.g. $A.138 to $B which ends up at $A.1) work just fine. But connections from $A.1 to $B which ends up at $A.1 do not.
And I don't expose my SSH to the internet on port 22, but instead on another random port. So my configuration looks like
SSH ALT <randomport> 22 $A.1
As soon as I fixed the SSH line to look like the above from the incorrect one that had an internal start port of 172, the internal SSH connections appear to come from the internet. And as soon as I delete the SSH forwarding line, it goes back.
So, it is the port forwarding that is messing with the connection paths.
Glad you got it working. Please mark your thread as solved so others will know. Be sure to save off a back up configuration to file for safe keeping. Saves time if a reset is needed.
https://kb.netgear.com/000062080/How-do-I-back-up-the-configuration-settings-on-my-Orbi-WiFi-System
Enjoy. 📡
