Residential Sonic IP addresses blacklisted: connection to https://www.redpocket.com/ timing out

Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
10 posts Page 1 of 1
by gabors » Wed Dec 02, 2020 11:55 am
Hello,

For the last few days connections to https://www.redpocket.com/ have been timing out, and therefore have called customer service. Their final advice was to contact Redpocket myself about the issue, even after they admitted that several other Sonic subscribers have been impacted, and even after I tried to explain the likely cause of the problem to them. I don't think I should be doing this on behalf of Sonic, though, please see below why.

Customer service helpfully determined, however, that Redpocket must be blocking my IP address, and the issue is not with my equipment, or on Sonic's end. After doing a little research, this is what I've found:

1. Running a traceroute to redpocket.com indeed reveals that the trace leaves Sonic's network, and gets blocked thereafter.

2. Running a DNS lookup for redpocket.com's IP addresses reveals that they are served by AWS. See https://mxtoolbox.com/SuperTool.aspx?ac ... n=toolpage . Therefore I think it's possible that the IP blocking is happening as part of Amazon's infrastructure, which gives me even less motivation to try to solve the issue myself by somehow getting in touch with Redpocket's internal technical teams.

3. Checking blacklist providers whether my IP address may be listed served up something, for instance: https://dnschecker.org/ip-blacklist-che ... .180.170.1 (this is not my actual IP address, I changed the last two bytes, but it's close enough). According to this, dnsbl.spfbl.net has the IP address range on its blacklist, and indeed going to https://matrix.spfbl.net/en/135.180.170.1 confirms the listing.

So my potential explanation is that Amazon is checking the blacklist providers, finds my IP address (and apparently several others in this range) on one list, and blocks access to https://www.redpocket.com/ .

My question is this: is it reasonable to assume that the blocking is caused by the blacklisting above? And if so, is it reasonable for Sonic to expect me to contact Redpocket, possibly Amazon, and if the blacklisting is the cause, spfbl.net (who btw would likely bounce me back to Sonic)? Also, besides Redpocket, other destinations may be unreachable as well, if the assumptions above are true.

I'm not sure that customer service's other suggestion, to shut down the ONT device for a few hours to acquire a new IP address would help, as it's possible I'd still get a similar IP address to the current one, which will also be listed.

Thank you very much!
by dane » Wed Dec 02, 2020 3:40 pm
The SPF listing isn't a blocklist per-se, it's an identification of the IP as a residential or dynamic IP. Generally ISPs use this as part of a scoring system in order to block email spam. The theory is basically that dynamic IP consumers shouldn't be directly delivering email, and if they are, it's a compromised host and likely spam.

I'm afraid these sort of issues can be challenging to isolate and resolve, but it's not clear who is doing the blocking.I don't know why Redpocket would be blocking any Sonic IPs, you'd need to ask them about that. I can't imagine that Amazon AWS itself is doing so, that wouldn't align with the function of their business model. All I can say is that Sonic itself isn't doing any blocking, which I think you can see in the traceroute.
Dane Jasper
Sonic
by gabors » Wed Dec 02, 2020 5:17 pm
Dane, thanks a lot. I indeed thought so that spfbl doesn't serve as a strict exclusive blacklist, only one of the many signals that service operators use, and thought that perhaps the thresholds at Redpocket are set a bit too sensitive. But seeing no other obvious reason for the blocking that was one thing I could see perhaps happening. It's also a good sign that other blacklist providers don't seem to list the Sonic IP addresses. In any case I notified Redpocket also about the issue.
by dane » Wed Dec 02, 2020 5:23 pm
gabors wrote:Dane, thanks a lot. I indeed thought so that spfbl doesn't serve as a strict exclusive blacklist, only one of the many signals that service operators use, and thought that perhaps the thresholds at Redpocket are set a bit too sensitive. But seeing no other obvious reason for the blocking that was one thing I could see perhaps happening. It's also a good sign that other blacklist providers don't seem to list the Sonic IP addresses. In any case I notified Redpocket also about the issue.
SPF (sender policy framework) BL is used as an antispam scoring metric for email, which is generally not trusted when it comes from an end-user's PC rather than an actual email server.

It is not used as a block-list for services like Redpocket or Amazon AWS who are seeking to serve exactly those sort of end-users.

I wonder if you've got a client issue there. Antivirus or antimalware, etc..? Have you checked from multiple devices, like a phone or tablet etc? A good test would be to see if the website loads from your phone when WiFi is disabled, but then does not work when WiFi (via Sonic) is enabled. If that fails, and other devices also fail when connected via our network, it points toward something on our side or beyond.

Traceroute can also be a bit misleading. Just because traffic makes it part way but not the full distance, doesn't mean it's the far side. Could be a bad route somewhere between the two networks - on third party networks that perhaps neither of us control. The internet is complex that way.
Dane Jasper
Sonic
by gabors » Wed Dec 02, 2020 6:53 pm
Thank you Dane, yes, the explanation you see for a query like https://matrix.spfbl.net/en/135.180.170.1 did suggest that the reason these IPs are on the list has to do with running an email server on a dynamic address, and it'd be indeed counterproductive for Redpocket to ban even just suspect IP addresses based on a different use case (email sending vs. Web browsing), or even to ban anybody for that matter. The possibility I saw was that maybe they configured their Web servers just in a generic way to reject potentially malicious scrapers, but this is just a theory and you may be right.

Yes, I tried combinations of devices and connection types (laptop, phone, tablet, and Sonic or 4G connection), even browsers. The Sonic connection consistently fails, independently of the device, and the 4G connection consistently succeeds, independently of the device. When I tried to go through Web anonymizer proxies with the Sonic connection that also loaded the site as expected. So this suggested to me that it'd maybe have to do with the IP address after all.

You're right, when I tried traceroute with the 4G connection (which does load the Web site), that also stopped somewhere in the AT&T network, so this is not a reliable indicator, however just in case: the traceroute with the Sonic connection stops on some AWS server. Not reading too much into it.
by virtualmike » Wed Dec 02, 2020 11:35 pm
What happens if you try while connected to Sonic VPN?
by gabors » Thu Dec 03, 2020 12:10 pm
That was a good idea, and through the VPN, Redpocket is reachable.

What's more, if you check the public IPv4 & IPv6 addresses I go through now on the Sonic VPN in the spfbl.net database, or dnschecker.org that I used previously, they also come back as flagged. (The IPv4 one with the same message as what I get for my IP address, "This IP has been flagged because it is dynamic or by suspect to be domestic use only.", the IPv6 one because of "This IP has been flagged because have none valid FCrDNS.")

So just SPFBL by itself is not a likely explanation after all, but the origin IP address or some routes still seem to play a role? I'm just a bit concerned that it may be that it's not only Redpocket that shows this, and you'll never know.
by dane » Thu Dec 03, 2020 12:37 pm
The SPF list is a red herring - that's simply a list of all dynamic residential IP addresses for all ISPs in America and beyond. It's got nothing to do with any issues you're having, unless you are trying to run a mail server and everyone is rejecting your email because they think it's probably spam.

Dunno why though you're not able to reach their site. What do they say about it?

One tool that can be really useful is to see a traceroute in both directions. Can they run one toward you, which we can compare to the one you can run toward them?
Dane Jasper
Sonic
by gabors » Thu Dec 03, 2020 4:59 pm
I understand there's no real reason to use those lists if you're a website provider, but if a blocking is happening closer to their end (which I think you & customer service suggested is at least a possibility), they must be using some resources to base a decision on, even if these blacklists are a red herring (and of course I'm not running a mail server, and this is a Web request)... At any rate I got a more or less generic response from them suggesting to use a stable connection and clear the browser caches, but I linked them to this thread and told them about your suggestion to run the reverse traceroute, in case their technical teams can take a look at it next.
by dane » Thu Dec 03, 2020 5:37 pm
Sounds good. Sorry to leave you stuck in the middle on this, with both of us pointing fingers. I just don't think we have a fix, at least in that it appears the issue is on their side, limited to their site.
Dane Jasper
Sonic
10 posts Page 1 of 1

Who is online

In total there are 26 users online :: 1 registered, 0 hidden and 25 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: Semrush [Bot] and 25 guests