Has anyone successfully set up a reverse proxy using IIS and URL rewrite and can launch a project from the gateway that could help with some configuration issues I’m having.
I’m using IIS and Certify the Web/Letsencrypt for SSL, I have the reverse proxy setup and working fine, I can access Ignition via my domain and with SSL no issues, the issue I seem to be having now Is when a launch a perspective project from the gateway it hangs up swinging between initializing client and authorizing… Inspecting the page showed errors with websockets, I then enabled websockets protocol on IIS and now It works on Internet Explorer and Firefox but no luck on chrome, there are no errors when I inspect the webpage now, so this is now just an issue with chrome. I have noticed when I inspect the webpage and go to the security tab it say’s wss://mydomain.com unknown/canceled I have a feeling chrome is just dropping the connection. I have tried creating a websocket proxy back the ignition gateway localhost:8088 without any luck. I did notice under the Inspect and network tab It’s trying to direct from wss://mydomain.com to https://mydomain.com but still no luck. It seems to be an issue with websockets and chrome, but could be something else and don’t know what to try now.
Yes, I have configured this successfully. This behavior is due to IIS ARR inability of handling websocket compression properly. When launching a session, Chrome sends a websocket upgrade request containing a “Sec-WebSocket-Extensions” header with a value of “permessage-deflate”; the proxy server receives this message and forwards it to the gateway server, which responds back with the websocket protocol swap, including the “permessage-deflate” compression. However, while the proxy server receives subsequent websocket frames from the gateway server, it does not forward them back to the client (browser).
We can add a server variable within the inbound proxy rule so that the “Sec-WebSocket-Extensions” header is cleared, meaning that the requested compression isn’t used for websocket frames.
Do the following on the proxy server:
- Add the server variable within IIS Manager > URL Rewrite > View Server Variable… > Add…
Server Variable Name: HTTP_SEC_WEBSOCKET_EXTENSIONS
- Edit inbound rule (IIS Manager > Your Site > URL Rewrite) and add server variable:
Name: HTTP_SEC_WEBSOCKET_EXTENSIONS
Value: “”
Replace the existing value: True
- Locate path where web.config is stored. (e.g. %SystemDrive%\inetpub\wwwroot)
-
Clear value for HTTP_SEC_WEBSOCKET_EXTENSIONS variable within web.config.
<set name="HTTP_SEC_WEBSOCKET_EXTENSIONS" value="" />
1 Like
making those changes caused my reverse proxy to stop working completely and can’t even access the gateway. Should I try my configuration with your web.config and change to my IP address and see if that works?
Can you please put up your complete configuration in case I have missed something else previously or just have everything configured wrong from the start.
To be honest, I would probably need to review your specific rules. Can you email support@inductiveautomation.com and I’ll follow up with you personally?
Hi Kurt, I have just sent an email. Thanks
Ignition wants me to create new account with my full email address, I have 2x domains, one short and one long which does automatic redirects. Would I be best to create a ticket in my current account?
I’ve received your email. I’ll followup shortly. Thanks.
The earlier steps weren’t as clear. Needed to explicitly add the server variable within URL Rewrite in addition to defining the variable / value within the inbound rule. Updated the original post.
I believe are having this same problem. Is there something in wireshark I can show our network admin that is happening that should not be happening? I want to give him something concrete to work against. Also are works with Edge, but not chrome and not firefox.
Just an update to this thread. As of the recent 8.0.11 nightly, we have added a JVM parameter –perspective.ws.disablePermessageDeflateExtension=true – that will specifically disable the permessage-deflate extension for any perspective web socket sessions, thus allowing for Microsoft IIS based firewalls to rewrite secure websocket messages when acting as a reverse proxy.
The custom server variable is no longer necessary due to this additional parameter, which would be added within the ignition.conf file as shown below:
2 Likes
I’m having the exact same problem.
When I try to add this:
wrapper.java.additional.4=–Dperspective.ws.disablePermessageDeflateExtension=true
I get the following error:
WARN | wrapperm | Configuration file, C:\Program Files\Inductive Automation\Ignition\data\ignition.conf, contains a problem on line #74 and could not be read. (Invalid multibyte sequence.)
FATAL | wrapperm | Failed to load configuration: C:\Program Files\Inductive Automation\Ignition\data\ignition.conf
FATAL | wrapperm | The Wrapper will stop.
There is a small discrepency between the text and the screenshot, my assumption is the parameter starts with -Dperspective and not -perspective.
Any help would be appreciated.
That error suggests that whatever editor you used changed the file encoding. This file should be plain ascii.
I think the dash in your -Dperspective... might be an en or em dash and not an ascii hyphen.
1 Like
Thanks Phil.
I edited in notepad which was set to ANSI encoding. I changed it to UTF 8 and the file error disappeared.
I’m still having issues with the reverse proxy alternating between initializing and authorizing, I’m going to learn about web sockets next.
The dash was certainly problem #2, along with enabling web sockets.
I just did a copy/paste from the line above and it fixed the issue.
…now just need to figure out how to get the reverse proxy to go directly to Perspective. I can get there through the gateway webpage and reverse proxy, just can’t seem to add to the path.
Ugh…I’m really out of my element here
This rule works perfectly:
After addressing the issues above https://demo.mydomain.com goes directly to the gateway home page and I can get anywhere from there, including launching my Perspective app.
What I want is a rule where https://demo.mydomain.com takes me straight to my Perspective project. This is what I have, it gets stuck on Authenticating:
If I remove the authentication from the project (make it public) I just get a blank page.
Any help would be appreciated.
Perspective needs resources that are outside the project. If you monitor your proxy’s access logs while running the working config, you’ll see those. I would use that config plus a rule to redirect your bare site URL (checking for no path, no query string) to your project.
Did you ever get this to work? I too am struggling to only reverse proxy (via IIS) just a perspective project and not the entire webui
I never did get it working as intended, and I’ve also migrated away from Microsoft and try to do things on Ubuntu as much as possible. Linux seems to just work better in the long run.
If I had to do it again I would probably just set the gateway to use the default https port 443 and make sure my security is very tight.
Make sure you install IIS WebSocket Protocol.
.
I had forgotten to do this and the Perspective pages were hanging at the Authentication stage, due to failed web socket connection. All working just fine now using IIS Reverse Proxy.
