Synchrony and HTTPS Web Publishing using TMG 2010 Reverse Proxy Server

[steve harris]

Hi Everyone,

We have been trying to get Synchrony working with our TMG 2010 Reverse Proxy Server to no avail.

A Web Publishing Rule is in place as follows on our public facing TMG 2010 Reverse Proxy Server:

From: Anywhere
To: Confluence Test Host on Internal Network
Traffic: HTTP and HTTPS
Web Listener: Confluence 6, port 80 and 443, using wildcard certificate, no authentication
Public Name: confluencetest.x.y.z
Web Server redirect requests to HTTP port 8090
Apply link translation to this rule (ticked)

On the Confluence Test Server and Synchrony ports (8090 and 8091) are in a listening state:
TCP 0.0.0.0:8090 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8091 0.0.0.0:0 LISTENING

However, collaborative editing / editing of documents fails with "loading the editor's taking longer than usual".

The following KB mentions - Reverse proxy issues
https://confluence.atlassian.com/doc/troubleshooting-collaborative-editing-858772087.html

"If you have configured your reverse proxy, but can't edit pages, here's some things to check in your configuration:
Go to installation-directory>/conf/server.xml and check the Connector directive. Make sure that you have correct values for <protocol> and <proxyName>. See the examples in the guides below for more information."

I'm not sure what the above means given Synchrony is configured within Confluence not server.xml
Our server.xml is configured as:
HTTPS - Proxying Confluence via Apache or Nginx over HTTPS

<Connector port="8090" connectionTimeout="20000" redirectPort="8443"
maxThreads="48" minSpareThreads="10"
enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
protocol="org.apache.coyote.http11.Http11NioProtocol"
scheme="https" secure="true" proxyName="confluencetest.x.y.z" proxyPort="443"/>

<Engine name="Standalone" defaultHost="localhost" debug="0">
<Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="false" startStopThreads="4">
<Context path="" docBase="../confluence" debug="0" reloadable="false" useHttpOnly="true">
<!-- Logging configuration for Confluence is specified in confluence/WEB-INF/classes/log4j.properties -->
<Manager pathname=""/>
<Valve className="org.apache.catalina.valves.StuckThreadDetectionValve" threshold="60"/>
</Context>

The following KB mentions XHR fallback when connection to a websock is not possible, but this does not occur.
https://confluence.atlassian.com/conf610/administering-collaborative-editing-952623315.html

XHR fallback
When a user cannot connect to Confluence via a WebSocket, we'll fall back to a XML HTTP Request (XHR), allowing them to edit pages successfully. For the best editing experience, we strongly recommend that your environment allows WebSocket connections however.
XHR fallback is enabled by default, but can be disabled using a system property if necessary. You shouldn't need to change this.

Source documents:
https://confluence.atlassian.com/doc/troubleshooting-collaborative-editing-858772087.html
https://confluence.atlassian.com/doc/possible-confluence-and-synchrony-configurations-958779064.html

We have spoken to Microsoft re: websockets on TMG and they advise our existing TMG 2010 solution will require a second NIC for websockets to work and for us to create a non-web server protocol publishing rule. Our ISP advised this is not a viable option as there are security implications.

Any information on why XHR fallback isn't working or other options would be greatly appreciated.

Thank you for reading.