Added support to add 500 IPs to thje allowlist.

https://support.atlassian.com/security-and-access-policies/docs/specify-ip-addresses-for-product-access/

We have added support to accommodate 500 IPs- therefore closing this ticket. 

We will be adding support to increase the limit from 100 to 500 by 10/15/24. 

We are currently building this feature. Potential launch date - 10/1/2024

https://getsupport.atlassian.com/browse/PCS-229666

Well we use the whitelist for a subset of third party address's to reach our ecosystem. How ever I am installing plugins that require Atlassian Forge Allow-listing. Well guess what we only have 100 slots to do this work with and that is not enough to even cover all of the CIDR blocks your forge apps have.

I wanted to get this behaviors plugin to work with Script Runer. 
https://docs.adaptavist.com/sr4jc/latest/features/behaviours

Well I was going to start looking into adding the into the scope of allowed lists but then noticed over 1200 records with various cidr blocks. Why does Forge not have a single IP address or a small subset that is NAT'ed back to the end users cloud instance. Because at this point we are hard blocked after being forced to move to cloud.

https://ip-ranges.amazonaws.com/ip-ranges.json

Force Closure of Server Instances to make people use DC or Cloud was a terrible move as DC is almost 3 times the cost and Cloud is not flushed out enough. If you are a simple user then this may not be an issue. But how can you be a power user of a product when the Providers of the tool simply block you from using their tool in an agile way to moving back to a waterfall methodology of using the tool.

To those of your who are saddled with the 100 IP address limitation in the allow list:

We attempted to use the new Behaviours module, from ScriptRunner, that is making use of Forge. With over 400 IP addresses to included in the allow list (we are in region us-west-2), I appreciate that the support team was able to increase my limit of IP addresses to 1000. With that increase, the Behaviours module now works!

Literally turned me into a switch board operator.... turning access on and off for remote users to get their work done.

We were essentially forced to move to the cloud, and then only given 100 IPs to work with. With a global workforce this is an indefensible, this is a product defect, not a 'feature request'. 

VPN is not a solution for our company.

We have around 500 users in different countries.

If we want to allow countries from CH, EU, EFTA, UK, Ukraine, Congo, South Africa and Kenya, there are total 827225 IPs with IPv4 and 19244 with IPv6 to configure.

I think it makes more sense that the whitelist has no limitation.
    
Our wish is also that you can configure not only a whitelist but also a blacklist of IPs that you do not want to allow to access Jira or Confluence in the cloud.

For allowed-listing of IPs of SaaS services like Zscaler or Cloud Providers i.e. Azure, AWS, or GCP, that 1000 IP address limit will quickly be filled up. Azure's US Central Region alone lists out 460+ IP addresses so the 1000 IP address limit can be easily reached. Is there a way to create a dynamic object or an updateable object as these IP addresses can change dynamically? It becomes extremely difficult to scale and to keep up with the IP addresses that may constantly change.

Can't agree more with the above, I currently need to choose which integration / service can work and which cannot. 
Simple example : Atlassian's own Google Sheet integration add-on requires 13 IPs to be whitelisted, Okta workflows 32, Workato 6, Strongpoint 15... Which lefts me with 34 entries left, which are all taken by our own integrations and the few other services that need to be whitelisted. 
So now I'm having the time of my life reaching out to all of my users asking them whether they're sure they need the x IPs they asked me to whitelist for their integrations or scripts so I can enable once again the 13 required for the Google Sheet integration add-on and the 5 ones for LogicMonitor. 2023 is almost literally tomorrow and we're still stuck in 2000's. 

If the assignee can upgrade us to 1000, that'd be great, thanks. Our org id is 872d4795-bb67-1053-j493-28k6d6ddc108https://jira.atlassian.com/secure/ViewProfile.jspa?name=eee30c920d0f

This should be considered a feature design flaw (bug) as you have Azure cloud with over 70 IPs you need to whitelist and Atlassian themselves have 29 that require whitelisting in some integrations. If a VPN service is such a great idea, why doesn't Atlassian do it for themselves. As more people move to the cloud this is going to get much worse.

We have around 200 clients, some of which have multiple locations. 100 IP address per product is not sufficient to continue business on the Atlassian Platform. We've even had Atlassian increase our whitelist to 1000 but we are already nearing that limit. We are in high business need to surpass 1000 ips. Please assist.

Agree with @Rick Hadsell, 1,000 should just be the default for everyone (in fact I don't think there should be a limit).

It doesn't make any sense that the default is 100 as even small organizations can easily exceed that number, and also since we deal with customers from a variety of different organizations it's not possible to stay under the 100 limit when consolidating into CIDR blocks. I tried.

The VPN option is also not possible for the same reasons.

Regards.

The update to workaround is absurd. No company is going to adopt a VPN service to consolidate CIDR blocks. It's a ridiculous, tone-deaf suggestion that once again reinforces what I've been saying for a decade: Atlassian still doesn't get enterprise. 

Just change the default flag to 1000, which worked for us and several other customers. Why is this even an issue if you can reconfigure your service to support a larger number?

Will consider increasing the IP allowlist for all customers in the near future. For now use the workaround suggested in the ticket.

Curiously, when I navigate to IP allowlists on the admin panel, the hex string changes to:

569e8e4b-0678-4d3f-8879-6c2a07e4473a

Can you set that org-ID to 1000 too please?  

Internal organization - we use the CIDR blocks to allow broad company-wide read for content in Confluence but not have our proprietary Confluence Cloud open to the internet. Our licenses are obviously restricted to editors. 

The IPs are all internal company IPs - either VPN or company office locations. Browser access mostly, and to date all internal. 

Hi Srivatsa, can you please advise if this has been actioned as per my last comment?

Hi Srivatsa, thank you our ord-id is:

https://admin.atlassian.com/o/e940a6c5-7be7-4bd5-ba81-4c4ca395dc5b/overview

If you could please increase our limit to 1000 as discussed and confirm back.

Cheers.

Hi Srivatsa, it maybe pshelp if you can see that org-id?

Regards.

Hi Srivatsa, please advise where I can't find my 'org-id', I can see anything that references that anywhere in Jira Admin.

Regards.

Can this improvement be given some priority please. It's a un-usually low number (100 IP addresses) and is really limiting our ability to allow access to our confluence site in a secure manner.

Because we've grown from a small startup to a mid-sized company over 20 years, and also have significant M&A and regional office locations, we have more than 100 CIDR blocks.

Important: IP Whitelisting is the ONLY way for an organization moving from Server to Cloud products to continue with company-wide read-only without licensing thousands of users who likely never touch the system and if they do, only read something. So this limitation is frustrating.