Background
The organization had multiple offices accessing an instance of Spira cloud hosted by Inflectra running HTTPS. One of the offices could connect fine, but the other had an issue connecting. They kept getting this error:
ERR_CONNECTION_CLOSED
The other part that was strange, was that the SSL certificate the users were seeing did not match the one that Inflectra uses for its IIS web server. It turned out that it was a SSL certificate that was being issued by the Firewall / VPN itself.
That led us to realize that we had a different kind of VPN / Firewall.
Most firewalls simply take incoming encrypted HTTPS requests and as long as it's on port 443 and meeting the appropriate IP whitelisting/blacklisting rules will be allowed into the network (for access by the end user):
However, some firewalls do more than this. They actually decrypt the HTTPS requests like a web browser, inspect the packets, then re-encrypt using their own SSL certificate and send it to the user:
As a result, the end user's computer is getting an HTTPS / TLS certificate from the Firewall not the actual application (in this case Spira). Once this architecture was understood, it was possible to diagnose more clearly where the connection drop was happening...
Solution
In this case, the solution was relatively simple. They had to enabled HTTP/2 traffic to be decrypted in their VPN firewall. Once that was done the system worked correctly again.