Atlassian Application Tunnels plugin will not work via outbound proxy
Platform Notice: Cloud and Data Center - This article applies equally to both cloud and data center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Atlassian Application Tunnels plugin will not connect to Atlassian Cloud instances via outbound proxy server specified neither in JVM parameters nor via system wide environment variables
Environment
Any Atlassian Product that has application tunnels functionality and can only communicate to Atlassian Cloud via a forward (outbound) proxy
Diagnosis
When attempting to connect, in the On Premises application, it will appear as though it's trying to establish a connection, cycling through different statuses and at the end it will even show 'Connected' at the on premises side, however, at the Cloud side the connection status will appear as 'Incomplete' and the applications will stay disconnected
Log entries like below will be evident in the application logs:
1
2
2022-08-19 10:23:26,806 DEBUG [tunnel-executor:thread-1] c.a.t.process.InletsClientManager [INLETS CLIENT] time="2022/08/19 10:23:26" level=error msg="Failed to connect to proxy. Empty dialer response" error="dial tcp 104.192.142.11:443: i/o timeout"
2022-08-19 10:23:26,808 DEBUG [tunnel-executor:thread-1] c.a.t.process.InletsClientManager [INLETS CLIENT] time="2022/08/19 10:23:26" level=error msg="Remotedialer proxy error" error="dial tcp 104.192.142.11:443: i/o timeout"Note, the IP address could be different, but the 'Remotedialer' error is a fairly good indication that the application is affected by the issue
Cause
Application Tunnels plugin is using a third party 'Inlets' process which ignores the proxy settings defined in the JVM configuration properties (e.g. _start-webapp.sh)
Solution
a) On Linux, in case the application runs as a console application, add the following environment variables to the shell profile of the user that's used to run the application:
1
2
export HTTP_PROXY=http://<<proxy_name>>:<<proxy_port>>
export HTTPS_PROXY=http://<<proxy_name>>:<<proxy_port>>ℹ️ Make sure to change the parameters above as per your requirements.
b) On Linux, if application starts and stops as a systemd service, consider changing the respective service configuration to something like the below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[Unit]
Description=Your application name
After=network.target
[Service]
Type=forking
User=yourusername
Environment="HTTP_PROXY=http://<<proxy_name>>:<<proxy_port>>"
Environment="HTTPS_PROXY=http://<<proxy_name>>:<<proxy_port>>"
LimitNOFILE=20000
PIDFile=/path/to/your/app/work/catalina.pid
ExecStart=/path/to/your/app/bin/startService.sh
ExecStop=/path/to/your/app/bin/stopService.sh
[Install]
WantedBy=multi-user.targetℹ️ Make sure to change the parameters above as per your requirements.
c) If the Bitbucket service was installed by the official installer, this by default will use init.d and the service file would be in /etc/init.d/atlbitbucket You can then declare the proxy as follows in the service file:
1
2
export http_proxy=http://<<proxy_name>>:<<proxy_port>>
export https_proxy=http://<<proxy_name>>:<<proxy_port>>The service will need to be reloaded before restarting.
ℹ️ If using systemctl as a wrapper for the init.d service, you need to reload as following: systemctl daemon-reload
d) On Windows, run the below commands as a system administrator:
1
2
setx HTTP_PROXY http://<<proxy_name>>:<<proxy_port>>
setx HTTPS_PROXY http://<<proxy_name>>:<<proxy_port>>ℹ️ In all cases, the application needs to be restarted after the above changes
Was this helpful?