Noticed an issue a few weeks ago attempting to SSH to a device that is located over a VPN tunnel. This had been working previously and it wasn't a big deal because the site had already been configured to allow client VPN and it's a low touch environment so I wasn't all that concerned. Being a network guy though this was like a splinter irritating my brain that i had to work out.
So, I started doing some testing.
The VPN peer tunnel interface IPs are on 10.255.255.0/30 my local is .1 and the far end is .2
Local access is 10.1.0.0/24 - my client is DHCP, the gateway is .1 and my VPN appliance is .2
I can ssh to the vpn appliance at 10.1.0.2 just fine and from there I can use ssh to ssh to the far end vpn appliance at 10.255.255.2
Going further i can ssh to 10.20.0.1, and address on the remote side of the tunnel from the local vpn device.
When I attempt to ssh to 10.20.0.1 from my local endpoint, the traffic goes to my default gateway (10.1.0.1, where a static route is entered and directs the traffic to 10.1.0.2 - I get an initial SSH prompt for my login name, and then the traffic times out. This happens every time.
Ok, so i can get there from the VPN device but not my enpoint, both are on the same network.... what changed? I looked at the uptime om my RBR-850 it was 2 days, and a new firmware had just recently been released, which it had automagically upgraded to....
Ok, so lets take the RBR out of the mix with a static route from my endpoint.... so I added a route table entry in my local endpoint that sends 10.20.0.0/24 to 10.1.0.2 and fired up an SSH attempt to 10.20.0.1 - it completed flawlessly.
Great, so the router changed behavior with the new version. Examining the release notes however there was nothing that would indicate a change in behavior for async traffic flows (the flow would be async because the return traffic would egress out the local VPN device without having to hit the router as it would arp for the client being on the same network and all) or static routes. Ok well, I'll just downgrade to the previous version - but no, it looks like that is prevented. So I'm stuck here with a very expensive product that no longer functions the way i need it to....
Please fix this firmware to restore this lost functionality.
There's about 30 static routes and 20 different port mappings.
I guess I can factory reset it, and restore it from backed up settings, 'cause i'm not re-entering all that again.
I appreciate the input and when i want to drop connectivity for my 40+ devices I'll give it a go, but honestly I'm not sure how in 2021 that can be an acceptable troubleshooting step. If it was 2004 and a wrt54g.... ok maybe.
Semi-related, is there a way to prevent the RBR-850 from auto-upgrading?
While I don't want to turn this into a phiosophical debate about the customer experience, and I do get that they are different pieces of hardware. The router is purpose built and specifically designed to do basically one thing with no additional software installs allowed by customers, endpoints being far more complex only serves to further my point. When a purpose built device takes a software upgrade there are far less complexities engineers need to account for in the process. If something as simple as reading the configuration from nvram and refactoring for any additional features that may have been added/removed/etc can't be done on a closed / fixed system after over 20+ years of experience maybe it's time to examine the way it is being done and overhaul it, 'cause it ain't workin' baby.
</soapbox>
To the task at hand,
I backed up my settings, reset to factory defaults, restored the settings and the same issue still exists.
Something to make contact with NG support and let me know what your seeing on v4.
Ya i know. Something else I noticed the other day with mine. Factory reset and ran into all kinds of problems getting the RBS to conenect right and RBR would NOT go into AP modem. Low and behold I left the units unplugged and came back yesterday evening after work and the RBS connected correct and I was able to get into AP mode. Something caused the RBR and RBS to being some bad state, even after a reset, the power OFF for 24 hours then back ON, for unknown reasons fixed it. Orbi has been crazy for sure so even in this case, FR seemed to cause more problems then expected...at least on v4. Still, it's a valid troubleshooting item that we employ, I have seen it solve many many issues before time and time again. Now I need to employ a full power OFF as well. Lordy Lordy. Your not the only one with a LONG history in the computer field Sir. The first computer I touched was a dot matrix continuous paper fed computer with only a keyboard and conencted to sysop via analog dial up handheld phone modem.
Get in contact with NG support what your seeing. I may take time for them to fix what ever that was broke so if you need your system to work before v4 was applied, you need to downgrade back to v3.
Unfortunately Netgear support won't talk to me as my unit is over 90 days old and I refuse to pay for additional support on one of their most expensive systems (white glove should be included with the price tag) to troubleshoot a firmware upgrade I have no control over.
The release notes say I can't downgrade from this version of the firmware, at least on the RBR - I hear the RBS can, but I'm not really having issues with them. I haven't tried to downgrade though because I can't really afford to brick a $1K mesh system and then wait for any kind of replacement.
<Sigh> I knew I should have gotten the Ubiquiti Dream Machine.
