Hey there AT&T is using 172.0.0.0/12 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 reolink.com If someone from AWS is reading the list, please fix this issue Mehmet -- Mehmet +1-424-298-1903
Hi Mehmet, A traceroute would be particularly useful. Have you tried accessing http://ec2-reachability.amazonaws.com/ 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? Andras
On 1 Oct 2019, at 16:29, Mehmet Akcin <mehmet@akcin.net> wrote:
Hey there
AT&T is using 172.0.0.0/12 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 reolink.com
If someone from AWS is reading the list, please fix this issue
Mehmet -- Mehmet +1-424-298-1903
Hey Andras Here you go Warning: www.reolink.com has multiple addresses; using 52.21.66.90 traceroute to www.reolink.com (52.21.66.90) , 5 relative hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 4.200 ms 55.354 ms 56.375 ms 2 192.168.1.254 (192.168.1.254) 5.175 ms 56.006 ms 57.214 ms 3 75-55-252-1.lightspeed.irvnca.sbcglobal.net (75.55.252.1) 7.264 ms 380.989 ms 382.969 ms 4 * 71.147.164.53 (71.147.164.53) 5899.218 ms 5979.390 ms 5 71.147.164.53 (71.147.164.53) 0.394 ms cr1.la2ca.ip.att.net (12.123.30.78) 40.402 ms 214.075 ms 6 cr1.la2ca.ip.att.net (12.123.30.78) 0.452 ms 12.122.2.166 (12.122.2.166) 39.478 ms 213.425 ms 7 12.122.2.166 (12.122.2.166) 0.393 ms 12.122.2.81 (12.122.2.81) 36.410 ms 210.089 ms 8 12.122.2.81 (12.122.2.81) 0.508 ms 12.123.18.209 (12.123.18.209) 35.774 ms 111.450 ms 9 12.123.18.209 (12.123.18.209) 0.383 ms 12.244.76.10 (12.244.76.10) 36.579 ms 136.809 ms 10 12.244.76.10 (12.244.76.10) 0.454 ms * * 11 * * * 12 * * * 13 * On Mon, Sep 30, 2019 at 23:32 Andras Toth <diosbejgli@gmail.com> wrote:
Hi Mehmet,
A traceroute would be particularly useful.
Have you tried accessing http://ec2-reachability.amazonaws.com/ 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?
Andras
On 1 Oct 2019, at 16:29, Mehmet Akcin <mehmet@akcin.net> wrote:
Hey there
AT&T is using 172.0.0.0/12 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 reolink.com
If someone from AWS is reading the list, please fix this issue
Mehmet -- Mehmet +1-424-298-1903
-- Mehmet +1-424-298-1903
On Mon, Sep 30, 2019 at 11:38:25PM -0700, Mehmet Akcin <mehmet@akcin.net> wrote 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 172.0.0.0/12 --requested 10 52.21.66.90 Measurement #22932983 Traceroute 52.21.66.90 from prefix 172.0.0.0/12 uses 2 probes 2 probes reported Test #22932983 done at 2019-10-01T07:46:00Z From: 172.10.12.5 7018 ATT-INTERNET4 - AT&T Services, Inc., US Source address: 172.10.12.5 Probe ID: 11203 64 52.21.66.90 14618 AMAZON-AES - Amazon.com, Inc., US [11.43, 11.158, 10.806] From: 172.8.16.48 7018 ATT-INTERNET4 - AT&T Services, Inc., US Source address: 192.168.1.73 Probe ID: 51354 64 52.21.66.90 14618 AMAZON-AES - Amazon.com, 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!!" On Tue, Oct 1, 2019 at 8:51 AM Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, Sep 30, 2019 at 11:38:25PM -0700, Mehmet Akcin <mehmet@akcin.net> wrote 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 172.0.0.0/12 --requested 10 52.21.66.90 Measurement #22932983 Traceroute 52.21.66.90 from prefix 172.0.0.0/12 uses 2 probes 2 probes reported Test #22932983 done at 2019-10-01T07:46:00Z From: 172.10.12.5 7018 ATT-INTERNET4 - AT&T Services, Inc., US Source address: 172.10.12.5 Probe ID: 11203 64 52.21.66.90 14618 AMAZON-AES - Amazon.com, Inc., US [11.43, 11.158, 10.806]
From: 172.8.16.48 7018 ATT-INTERNET4 - AT&T Services, Inc., US Source address: 192.168.1.73 Probe ID: 51354 64 52.21.66.90 14618 AMAZON-AES - Amazon.com, Inc., US [22.301, 21.612, 21.615]
On Tue, Oct 01, 2019 at 09:09:38AM +0100, Christopher Morrow <morrowc.lists@gmail.com> wrote 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.
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) -Jim P.
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. - Matt
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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.
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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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.
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@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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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.
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@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@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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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.
Yes On Wed, Oct 9, 2019 at 20:46 Javier J <javier@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@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@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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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
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. On Thu, Oct 10, 2019, 11:07 AM Mehmet Akcin <mehmet@akcin.net> wrote:
Yes
On Wed, Oct 9, 2019 at 20:46 Javier J <javier@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@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@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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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
RCN here in the greater Boston area does CGNAT inside 10.0.0.0/8. This doesn't surprise me. On Oct 10, 2019, 11:27, at 11:27, Javier J <javier@advancedmachines.us> wrote:
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.
On Thu, Oct 10, 2019, 11:07 AM Mehmet Akcin <mehmet@akcin.net> wrote:
Yes
On Wed, Oct 9, 2019 at 20:46 Javier J <javier@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@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@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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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
IPv6 all the things. On Thu, Oct 10, 2019, 12:11 PM Neil Hanlon <neil@shrug.pw> wrote:
RCN here in the greater Boston area does CGNAT inside 10.0.0.0/8. This doesn't surprise me. On Oct 10, 2019, at 11:27, Javier J <javier@advancedmachines.us> wrote:
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.
On Thu, Oct 10, 2019, 11:07 AM Mehmet Akcin < mehmet@akcin.net> wrote:
Yes
On Wed, Oct 9, 2019 at 20:46 Javier J < javier@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@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@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@nanog.org> wrote:
> On October 1, 2019 9:39:03 PM UTC, Matt Palmer < mpalmer@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
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@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@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@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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer <mpalmer@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
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@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.
Yes
On Wed, Oct 9, 2019 at 20:46 Javier J <javier@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@akcin.net> wrote:
To close the loop here (in case if someone has this type of issue in
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@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@nanog.org> wrote:
On October 1, 2019 9:39:03 PM UTC, Matt Palmer < mpalmer@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.
Mehmet Akcin writes: the 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
participants (9)
-
Andras Toth -
Christopher Morrow -
Javier J -
Jay Borkenhagen -
Jim Popovitch -
Matt Palmer -
Mehmet Akcin -
Neil Hanlon -
Stephane Bortzmeyer