STH site and forum block from my IP
- Thread starter airocle
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
From what I can see, it’s not that new. While it was registered in ‘21 with the current group, I don’t see anything that might suggest it was previously reserved for something else, that whole /8 was previously allocated to APNIC and released around 2011 for use.
APNIC themselves produced a report back in 2010 about using that block for general use with some very specific caveats about some host IPs, but not in this /23 range.
The AS for that company was allocated in 2004. It’s not an ISP that owns it however. You probably know this already and I’m making some assumptions here at this point. Based on your username, I assume you’re part of that company.
Going back to 2017 that wasn’t in the general bogons list, so I surmise it could be an outbound issue for you. Can you confirm your sourcing from that first /24 of that block?
Do you have any visibility into your edge FWs to confirm it’s not being blocked outbound for whatever reason?
APNIC themselves produced a report back in 2010 about using that block for general use with some very specific caveats about some host IPs, but not in this /23 range.
The AS for that company was allocated in 2004. It’s not an ISP that owns it however. You probably know this already and I’m making some assumptions here at this point. Based on your username, I assume you’re part of that company.
Going back to 2017 that wasn’t in the general bogons list, so I surmise it could be an outbound issue for you. Can you confirm your sourcing from that first /24 of that block?
Do you have any visibility into your edge FWs to confirm it’s not being blocked outbound for whatever reason?
Last edited:
Your assumptions are correct for the most part.
Definitely sourcing from the first /24 in the block. I've also triple checked it's not being blocked outbound. If I change the source to be from an IP from an ISP's pool, it works just fine with the same firewall rule set, hence my assumption about an outdated bogons list somewhere.
Checking edge firewalls, I can see outbound attempts to STH and the forums, but 0 bytes of return traffic.
Definitely sourcing from the first /24 in the block. I've also triple checked it's not being blocked outbound. If I change the source to be from an IP from an ISP's pool, it works just fine with the same firewall rule set, hence my assumption about an outdated bogons list somewhere.
Checking edge firewalls, I can see outbound attempts to STH and the forums, but 0 bytes of return traffic.
I hate troubleshooting the internet. 
The amount of times I have to do this with clients...
Well, generally speaking, from what I have visibility into, I see each end's prefixes in various spots, but you'd need to confirm your ISP has STH's route and their ISP has yours. I've seen instances before where that's not the case.
Not an end client issue per se.
I trace may give some insight, but not always.
The amount of times I have to do this with clients...Well, generally speaking, from what I have visibility into, I see each end's prefixes in various spots, but you'd need to confirm your ISP has STH's route and their ISP has yours. I've seen instances before where that's not the case.
Not an end client issue per se.
I trace may give some insight, but not always.
It's always interesting isn't it
For what it's worth, a trace from our end towards STH, the path is identical sourced from the troublesome block, or from an alternate address that works.
Is it possible for you to DM me a trace from your end, or do you not have that capability?
For what it's worth, a trace from our end towards STH, the path is identical sourced from the troublesome block, or from an alternate address that works.
Is it possible for you to DM me a trace from your end, or do you not have that capability?
I don't mind posting it here for all to see. For this I'm behind a CGNAT so it doesn't matter. From either ISP I have (from a home perspective for the purposes of this testing) the results are the same; obscured behind HE.
Code:
1 <1 ms <1 ms <1 ms 10.1.2.1
2 <1 ms <1 ms <1 ms 10.48.78.225
3 17 ms 16 ms 18 ms 11.1.6.254
4 * * * Request timed out.
5 16 ms 23 ms 16 ms 213.121.52.213
6 * * * Request timed out.
7 20 ms 69 ms 28 ms 109.249.132.46
8 22 ms 35 ms 19 ms 166.49.209.194
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 189 ms 206 ms 193 ms 184.104.199.58
15 * * * Request timed out.
<truncated>Interesting. Here's what I see:
Code:
Start: 2023-07-02T21:24:32+0000
HOST: DESKTOP Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 2 0.3 0.3 0.3 0.3 0.0
2.|-- ??? 0.0% 2 0.7 0.7 0.7 0.8 0.1
3.|-- 159.196.194.134 50.0% 2 6.2 6.2 6.2 6.2 0.0
4.|-- HundredGigE0-0-0-35.cfl1.nextdc-s2.syd.aussiebb.net 0.0% 2 95.3 95.3 95.2 95.3 0.1
5.|-- 10.241.13.78 0.0% 2 97.3 97.2 97.0 97.3 0.3
6.|-- be2.lsr2.equinix-sy4.syd.aussiebb.net 0.0% 2 96.7 97.1 96.7 97.5 0.6
7.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0
8.|-- be30.core2.equinix-sg1.sin.aussiebb.net 0.0% 2 95.7 95.6 95.5 95.7 0.2
9.|-- port-channel14.core3.sin1.he.net 0.0% 2 261.1 261.1 261.0 261.1 0.0
10.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0
11.|-- he-peer.eqnx03.pr.telstraglobal.net 50.0% 2 249.6 249.6 249.6 249.6 0.0
12.|-- 100ge4-2.core3.fmt2.he.net 0.0% 2 246.5 246.5 246.5 246.5 0.0
13.|-- 100ge2-1.core2.fmt2.he.net 0.0% 2 315.9 287.1 258.4 315.9 40.7
14.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0Your 13th hop is effectively the same as my original 14th...
I don't resolve usually as it's faster in some cases...but here's the same again truncating the first few irrelevant hops:
That said, I'd be interested to see your prefix in the far end's routes.
I don't resolve usually as it's faster in some cases...but here's the same again truncating the first few irrelevant hops:
Code:
7 20 ms 19 ms 22 ms 109.249.132.40
8 22 ms 17 ms 19 ms core6-hu0-0-0-35.faraday.ukcore.bt.net [62.6.201.245]
9 31 ms 23 ms 25 ms 166-49-209-194.gia.bt.net [166.49.209.194]
10 * * * Request timed out.
11 91 ms 97 ms * port-channel7.core2.nyc5.he.net [72.52.92.102]
12 * * * Request timed out.
13 * 166 ms * port-channel13.core3.sjc2.he.net [184.104.198.253]
14 * 170 ms * 100ge0-71.core1.fmt2.he.net [184.104.197.40]
15 179 ms 197 ms 196 ms 100ge1-2.core2.fmt2.he.net [184.104.199.58]
16 * * * Request timed out.Not a clue. I would assume they may have some service in front of it, but if they did, like Cloudflare, it would leverage Cloudflare's IPs, not Hurricane Electric's. In this instance, they're definitely not using Cloudflare.
Where specifically they're hosted I don't know. And spot checking HE's looking glass, I saw your prefix.
Where specifically they're hosted I don't know. And spot checking HE's looking glass, I saw your prefix.
Based on the whois, they're HE IP's, but STH's fearless leader is named as a contact for the /27
Being STH, it's got to be self-hosted
I guess this strengthens my suspicions it's an outdated bogons list (not the first time I've come across this, and it's mostly been sites that are self-hosted/managed to some degree). It's also my reasoning for wondering if I'm not the only one that can't access STH and it's gold-mine of info for this reason.
Being STH, it's got to be self-hosted
I guess this strengthens my suspicions it's an outdated bogons list (not the first time I've come across this, and it's mostly been sites that are self-hosted/managed to some degree). It's also my reasoning for wondering if I'm not the only one that can't access STH and it's gold-mine of info for this reason.
The plot thickens.
Doing a trace to a random IP out of your range, Equinix and Core Site gets somewhere, DRT does not and dies out after the first hop. This is for their San Fran POPs. All other California POPs seem to work. I have a large disdain for DRT, and this tracks.
It would be nice if @Patrick or someone in that team could chime in.
Doing a trace to a random IP out of your range, Equinix and Core Site gets somewhere, DRT does not and dies out after the first hop. This is for their San Fran POPs. All other California POPs seem to work. I have a large disdain for DRT, and this tracks.
It would be nice if @Patrick or someone in that team could chime in.