Open issuesSwitch filter

bmcalary added a comment - 02/Apr/2025 2:14 AM Hello All,  Ben from Atlassian Networking. We have built a public tool which allows searching for an IP or filtering the ip list based on use case https://ip-ranges.atlassian.com/tool.html     Also, we would like to share these additional code examples for working with https://ip-ranges.atlassian.com/ : JQ example for getting Atlassian Outbound IPv4 ranges: curl https: //ip-ranges.atlassian.com/ | jq '.items[] | select((.product[] | contains( "jira" )) and (.perimeter == "commercial" ) and (.direction | length == 1 and .[0] == "egress" ) and (.cidr | endswith( "/28" ))) | .cidr' | sort "104.192.136.240/28" "104.192.137.240/28" "104.192.138.240/28" "104.192.140.240/28" "104.192.142.240/28" "104.192.143.240/28" "13.200.41.224/28" "13.236.8.224/28" "13.52.5.96/28" "16.63.53.224/28" "18.136.214.96/28" "18.184.99.224/28" "18.234.32.224/28" "18.246.31.224/28" "185.166.140.112/28" "185.166.141.112/28" "185.166.142.240/28" "185.166.143.240/28" "43.202.69.96/28" "52.215.192.224/28" Python example for getting Atlassian inbound ranges, with summarization: import ipaddress import json import urllib.request response = urllib.request.urlopen( "https: //ip-ranges.atlassian.com/" ) ip_ranges = json.loads(response.read().decode( "utf-8" ))[ "items" ] cidrs_v4: list = [] cidrs_v6: list = [] for ip_range in ip_ranges: if all( [ "jira" in ip_range[ "product" ], "ingress" in ip_range[ "direction" ], ip_range[ "perimeter" ] == "commercial" , ] ): if ipaddress.ip_network(ip_range[ "cidr" ]).version == 4: cidrs_v4.append(ipaddress.ip_network(ip_range[ "cidr" ])) else : cidrs_v6.append(ipaddress.ip_network(ip_range[ "cidr" ])) print([str(cidr) for cidr in ipaddress.collapse_addresses(cidrs_v4)]) print([str(cidr) for cidr in ipaddress.collapse_addresses(cidrs_v6)]) [ '13.35.248.0/24' , '13.200.41.128/25' , '13.227.180.0/24' , '13.227.213.0/24' , '16.63.53.128/25' , '43.202.69.0/25' , '104.192.136.0/21' , '185.166.140.0/22' ] [ '2401:1d80:3000::/36' ]

Ali Türkkan added a comment - 13/Apr/2023 2:27 PM Hi @bmcalary, We are having problems with adding a large number of IP addresses to Network Firewall rules. However, we wanted to try it in a different way. We opened our application completely to the outside and we wanted to see Jira, with which ip address it came to our on-premis application. As a result of our 4 different rest operations, we determined that Jira came to our local application from the following ip addresses. 18.193.7.22 3.69.45.100 x2 3.72.246.5 However, these ip addresses are not defined in the ip ranges document( https://ip-ranges.atlassian.com/ ). In addition, it is not defined in AWS's ip ranges( https://ip-ranges.amazonaws.com/ip-ranges.json ). That's why even allowing a large number of thread spacings in the relevant document does not solve it. In this case, we couldn't find a way to access our on-premis application over the Jira cloud. We think Atlassian should come up with a solution in this case.

bmcalary added a comment - 23/Aug/2022 8:04 AM - edited Hello everyone, Ben from Atlassian Network Engineering. In January 2022 we made improvements to our documentation at https://confluence.atlassian.com/cloud/atlassian-cloud-ip-ranges-and-domains-744721662.html and specifically to our list of IP addresses in https://ip-ranges.atlassian.com/ so that product , region and directional information are now included. Even though regional information is provided, we do not recommend that customers allow-list ingress or egress networks associated with specific regions, but instead include all networks relevant to a product and direction. This is because we optimise our network over time, continuously bringing our cloud closer to all customers by deploying additional edge regions. Due to the underlying technology of the internet, in particular unicast routing and latency-based DNS routing, these improvements can and do result in customer based clients and servers seeing new Atlassian IP addresses (from our published ranges) used for connections over time. This issue is not unique to Atlassian, AWS also adds expands and adds additional IP ranges to their products over time, including to the popular services EC2 and Cloudfront in https://ip-ranges.amazonaws.com/ip-ranges.json . All that being said, if you wish to proceed, once queried for the desired combination of product, region and direction, the resulting number of CIDR blocks should be short. However, please be mindful of the earlier warning regarding the dangers of filtering by region. An example script which can yield the networks one cares about might be: import requests import json import netaddr # Direction of requests from perspective of Atlassian i.e: # ingress = client ---> internet --> Atlassian Cloud (e.g. browser loading Jira) # egress = Atlassian Cloud ---> Internet ---> On-premises Server (e.g. Jira Cloud sending webhook or loading remote Email, Jira/Confluence/Bitbucket DC, Jenkins etc) direction = "ingress" product = "confluence" region = "eu-west-1" networks = requests.get( 'https://ip-ranges.atlassian.com/' ).json()[ 'items' ] # Find the networks we want allow_list = [] for network in networks: if all ([ direction in network.get( "direction" , []), product in network.get( "product" , []), region in network.get( "region" , []) or " global " in network.get( "region" , []) ]): allow_list.append(network[ "cidr" ]) # Use netaddr to merge any networks which are contiguous allow_list = sorted ([ str (x) for x in netaddr.cidr_merge(allow_list)]) for cidr in allow_list: print ( str (cidr)) Which would yield: 104.192.136.0/21 185.166.140.0/22 3.251.213.64/26 52.215.192.128/25 A iteration on this script which takes into account our warning and excludes regional filtering is: import requests import json import netaddr # Direction of requests from perspective of Atlassian i.e: # ingress = client ---> internet --> Atlassian Cloud # egress = Atlassian Cloud ---> Internet ---> On-premises Server (Email, Jira/Confluence/Bitbucket DC), Jenkins etc) direction = "ingress" product = "confluence" networks = requests.get( 'https://ip-ranges.atlassian.com/' ).json()[ 'items' ] # Find the networks we want allow_list = [] for network in networks: if all ([ direction in network.get( "direction" , []), product in network.get( "product" , []) ]): allow_list.append(network[ "cidr" ]) # Use netaddr to merge any networks which are contiguous allow_list = sorted ([ str (x) for x in netaddr.cidr_merge(allow_list)]) for cidr in allow_list: print ( str (cidr))   We do recommend using automation or polling this list (or subscribing to the upcoming AWS SNS endpoint which we will be documenting in https://confluence.atlassian.com/cloud/atlassian-cloud-ip-ranges-and-domains-744721662.html ).

Stephen Herd added a comment - 07/Dec/2020 10:45 PM All they would need to do for this would be to introduce a NAT for all their outbound traffic.  That way all traffic would originate from a single address vs any one of thousands.

Cory Galloway added a comment - 02/Dec/2019 4:27 PM There are way too many IPs to add.  There has to be a better way.

Daminda Gunawardana added a comment - 04/Oct/2018 7:29 AM The workaround of a server solution is not at all acceptable given the many advantages of using a cloud service, especially in the case of a geographically widespread organisation. The large number of IPs and IP ranges required to be whitelisted on a firewall to facilitate the cloud service is a complication that a user organisation should be spared of. A quick solution to this would be very much appreciated.