Atlassian Application Tunnels plugin doesn't work via outbound proxy
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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 cannot connect to Atlassian Cloud instances via the outbound proxy server specified 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 proxy.
Diagnosis
When attempting to connect, the on premise application will appear as though it's trying to establish a connection. It will then cycle through different statuses and at the end will show 'Connected'.
However on the Cloud side, the connection status will appear as 'Incomplete' and the On-Premise application and Cloud application will stay disconnected.
Log entries like below will show up in the application logs:
1
2
2022-07-14 12:11:49,166+0930 tunnel-executor:thread-1 DEBUG [c.a.tunnel.process.InletsClientManager] [INLETS CLIENT] time="2022/07/14 12:11:49" level=error msg="Failed to connect to proxy. Empty dialer response" error="dial tcp 104.192.143.9:443: i/o timeout"
2022-07-14 12:11:49,166+0930 tunnel-executor:thread-1 DEBUG [c.a.tunnel.process.InletsClientManager] [INLETS CLIENT] time="2022/07/14 12:11:49" level=error msg="Remotedialer proxy error" error="dial tcp 104.192.143.9:443: i/o timeout"ℹ️ Note, the IP address could be different, but the 'Remotedialer' error is an 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 files (e.g. setenv.sh).
We recommend that you confirm that the HTTP_PROXY and HTTPS_PROXY settings are accurately configured in both the running Jira process and the inlets process:
1
2
3
4
5
# ps naxfwww|grep inlets
16875 ? Sl 0:03 \_ ./inlets client --url=wss://tunnel.services.atlassian.com --upstream=xxxx-4d17-5c48-8db1-xxxxxx541d5e.self-hosted.atlassian.com=http://127.0.0.1:8089 --token-from=/jiratest/jirahome/secure-tunnel/token --strict-forwarding
# cat /proc/16875/environ | tr '\0' '\n' | grep PROXY
HTTPS_PROXY=http://jira-proxy-test.com:80/
HTTP_PROXY=http://jira-proxy-test.com:80/Solution
a) On Linux, if the application runs as a console application, add the following environment variables to the shell profile of the user running the application:
1
2
export HTTP_PROXY=http://your.proxy.name:proxyport
export HTTPS_PROXY=http://your.proxy.name:proxyportb) On Linux, if application starts and stops as a systemd service, consider changing the respective service configuration to something like below. You'll need to update the paths to match your environment.
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://your.proxy.name:yourproxyport"
Environment="HTTPS_PROXY=http://your.proxy.name:yourproxyport"
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.targetUpdate the other parameters as needed in your environment.
c) On Windows, run the below commands as a system administrator:
1
2
setx HTTP_PROXY http://your.proxy.name:yourproxyport
setx HTTPS_PROXY http://your.proxy.name:yourproxyportIf your On-Premise application runs as a service and impersonates a user that is different from your system administrator account, you may want to set the parameters for that service user or set the variable in the system environment so that those variables are visible to all users (including On-Premise application service user)
1
2
setx /m HTTP_PROXY http://your.proxy.name:yourproxyport
setx /m HTTPS_PROXY http://your.proxy.name:yourproxyportFor more information, please refer to Microsoft Windows documentation.
If the issue persists after applying the parameters above, please execute the following commands:
1
2
setx /m http_proxy http://your.proxy.name:yourproxyport
setx /m https_proxy http://your.proxy.name:yourproxyportd) If you have docker deployment with Ansible you may need to add these parameters as an environment variable like the below example:
1
2
3
4
5
6
- name: Pull Confluence Container
.....
env:
http_proxy: "http://your.proxy.name:yourproxyport"
https_proxy: "http://your.proxy.name:yourproxyport"
noProxy: "*.test.example.com,.example2.com,localhost,127.0.0.0/8"e) For Kubernetes deployed instances additionalEnvironmentVariables can be used to add the required variables via values.yaml. For example:
1
2
3
4
5
6
7
8
jira:
. . .
additionalEnvironmentVariables:
- name: HTTP_PROXY
value: "http://your.proxy.name:yourproxyport"
- name: HTTPS_PROXY
value: "http://your.proxy.name:yourproxyport"
. . .ℹ️ In all scenarios, the application needs to be restarted after the above changes
Was this helpful?