OH3 with Microsoft IIS Reverse Proxy and Authentication

Has anybody gotten a reverse proxy to work with OH being on RPI internally and IIS exposed to the internet?

The IIS reverse proxy is working but I don’t have any authentication pages coming up to actually do anything with OH.

Looks like this is covered well with NGINX below and it seems I need to add two strings to IIS but where?

add_header Set-Cookie X-OPENHAB-AUTH-HEADER=1;
proxy_set_header Authorization “”;

Best, Jay

Hi Jay,
those are set in the server variables
I posted on this with pics here.

What I showed should work regardless of whether you are running on a RPI or docker or nux or windows the internal side can run either secure or not that should be irrelevant assuming your internal IIS NIC is able to resolve your internal FQDN of the Openhab RPI or you configured it with IP as for the IIS exposed to the internet If you are fully sealed it will work the configuration setup I outlined does not care if it is internal or external facing and the IIS setup is pretty much MSFT recommended configuration.

I actually have been following this thread :wink:

Here’s what I have discovered; the rewrite ADD variables feature/logic will not work with Windows 2012 R2 IIS without unlocking the server config. Here’s how to do it:

Most IIS sections are locked by default but you can “unlock” them by setting the attribute overrideModeDefault from “Deny” to “Allow” for the relevant section group by modifying the ApplicationHost.config file located in %windir%\system32\inetsrv\config in Administrator mode

Search for allowedServerVariables and change it to Allow.

Another big thing that needs to be documented is - when using a windows user/pass to authenticate for IIS, this user/pass must match OH’s GUI user/pass. If they are different, it will just keep prompting you in circles between IIS and OH.

Best, Jay

Hey @justaoldman,

Everything is working now except /habpanel’s

The issue is when you first launch /habpanel it will always ask you what panel you want, local or server. This step is not showing up. It shows the initial black page but the options to switch the panel never comes across so you can never see the panels.

My guess it has to do with the rewrite outbound and matching MIME parameters. I’m guessing it’s missing something (JavaScript, etc.).

                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^application/json" />	


Best, Jay

Hi Jay,
Did you take a look at that last MSFT article I included? I linked it initially due to some behavior changes that 3.4 brought to the table. But if you read through the write up and go to the 3rd(part 3) MSFT link that the writer mentions I seem to recall it talks about pretty much what you are describing for JavaScript quirkiness and how to address it as well. I did not try all of his extra part 3 stuff but it you may give it a whirl and see if it helps.

I did read it, but that was around 500 errors. Not getting any errors and I’m running OH 3.2 vs. 3.4.

I’ll keep trying to debug.

Best, Jay

This one?

It is all about outbound and javascript rewrites not 500 errors The entire 3 part series was all around how to make URL rewrite work not just the 500 errors. :slight_smile:

Thank you, I did not see this one. I just tried what it said and it’s still not working. I have added all possible MIME entries below to the outbound rewrite. Guess, I’ll continue to debug.

                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/(.+)" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^application/json" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^image/png" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^image/jpg" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^image/jpeg" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/javascript" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^image/gif" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^video/mp4" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^video/mpeg" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^image/svg+xml" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^image/tiff" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^application/xml" />
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/application-javascript" />	

Best, Jay

Hi Jay for what its worth I just tossed a simple openhab panel together on my test servers and I do not see the issue you mention…

as you can see from the url it is running on fqdn and secure and using IIS reverse proxy. Only difference I have here is it is server 2019 not 2012R2 (really doubt that matters) and I am running on a basic openhab build 3.4 that is running on windows10 separate machine different subnet and also vlan (again not that any of that matters either), I also tested 3.2 before on nux and as a docker and before that 3.1 and it also worked fine as I recall IIS does not care what the other environment is actually as long as it can get responses back.

Thank you for testing this, my situation is a bit different.

  • No SSL involved anywhere.
  • Using a modified habpanel JAR called org.openhab.binding.habpanelfilter-3.1.0-SNAPSHOT.jar which filters only items I want sent to the panel to increase the loading speed.

If I could just get past choosing the panel (local vs. server) it should work perfectly. It has something to do with the sliding door code that isn’t allowing it through the reverse proxy.

The actual web page source code is completely there, the drawer just isn’t working for some reason.

I actually was trying to see if I could just find the cookie that it needs for that setting but that didn’t pan out (didn’t find it).

Best, Jay

For those that are running Windows 2012, there is a default cache issue with ARR, OH 3.x reverse proxy and large list of OH items.

Thank you @justaoldman for helping me debug this situation!

Everything worked using @justaoldman screen shot documentation, but I wasn’t seeing items in the admin portal nor was habpanel working. The issue was the Response Buffer Threshold cache setting for ARR, it wasn’t big enough so the REST call for the items was being stopped. Once you fix the items showing up in Admin, habpanel works immediately.



Best, Jay