AWS issues with

Hey there

AT&T is using block as public IP for customers in USA. AWS seems to be blocking this block, I can reach to many sites just fine but i can’t get to some sites hosted on AWS such as

If someone from AWS is reading the list, please fix this issue


Hi Mehmet,

A traceroute would be particularly useful.

Have you tried accessing to verify if the green icons load? If not, any particular region that’s broken? Could you collect a traceroute towards some of the working and non-working IPs listed there?


Hey Andras

Here you go

Warning: has multiple addresses; using
traceroute to ( , 5 relative hops max, 52 byte packets
1 ( 4.200 ms 55.354 ms 56.375 ms
2 ( 5.175 ms 56.006 ms 57.214 ms
3 ( 7.264 ms 380.989 ms 382.969 ms
4 * ( 5899.218 ms 5979.390 ms
5 ( 0.394 ms ( 40.402 ms 214.075 ms
6 ( 0.452 ms ( 39.478 ms 213.425 ms
7 ( 0.393 ms ( 36.410 ms 210.089 ms
8 ( 0.508 ms ( 35.774 ms 111.450 ms
9 ( 0.383 ms ( 36.579 ms 136.809 ms
10 ( 0.454 ms * *
11 * * *
12 * * *
13 *

a message of 131 lines which said:

Here you go

The two RIPE Atlas probes in the AT&T prefix seem able to reach AWS:

% blaeu-traceroute --protocol TCP --size=0 --port=80 --first_hop=64 --format --prefix --requested 10
Measurement #22932983 Traceroute from prefix uses 2 probes
2 probes reported
Test #22932983 done at 2019-10-01T07:46:00Z
Source address:
Probe ID: 11203
64 14618 AMAZON-AES -, Inc., US [11.43, 11.158, 10.806]

Source address:
Probe ID: 51354
64 14618 AMAZON-AES -, Inc., US [22.301, 21.612, 21.615]

possible that this is various AWS customers making iptables/firewall mistakes?
  "block that pesky rfc1918 172/12 space!!"

a message of 27 lines which said:

possible that this is various AWS customers making iptables/firewall mistakes?
  "block that pesky rfc1918 172/12 space!!"

May be, but I used the same target as Mehmet.

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)

-Jim P.

Does AWS use internally, or They're different
things, after all.

- Matt

I don't know their entire operations, but they do use some
addresses internally. And yes, that is very different than 172/12, sorry
for the confusion.

-Jim P.

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.

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.


I’m just curious, was the ip in the RFC 1918 range?


Very strange ATT would put end users on an RFC 1918 block unless they were doing NAT to the end user.
If they were doing NAT, I would expect CGNAT in the 100.something or other range.

RCN here in the greater Boston area does CGNAT inside This doesn’t surprise me.

IPv6 all the things.

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

One of the public ipv4 ranges that AT&T assigns subscriber addresses
from is [ - ]

One of the private ipv4 ranges set aside by RFC 1918 is the
neighboring [ - ]

We notice more mis-originations of our 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 and not our

            Jay B.

Mehmet Akcin writes:

No, Mehmet’s public IP was not from the RFC 1918

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