AWS issues with 172.0.0.0/12

Javier J javier at advancedmachines.us
Mon Oct 21 18:46:50 UTC 2019


> No, Mehmet's public IP was _not_ from the RFC 1918 172.16.0.0/16
range.

I was guessing the same thing. It wouldn't matter even behind NAT if you
are using RFC 1918 unless you are building a tunnel into the VPC since in
the AWS VPC, you are behind a NAT / Internet Gateway for anything to reach
the public IPv4 internet.

- Javier



On Fri, Oct 11, 2019 at 7:48 AM Jay Borkenhagen <jayb at braeburn.org> wrote:

> I'm surprised that no one else has corrected this, so allow me to do
> so for the record.
>
> No, Mehmet's public IP was _not_ from the RFC 1918 172.16.0.0/16
> range.
>
> One of the public ipv4 ranges that AT&T assigns subscriber addresses
> from is 172.0.0.0/12: [ 172.0.0.0 - 172.15.255.255 ]
>
>  https://whois.arin.net/rest/net/NET-172-0-0-0-1
>
> One of the private ipv4 ranges set aside by RFC 1918 is the
> neighboring 172.16.0.0/12: [ 172.16.0.0 - 172.31.255.255 ]
>
>  https://whois.arin.net/rest/net/NET-172-16-0-0-1
>
>
>
> We notice more mis-originations of our 172.0.0.0/12 space and its
> more-specifics than any of our other ipv4 blocks, probably because
> other folks are similarly confused.  So please, if you intend to use
> RFC1918 space, please check your filters to make sure you're using
> 172.16.0.0/12 and not our 172.0.0.0/12.
>
>                                                 Jay B.
>
>
> Mehmet Akcin writes:
>  > Yes
>  >
>  > On Wed, Oct 9, 2019 at 20:46 Javier J <javier at advancedmachines.us>
> wrote:
>  >
>  > > I'm just curious, was the ip in the RFC 1918 172.16.0.0/16 range?
>  > >
>  > > https://tools.ietf.org/html/rfc1918
>  > >
>  > >
>  > >
>  > > On Mon, Oct 7, 2019 at 6:01 PM Mehmet Akcin <mehmet at akcin.net> wrote:
>  > >
>  > >> To close the loop here (in case if someone has this type of issue in
> the
>  > >> future), I have spoken to AT&T instead of trying to work it out with
> AWS
>  > >> Hosted Vendor, Reolink.
>  > >>
>  > >> AT&T Changed my public IP, and now I am no longer in that 172.x.x.x
>  > >> block, everything is working fine.
>  > >>
>  > >> mehmet
>  > >>
>  > >> On Thu, Oct 3, 2019 at 2:54 PM Javier J <javier at advancedmachines.us>
>  > >> wrote:
>  > >>
>  > >>> Auto generated VPC in AWS use RFC1819 addresses. This should not
>  > >>> interfere with pub up space.
>  > >>>
>  > >>> What is the exact issue? If you can't ping something in AWS chances
> are
>  > >>> it's a security group blocking you.
>  > >>>
>  > >>>
>  > >>>
>  > >>> On Tue, Oct 1, 2019, 7:00 PM Jim Popovitch via NANOG <
> nanog at nanog.org>
>  > >>> wrote:
>  > >>>
>  > >>>> On October 1, 2019 9:39:03 PM UTC, Matt Palmer <
> mpalmer at hezmatt.org>
>  > >>>> wrote:
>  > >>>> >On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG
>  > >>>> >wrote:
>  > >>>> >> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
>  > >>>> >> > possible that this is various AWS customers making
>  > >>>> >iptables/firewall mistakes?
>  > >>>> >> >    "block that pesky rfc1918 172/12 space!!"
>  > >>>> >>
>  > >>>> >> AWS also uses some 172/12 space on their internal network (e.g.
> the
>  > >>>> >network
>  > >>>> >> that sits between EC2 instances and the AWS external firewalls)
>  > >>>> >
>  > >>>> >Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
>  > >>>> >different
>  > >>>> >things, after all.
>  > >>>> >
>  > >>>>
>  > >>>> I don't know their entire operations, but they do use some
>  > >>>> 172.16.0.0/12
>  > >>>> addresses internally. And yes, that is very different than 172/12,
> sorry
>  > >>>> for the confusion.
>  > >>>>
>  > >>>> -Jim P.
>  > >>>>
>  > >>>> --
>  > Mehmet
>  > +1-424-298-1903
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191021/21d2eac1/attachment.html>


More information about the NANOG mailing list