2.2.9 Security Enhancements?

That toggle (UI or not) isn't going to happen, but we're listening to feedback and will do our best to accommodate the needs of the more advanced users. What's the use scenario you have in mind?

Understood. Mostly as a troubleshooting step... working with someone in another post whose envisalink integration broke with the upgrade and it would be a simple step to eliminate a connectivity issue resulting from those changes. However, there are other troubleshooting steps we can take and the problem may be completely unrelated. (BTW I'm unable to recreate his issue in my lower environment so who knows.)

Ha! story of my life there!

2 Likes

Yeah and whatever lower environments you have can't possibly include all of the sensors and devices people use... in my case I have a nonprod hub but definitely not a nonprod alarm system so it's never 100%

@gopher.ny
Where do I run the above command to add a couple of my other IP ranges?
The reason I ask is I have multiple Vlans and I currently cannot communicate across them to the hub even though the first number of the IP range is the same on all of them.

It would be part of the URL you would use.

But, you shouldn’t have to use this setting for that, by default all private IPs are allowed. I also have a number of VLANs and I’m still able to access without issue.

1 Like

2.2.9.129 allows CIDR subnet notations, e.g. 1.2.3.4/24. It does not allow subnets broader than /24, though.

Once you bring up hub's UI, e.g. http://192.168.1.5/, add the endpoint to that URL, e.g. http://192.168.1.5/hub/allowSubnets?123.123.123.0,124.124.124.0

2 Likes

I would make the suggestion that this is something that should be under the advanced networking section in the UI.

The ability to do this shouldn't exactly require soneobe finding these threads down the road.

6 Likes

…but then they’d miss out on the joy of searching the forum for these precious nuggets…:rofl:

Actually not a bad idea.

7 Likes

I think the devs at Hubitat would sooner commit Sepaku than go the way of Wink in any way, shape, or form...

1 Like

That is going to happen. Can't promise the timeline, but sooner rather than later.

5 Likes

So, closer to 2.2.9.130 than 3.0.0.1.

1 Like

Thank you. That worked perfectly.

2 Likes

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.

Yes, I said it's not looking at the headers just a few posts above... obviously, something implicitly does.

1 Like

So I just upgraded to .129 and found that my WebVPN Portal no longer works - I cant say I'm very impressed by this! :weary:

Now All I get is this when I try to connect:
Screen Shot 2021-10-10 at 1.45.54 pm

It's my own fault I guess for assuming the solution I use would be unaffected:

But if you guys could please add an option to allow competent IT folk to manage their own security, that'd be great, m'kay.

PS, adding my public IP doesnt solve the issue for me, however using a standard VPN tunnel into my network does still work.

1 Like

Figured where Jetty was processing the header (sneaky) and how to disable that processing. Next update will have the fix.

5 Likes

Fix is out in 2.2.9.130, please let me know if it solves the issue.

6 Likes

Cheers, I’ll try it today.

Yep, my VPN Web portal is back online, lovely work sir! :heart_eyes:

1 Like