Static IPs for firewalls
This guide should help to understand the requirements by the app to connect a self-hosted Data Center instance with the Microsoft 365 cloud.
We provide a list of static IP addresses that can be used to allow access to an internal Jira or Confluence instance - or be used with the Atlassian Cloud IP allow-listing feature.
We also recommend to look into mTls
Jira / Confluence Data Center
By default, all connections to your Jira Server or Data Center system will come from these IPs.
You might not need to whitelist all of them, in case you are certain of the region that will be used.
Only port 443 is used, if not specified otherwise in your Jira base url.
List of Domains
We have multiple domains for different purposes:
*.atlassianconnect.yasoon.com
*.app.yasoon.com
office.yasoon.com
*.yasoon.io (in case of user generated content)
List of static IPs
At the moment, our only static IP / egress proxy is located in Frankfurt. We are working on setting up regional data residency & compute resources. You will be able to choose which region to use then.
IP | AWS Region | Status |
|---|---|---|
52.57.22.128 | Europe (Frankfurt) (eu-central-1) | ACTIVE |
3.221.157.128 | US East (N. Virginia) (us-east-1) | SOON |
US West (Oregon) (us-west-2) | SOON | |
Asia Pacific (Sydney) (ap-southeast-2) | SOON | |
Asia Pacific (Tokyo) (ap-northeast-1) | SOON | |
Canada (Central) (ca-central-1) | SOON | |
Europe (Ireland) (eu-west-1) | SOON | |
Europe (London) (eu-west-2) | SOON | |
South America (São Paulo) (sa-east-1) | SOON |
mTLS
We understand it is a sensitive decision to grant access to your Jira instance for our services.
That’s why our infrastructure supports mTLS for additional security.
mTLS prevents various kinds of attacks, including:
On-path attacks: On-path attackers place themselves between a client and a server and intercept or modify communications between the two. When mTLS is used, on-path attackers cannot authenticate to either the client or the server, making this attack almost impossible to carry out.
Spoofing attacks: Attackers can attempt to "spoof" (imitate) a web server to a user, or vice versa. Spoofing attacks are far more difficult when both sides have to authenticate with TLS certificates.
Credential stuffing: Attackers use leaked sets of credentials from a data breach to try to log in as a legitimate user. Without a legitimately issued TLS certificate, credential stuffing attacks cannot be successful against organizations that use mTLS.
Brute force attacks: Typically carried out with bots, a brute force attack is when an attacker uses rapid trial and error to guess a user's password. mTLS ensures that a password is not enough to gain access to an organization's network.
Phishing attacks: The goal of a phishing attack is often to steal user credentials, then use those credentials to compromise a network or an application. Even if a user falls for such an attack, the attacker still needs a TLS certificate and a corresponding private key in order to use those credentials.
Malicious API requests: When used for API security, mTLS ensures that API requests come from legitimate, authenticated users only. This stops attackers from sending malicious API requests that aim to exploit a vulnerability or subvert the way the API is supposed to function.