Note: This release includes enhanced security measures that disable insecure access to the hub from outside local network using port forwarding or similar means. No IOT device is meant to be accessed publicly, and our hub is no exception. Use Hubitat Remote Admin, a private VPN, or other secure means of access instead.
First off I completely understand the importance of proper security and why Hubitat wants to ensure secure communications to the device by disallowing simple port forwarding. The issue and why I am posting this is because the recent update also breaks legitimate / secure methods of secure remote access not associated with port forwarding or non-SSL connections.
In my case I have a NGINX reverse proxy in place along with a Let's Encrypt certificate. So before the 2.2.9 update I had it setup so you could go to hubitat.mydomain.com where the proxy in conjunction with the cert would provide a completely secure SSL connection over port 443 to my hub functionally the same as connecting over a VPN tunnel. Basically when you hit the FQDN everything goes through the secure SSL browser connection via the NGINX proxy which rewrites each page on the fly via SSL & the certificate. Port forwarding is simply not in play here as the actual IP of the hub is never directly exposed to the internet.
So is breaking such a remote access scenario a "feature or a bug" with the update? Needless to say as soon as I installed the update my ability to connect to my hub stopped working.
Have you actually tested that this no longer works (although I see you said it didn’t work)? There were a number of people on here who have stated they used a reverse proxy without issue. There was even a fix in one of the earlier hot fixes to address people having issues with their reverse proxy.
There must be something unique with your config, as others have reported it still works.
Edit: and here is the thread about it, including the fix for the original issue.
I second the the above. Hubitat staff worked with my hub and at least one other to identify the unexpected issue, and of the 2.2.9 hotfixes solved the issue for me. You can also work around it by removing the X-Forwarded-For header (or setting it to something local) if this is the same problem.
If it's not the same, perhaps they'd be willing to see what it is for you. This wasn't their intent, as far as I can tell.
I wasn't aware of that thread so thanks for pointing it out!
I went through the posts and everything makes sense but unfortunately I am still broken. I am thinking the Hubitat folks would want to work with me to solve this because I am using the out of the box reverse proxy & Let's Encrypt integrated on my Synology DiskStation NAS. This is very popular and widely used solution and not a home brew.
So if I am reading the above thread correctly the idea of X-Forwarded-For header is so that it explicitly tells the local hub that the incoming address is local thereby not kicking in the new protection about an external IP address coming in and accessing the hub.
On my Synology I went into the proxy rule through the GUI and created a custom header called X-Forwarded-For and made the value the IP of my local hub. Was that correct?
In any even what's the best way to engage Hubitat to follow up on this as this isn't a garden variety issue and is already on someone's internal radar.
I should have been clear that the hotfix that addressed this now ignores X-Forwarded-For (which whatever they were using to detect the external address before was apparently unexpectedly looking at), so if you're up to date, there's no reason to bother anymore.
Not sure what your issue might be, but @gopher.ny would probably be able to look at what is happening like he did for me.
I am running 2.2.9.137 - & just sent a PM to Victor with my hubid. Nothing special with my particular hub as I am just using the built-in Synology NGINX based reverse proxy with the accompanying LE cert.
My setup also broke when I updated to 2.2.9. I am using NGINX as a reverse proxy with Let's Encrypt and also requiring a client certificate to connect. I would love to hear what you come up with to get yours working. I am on 2.2.9.138.
I don't see any "rejected" entries in the engineering log on the hub. Can you try a few more times? A rejected request should generate a log entry if the hub gets requests from IPs outside private ranges.
Sorry - that’s because I am having a completely unrelated issue with zwave and I had to restore from a backup. I just tried several times to hit the proxy so you should see logs now
Bobby - That's what I was indirectly doing in my reply without overtly mentioning his name as I knew he must be monitoring this thread. The other issue you are helping me with is completely unrelated. Victor did reach out and asked me to generate some failed / rejected proxy connections so I just did that.
I have been holding off on going to 2.2.9 because of this "remote access" change.
I have a hub that's on it's own separate network behind my main router so it's not exposed to the Internet in any way shape or form. But I still have to use port forwarding to access it from my main home network. This hub is in my RV plugged into a wifi bridge that acts as a router so if this update breaks port forwarding I will have no way to access this hub without having to go and physically run a long Ethernet cable to plug a laptop into the network switch it's on which is located in a hard to reach closet.
These sorts of "We know better than the users who buy our products so we're going to remove their ability to control how they use their own hardware" sort of changes are really infuriating sometimes.
Is there anyway to mitigate this before updating to 2.2.9? Because if I update and it breaks, I will be extremely irritated if I have to go physically run a bunch of cables to regain access to my hub.
To add to the above, if this is all still coming from your own LAN(s), it shouldn't be a problem. It sounds like yours isn't going through the Internet at all, so it really shouldn't be a problem; from what we've been told, it only would be if the "closest hop" came from a public IP address (which is what it looks for, not necessarily "not same LAN," again if what I've interpreted from what I've read is correct).
