> 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
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 assigns subscriber addresses
from is 172.0.0.0/12: [ 172.0.0.0 - 172.15.255.255 ]
IPv6 all the things.
On Thu, Oct 10, 2019, 12:11 PM Neil Hanlon 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 wrote:
>>
>> Very strange ATT would put end users on an RFC 1918 block unless they
>>
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 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
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 wrote:
> Yes
>
> On Wed, Oct 9, 2019 at 20:46 Javier J wrote:
>
Yes
On Wed, Oct 9, 2019 at 20:46 Javier J 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 wrote:
>
>> To close the loop here (in case if someone has this type of issue in the
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 wrote:
> To close the loop here (in case if someone has this type of issue in the
> future), I have spoken to AT instead of trying to work it out
To close the loop here (in case if someone has this type of issue in the
future), I have spoken to AT instead of trying to work it out with AWS
Hosted Vendor, Reolink.
AT 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
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
wrote:
> On October 1, 2019 9:39:03
On October 1, 2019 9:39:03 PM UTC, Matt Palmer 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
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 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
On Tue, Oct 01, 2019 at 09:09:38AM +0100,
Christopher Morrow 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.
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 wrote:
>
> On Mon, Sep 30, 2019 at 11:38:25PM -0700,
> Mehmet Akcin wrote
> a message of 131 lines which said:
>
> >
On Mon, Sep 30, 2019 at 11:38:25PM -0700,
Mehmet Akcin wrote
a message of 131 lines which said:
> Here you go
The two RIPE Atlas probes in the AT 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
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
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?
Hey there
AT 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
18 matches
Mail list logo
