Website seems to be blocked/inaccessible via PlusNet

[#1]

Today I no longer seem to be able to access this website via my Broadband/WiFi connection: https://mantine.dev

It was working earlier today, but now any attempts to connect to it just time out. The same problem happens on both my laptop and phone (connected to WiFi) but when I try via 4G or over a VPN then it connects fine. It seems to be something on PlusNet's network that is blocking access.

I have broadband firewall currently set to "off", so I don't think it's that.

Can anyone on PlusNet's network confirm that the site is inaccessible, or is it just me?

[#2]

Same with my PN connection, can't connect to it either.
VPN and company networks are fine.
I'm not using PN DNS so it's not that either.

[#3]

Funnily enough I've been noticing some odd issues this morning and this is related. Any sites hosted on github.io (which includes `mantine.dev`) are inaccessible...

```

curl -v https://kubernetes.github.io/                                                                                                                                                                INT * Host kubernetes.github.io:443 was resolved.
* IPv6: (none)
* IPv4: 185.199.111.153, 185.199.110.153, 185.199.108.153, 185.199.109.153
*   Trying 185.199.111.153:443...
* connect to 185.199.111.153 port 443 from 192.168.0.158 port 37872 failed: Connection timed out
*   Trying 185.199.110.153:443...
* ipv4 connect timeout after 83112ms, move on!
*   Trying 185.199.108.153:443...

^C

```

```

curl -v https://mantine.dev                                                                                                                                                            ✔ * Host mantine.dev:443 was resolved.
* IPv6: (none)
* IPv4: 185.199.109.153, 185.199.108.153, 185.199.111.153, 185.199.110.153
*   Trying 185.199.109.153:443...

```

(note that the DNS name resolves to the same IP in both instances). I can connect to either hostname fine from another (non-Plusnet) network..

```

* IPv4: 185.199.108.153, 185.199.111.153, 185.199.110.153, 185.199.109.153
*   Trying 185.199.108.153:443...
* Connected to mantine.dev (185.199.108.153) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2595 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=mantine.dev
*  start date: May  8 08:10:55 2024 GMT
*  expire date: Aug  6 08:10:54 2024 GMT
*  subjectAltName: host "mantine.dev" matched cert's "mantine.dev"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

```

I've rebooted by router and received a different IP address with the same result. I'd say theres a routing issue on Plusnet's side somewhere.

[#4]

Results for a mtr (traceroute) command

 mtr -b -w -r -c 1 -w -z mantine.dev
Start: 2024-06-03T13:04:44+0100
HOST: wireguard                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.10.1                          0.0%     1    1.1   1.1   1.1   1.1   0.0
  2. AS6871   254.core.plus.net (195.166.130.254)   0.0%     1    7.6   7.6   7.6   7.6   0.0
  3. AS6871   84.93.253.115                         0.0%     1    8.3   8.3   8.3   8.3   0.0
  4. AS???                                      100.0     1    0.0   0.0   0.0   0.0   0.0

Using windows power shell test network connection tnc mantine.dev -Port 443 it fails, netstat shows

TCP    192.168.10.100:52084   185.199.109.153:443    SYN_SENT
TCP    192.168.10.100:52088   185.199.111.153:443    SYN_SENT
TCP    192.168.10.100:52089   185.199.110.153:443    SYN_SENT
TCP    192.168.10.100:52090   185.199.108.153:443    SYN_SENT

[#5]

Yes, looks like https://github.io is completely inaccessible via PlusNet.

Is the consensus that this is a PlusNet problem? If so, what's the best way to try raise it to get it fixed?

[#6]

I'd say its a PN issue. Hopefully this thread gets the attention of some Plusnet staff (@bobpullen ?)

[#7]

Ditto here - been attempting to access some docs on aws.github.io - as per others' checks, my tracert is showing nothing getting past 84.93.253.115 - which my uninformed whois-ing implies is PlusNet internal infrastructure - assuming either a fault or some rather over-zealous blocking?

[#8]

I'd say its a wider BTW issue, similar reports over at EE - suggest yiu call PN CS - the more reports they have the sooner it should get looked at.

[#9]

I concur, same issue from an EE connection.

Another report on the BT Community forums too.

Perhaps some ribs in @dave's vicinity that can be prodded?

[#10]

+1. I have been trying to get to https://zigbee2mqtt.io for a couple of days. Glad I am not alone!

[#11]

Is this why https://brew.sh is also inaccessible on PlusNet?

[#12]

Yep. Theres a post on the BT forum which links to some spamhaus reports for the affected IP addresses. Presumably BT/Plusnet auto block things on the spamhaus lists.

https://check.spamhaus.org/results/?query=SBL650085
https://check.spamhaus.org/results/?query=SBL650086
https://check.spamhaus.org/results/?query=SBL650087
https://check.spamhaus.org/results/?query=SBL650088

I'd guess that github/fastly (github's CDN provider) need to get in touch with spamhaus to get unblocked.

[#13]

https://check.spamhaus.org/results/?query=SBL650085
https://check.spamhaus.org/results/?query=SBL650086
https://check.spamhaus.org/results/?query=SBL650087
https://check.spamhaus.org/results/?query=SBL650088

I'd guess that github/fastly (github's CDN provider) need to get in touch with spamhaus to get unblocked.

[#14]

Got a chance to call Plusnet support this morning - their response is that it's a known issue, they're looking into it, and don't have an estimate for how long it'll take to get resolved. Guess I'll be getting a VPN sorted for a while then

[#15]

I doubt they'll do much about it. On the off-chance I created a support request with github to see if they can get the IP removed from the spamhaus list.

But yeah - VPN fired up, didnt realise how much documentation is hosted on github.io

[#16]

Same for me as everyone else, the following hostnames can resolve to an IP using dig on a linux CLI, but trying to ping the same hostname times out. Probably more besides.

• github.io
• mantine.dev
• brew.sh
• podman.io