The great Netflix vpn debacle!

Warren Kumari warren at
Tue Aug 31 19:01:31 UTC 2021

On Fri, Aug 27, 2021 at 7:54 PM Justin Krejci <JKrejci at>

> +1 on Bryan's message.
> It seems lots of ISPs are struggling to figure out the why and the where
> of many IP addresses or blocks that are suddenly being blacklisted or
> flagged as VPNs or as out of service area.
> I would really love to find, as Bryan said, if there is one particular IP
> reputation data provider who either got real aggressive recently or some
> (contaminated?) data was shared around. If there is I have no problem
> wading through their support processes to get it sorted but as it stands I
> just don't know who to call. It just has been very difficult to glean any
> actionable info and of course the normal support teams at the respective
> streaming providers mostly just are telling customers to call their ISP....
> as if every random ISP has some special backdoor contact to every
> streaming provider where we can just get problems resolved quickly and
> easily while we all have a good laugh at people being able to watch their
> preferred movies and shows.
> At least with email DNSBL filtering you usually get informed which DNSBL
> you are listed on and you can sort that out directly. In this case, the
> overall system of IP reputation based filtering seems still comparatively
> immature. The most I have gotten is after a very long phone call with
> someone at Hulu, they confirmed there is some issue affecting multiple
> networks and they are working on the issue and suggested I go through a
> whitelisting request process which may solve the problems but just for Hulu
> obviously.
> I have published and tried to register our own geofeed data as defined in
> RFC8805 with as many IP geolocation providers as possible.

So, RFC8805 is great and all, but it sure is annoying that you have to find
webforms for a whole heap-o-geolocation providers, and figure out how to
tell them where your geofeed file lives, etc.

Introducing RFC9092 - "Finding and Using Geofeed Data" ( ). It slices, it even
makes Julienne fries!...
Actually, nope, it just allows you to publish, in IRR records, the location
of the RFC8805 format file. e.g:
$ whois -h | egrep "inetnum|netname|remarks"
inetnum: -
netname:        ietf-meeting-network
remarks:        Geofeed

The RFC has more examples, and also suggests an optional signature to
strongly authenticate the data in the geofeed files...

Disclaimer: author

> I have checked around to as many IP geolocation and IP reputations sites
> as I can find and everything is either clean/accurate or there is no query
> method open to the public for troubleshooting that I can find. This is just
> yet another example to me of immaturity on dealing with geolocation
> problems: just spinning my wheels in the dark with mud spraying everywhere.
> There does not appear to be any consistency on handling issues by the
> content providers using IP geolocation and reputation to filter. If the
> content providers want to reject client connections they ought to provide
> more actionable information in their errors messages for ISPs since they
> are all just telling the users to call their ISPs. It just feels like a
> vicious circle.
> So currently we are left with multiple video streaming providers that all
> started to flag many customers across many of our IP blocks all beginning
> earlier this month affecting customers, many of whom have been using the
> same IP address for years without issue until now. Do we try and
> decommission multiple IP subnets shuffle users over to new subnets and risk
> contaminating more subnets if this is an ongoing and regularly updated
> blacklist data set. This would further exacerbate the problem across
> yet more subnets that are getting scarcer. As a tangent, I am curious to
> see how IP geolocation and reputation systems are handling IPv6, I suppose
> they are just grouping larger and larger networks together into the same
> listings.
> Someone who knows something concrete about this current issue, please throw
> us ISPs a bone.
> With this email I feel like Leia recording a video plea for help
> addressed to Obi-Wan Kenobi.... help me Nanog Community... you're my only
> hope.
> ------------------------------
> *From:* NANOG < at> on behalf
> of Bryan Holloway <bryan at>
> *Sent:* Friday, August 27, 2021 4:56 PM
> *To:* Mike Hammett; John Alcock
> *Cc:* nanog at
> *Subject:* Re: The great Netflix vpn debacle!
> Is there some new DB that major CDNs are using?
> We've been getting several reports of prefixes of ours being blocked,
> claiming to be VPNs, even though we've been using those subnets without
> incident for years.
> HBO, Netflix, and Hulu appear to be common denominators. I have to
> wonder if they're all siphoning misinformation off of some new DB
> somewhere ...
> On 8/14/21 1:45 AM, Mike Hammett wrote:
> >
> >
> >
> >
> > -----
> > Mike Hammett
> > Intelligent Computing Solutions <>
> > <
> <>
> >
> > Midwest Internet Exchange <>
> > <
> >
> > The Brothers WISP <>
> > <
> >
> > ------------------------------------------------------------------------
> > *From: *"John Alcock" <john at>
> > *To: *nanog at
> > *Sent: *Friday, August 13, 2021 2:11:16 PM
> > *Subject: *The great Netflix vpn debacle!
> >
> > Well,
> >
> > It happened. I have multiple subscribers calling in. They can not access
> > Netflix.
> >
> > Any contacts on list for Netflix that I can use to get my up blocks
> > whitelisted?
> >
> > John
> >

The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the NANOG mailing list