Corporate Public IP range can't access some statuspage sites

[Robin Martin]

My company (in Australia) has two public /24 ranges, site A and site B.

### From Site A, we can access some statuspage sites but not others.

These work

https://status.vendorrisk.com
https://status.airship.eu
https://status.avidian.com
https://status.castlighthealth.com

- these ones appear to be behind a CDN or similar (I think), judging by the name resolutions, which returns nested CNAMEs

e.g, status.vendorrisk.com CNAME n4l7z84txh8s.stspg-customer.com
n4l7z84txh8s.stspg-customer.com CNAME status-vendorrisk-com-60f513b0-775d-49e8-b4b2-1b4490d25faf.saas.atlassian.com

But these do not.

https://status.kajabi.com
https://status.kore.com
https://status.thehive.ai
https://status.arkoselabs.com

- telnet does work, so assuming application layer

- these ones that don't all seem to be in the range 13.236.8.0/24

- these one name resolve to just a single CNAME

e.g., status.arkoselabs.com CNAME ntmkcpjv4jzt.stspg-customer.com 

- In a Wireshark session, we do not receive the 'server hello'

### From Site B, or my work laptop, or my personal phone, they all work.

From the above, you'd assume there's a reputation or geolocation problem with our Site A range. However I've checked the range on the sites below and appears all clean.

https://mxtoolbox.com/blacklists.aspx

https://talosintelligence.com/reputation_center/

So my questions are

- are you able to see any common differences between these 2 lists of statuspage sights, which could explain the differences? Different types of statuspage subscription plans they have maybe?

- is there a particular reputation database or site that statuspage uses to block bad actors?

- any idea why this may be happening?

Thanks,

Robin

[Scot Wilson · Accepted solution]

G'day Everybody - It's Scot from the APAC Statuspage Support team with an update for anyone who turns up this question in a search.

Robin and I worked on this in a ticket through the Atlassian Support portal, as network details can be considered sensitive data and we never want you to expose anything in Community threads.

We identified there was not any IP Blocking on the Statuspage side, and the connectivity issue is related to just this particular subnet. However, our investigation into this has stopped as a Statuspage backend update has rendered it moot, since it's no longer happening.

Currently, we're migrating the distribution of our backend hosting of your Statuspages to our newer distribution platform (for improved scalability and enhanced protection) and this has resolved the connection problems for this scenario. This is a rolling change that will propagate throughout all the Statuspages we provide over time. 

Cheers,
Scot Wilson

[Robin Martin]

Thanks Scot, as discussed. Root cause is likely on my end, but this has been a great work around.