I just installed 2.2.9.128, and one of the "features" is to disable reverse proxy to the hub - i get the rationale - to stop unsecured devices popping up on the internet, but mine was already protected behind a pretty strong Traefik reverse proxy with SSL and 2FA.
How do i disable this so i can continue to use reverse proxy in a responsible way?
In the mean time i have downgraded my hub back to 2.2.8.156
Please can an option be included to disable this feature?
No, this is not the motivation at all. The problem is that there are lots of users who don't understand how to secure their hubs from outside attacks, and unknowingly expose them to such attacks. So our motivation is security related.
I too am using a secured SSL/MFA reverse proxy that is now broken.
As a result of disabling reverse proxies, my remote monitoring (UptimeRobot) is also now broken. I had it configured to authenticate to the proxy and locked down by an ACL. I like to be alerted if the hub is down/locked up. That ability just went away.
It appears that you can add additional IP address ranges via a web endpoint for more complex network scenarios, like yours. See the following post.
Thanks this wouldn't work as it only lets you whitelist /24
If anyone is able to get this working some guidance would be hugely appreciated.
we need a /hub/allowSubnets?all
or something to specify cidr/prefix notation, like 1.0.0.0/9
or /hub/TrustMeIKnowWhatImDoing
only if it requires the parameter famousLastWords 
, i.e.
/hub/TrustMeIKnowWhatImDoing?famousLastWords=true
Yes! this is would be perfect. i'll be staying on the previous version for a while i guess.
wow this kinda sucks... downgrading I go
Oh oh, I don't use a reverse proxy but I do use OpenVPN to connect to clients. Most tunnel connectors are using 172.x.x.x IP addresses so it looks like this may be an issue if it true that only /24's are allowed.
These should be defined as private IP ranges by default if I'm reading this correctly:
10.0. 0.0/8
172.16. 0.0/12
192.168. 0.0/16
I'm adding some back end logging to save IPs of refused requests. That should help with troubleshooting and eventual workaround or fix.
Thanks. Wont logging just tell you which IP addresses any admin's cell provider etc. was used when trying to access the hub? in other words enabling IP Whitelist all type functionality will still be required by some users.
an advanced user is fine enabling this via endpoints. a novice user wouldnt go that far, further many notice users will never update their hubitats so they are still exposed regardless.
thanks, looking forward to a fix or workaround as there are some lovely new features in 2.2.9.128 i am keen to use when i can get around this issue.
2.2.9.129 (just released) logs refused connections' IPs but there's no resolution yet. I'll need more time to experiment with NGINX reverse proxy this long weekend.
Whatever proxy you use, can you try commenting out X-Forwarded-For header? As in do not have proxy create one. That made a difference between receiving real IP vs. proxy's IP on my (admittedly very basic) nginx setup.
Interesting, my reverse proxy works just fine. But then again I'm only using it internally to get subdomain / ssl access. I specifically block external access.
This is what I was thinking. There either has to be a configuration issue on the reverse proxies that are being used... or the 2.2.9 update must be treating forwarded IPs as the source instead of the raw IP from the reverse proxy.
I am going to try later setting the passHostHeader to false on my traefik v2 reverse proxy, but it would be useful to know how 2.2.9 detects and blocks the proxy.
If the X-Forwarded-* headers are used as the detection method then they can’t be disabled in traefik.
Whilst it might be a bug, The feature appears to be acting as intended in disabling proxy. I am taking a little frustration that I can’t disable or override this feature.
Creating workarounds on reverse proxies probably isn’t the most optimal approach.
Figured where Jetty was processing the header (sneaky) and how to disable that processing. Next update will have the fix.
Fix is out in 2.2.9.130, please let me know if it solves the issue.
Download the Hubitat app
