dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
3297

exocet_cm
Writing
Premium Member
join:2003-03-23
Brooklyn, NY

exocet_cm

Premium Member

[LA] Cox routing class C over the internet?

Click for full size
Click for full size
I was having an issue bringing a remote site online using 192.168.14.0/24 block, did a port scan of the block and saw that the 14.0/block is being routed over the internet?

To make sure I wasn't smoking the good stuff, I had a friend check. Same result.
Rakeesh
join:2011-10-30
Phoenix, AZ

Rakeesh

Member

LOL it does. Just confirmed here as well.

Cox is in violation of RFC 1918, somebody call the internet cops.

You'll have to work around that by setting a static route in your routing tables. Lots of consumer grade routers should be able to do this, not just high end equipment. Still though that is a problem that Cox should probably fix - I'm guessing possibly a security issue as well since it's my guess that whatever is on this network wasn't intended for public exposure, but it is being exposed to their customers.

Optimus2357
Premium Member
join:2010-11-21
West Warwick, RI

1 recommendation

Optimus2357

Premium Member

He is the law. LOL

exocet_cm
Writing
Premium Member
join:2003-03-23
Brooklyn, NY

exocet_cm to Rakeesh

Premium Member

to Rakeesh
Yeah, hopefully they'll fix it. I just use another block until they do, no biggie... gotta rearrange my Visio now
cmos100
join:2004-08-24
Lafayette, LA

cmos100

Member

Those IP's are filtered and are not routed over the internet.

exocet_cm
Writing
Premium Member
join:2003-03-23
Brooklyn, NY

exocet_cm

Premium Member

Filter only on Cox's network perhaps...
cmos100
join:2004-08-24
Lafayette, LA

cmos100

Member

They are filtered at the edge and not advertised to the internet

exocet_cm
Writing
Premium Member
join:2003-03-23
Brooklyn, NY

exocet_cm

Premium Member

I think the point is a private class C is being routed of the "internet" (define how you want). See attached tracert to confirm. If I, in New Orleans, and Rakeesh, in Arizona, as well as a third party here in NOLA are seeing this... probably a problem.

Those IPs should not be showing up on Cox's network like that.
cmos100
join:2004-08-24
Lafayette, LA

cmos100

Member

It's not being routed over the internet, it's staying local. RFC 1918 defines the private IP space that may not be advertised to the global internet and may be used by the local enterprise without coordination from IANA. Which is what's happening.

CoxTech1
join:2002-04-25
Chesapeake, VA

CoxTech1

Member

That' correct. These IP's are being used within the Cox network and not being used for routing across the public Internet.

Optimus2357
Premium Member
join:2010-11-21
West Warwick, RI

Optimus2357

Premium Member

Just out of curiosity, if someone had found a Cox security vulnerability, what is the proper procedure to report it?

CoxTech1
join:2002-04-25
Chesapeake, VA

1 recommendation

CoxTech1

Member

Any evidence of abuse originating from the Cox network should be sent to abuse@cox.net for processing. Note they do not accept attachments and any evidence should show a Cox IP address.

exocet_cm
Writing
Premium Member
join:2003-03-23
Brooklyn, NY

exocet_cm to CoxTech1

Premium Member

to CoxTech1
So the 14.x IPs we are hitting are Cox's network?
I'll write a firewall rule to not allow that traffic outside of my gateway. :-\
Rakeesh
join:2011-10-30
Phoenix, AZ

Rakeesh to CoxTech1

Member

to CoxTech1
said by CoxTech1:

That' correct. These IP's are being used within the Cox network and not being used for routing across the public Internet.

Isn't that somewhat broken that I can hit an RFC1918 address from the other side of a non-RFC1918 router?

I mean yeah so long as it isn't being distributed via BGP it's probably within spec as far as IANA is concerned, but it's clearly breaking intranet functionality for at least one customer, who should otherwise be right to assume that the entire address space should be usable. Hell, what if some manufacturer of home network equipment wanted to troll Cox by making 192.168.14.0/24 its default network?

Besides, given that this is an RFC1918 address, I would think that whatever devices you put there aren't intended for public exposure, correct? If so, security best practices would tell me that these shouldn't be reachable by customers in any case.
said by exocet_cm:

So the 14.x IPs we are hitting are Cox's network?
I'll write a firewall rule to not allow that traffic outside of my gateway. :-\

I'd opt for route adjustment instead, but that's just my personal pref.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to exocet_cm

MVM

to exocet_cm
said by exocet_cm:

[LA] Cox routing class C over the internet?

"Class C" is more than just an RFC 1918 IP address range. I expect there is nothing wrong with routing the majority of "Class Cs" extant. In any case, "Class C" is old school; even passe. Current network jargon is, "Classless Inter Domain Routing" (CIDR), in which the "Class C" is now a "/24".

It appears that Cox is using 192.168.14.0/24 internally. Odd. Some ISPs use 10.0.0.0/8 to extend the number of IPv4 IP addresses for customers (instead of deploying IPv6); part of Carrier Grade NAT? But a /24 doesn't buy a lot of address space.

Optimus2357
Premium Member
join:2010-11-21
West Warwick, RI

Optimus2357

Premium Member

Cox uses CIDR in a different way I believe, bonding public IPs to block of other public IP's for business customers. It allows the assigning of greater static IP and protects them from changing like a static IP might when a network is upgraded. Atleast thats how it was described to me.

»ww2.cox.com/business/ida ··· 00000000

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS

MVM

Not different at all. What I used as examples is simply the CIDR equivalent for Class A and Class C. The three ranges of RFC 1918 are:

• 10.0.0.0/8 (Class A)
• 172.16.0.0/12 (Class ?)
• 192.168.0.0/16 (Class B)

There is no "classful" equivalent for a "/12". Very few ISPs own entire Class As; most block assignments are marked by CIDR notation.

Here is a block of IP addresses assigned to AT&T (nee SBC); mostly assigned to residential dynamic accounts. I believe AT&T further subdivides them by CIDR for assignment to regional POP centers:
NetRange            64.160.0.0 - 64.175.255.255
CIDR                64.160.0.0/12
Name                SBCIS-SIS80
Handle              NET-64-160-0-0-1
Parent              NET64 (NET-64-0-0-0-0) 
Net Type            Direct Allocation
Organization        AT&T Internet Services (SIS-80) 
Registration Date   2000-06-02
Last Updated        2012-03-02
 

Here is the Cox IP block from the OP:
NetRange              68.11.0.0 - 68.11.127.255
CIDR                  68.11.0.0/17
Name                  NETBLK-NO-RDC-68-11-0-0
Handle                NET-68-11-0-0-1
Parent                COX-ATLANTA (NET-68-0-0-0-1) 
Net Type              Reassigned
Customer              Cox Communications (C00670875) 
Registration Date     2003-09-23
Last Updated          2007-08-16
 

It is smaller than the AT&T block, but likely is similarly subdivided among different NOCs.

Optimus2357
Premium Member
join:2010-11-21
West Warwick, RI

Optimus2357

Premium Member

I guess the word "different" was not accurate. I meant the term is used to refer to those blocks, as apposed to single or groups of IP, assigned to customers. All I meant is to state my opinion that I don't think Cox uses the 192.168.14.0/24 for customers with NAT, but just their internal network. Maybe the IP's that were planned for that part of the network were allocated else where so the /24 are acting as place holders? I refer to your obvious expertise though.
cmos100
join:2004-08-24
Lafayette, LA

cmos100

Member

It's not a place holder and it shouldn't effect someone using the same subnet behind a firewall/router on a cable modem. Those IP's in that subnet would be converted to the public IP by nat before it hits the cable modem. The router on a cable modem just uses a default route and doesn't learn routes coming from the outside. So the home router would never know about the other 192.168 network and would just route it internally.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS

MVM

said by cmos100:

It's not a place holder and it shouldn't effect someone using the same subnet behind a firewall/router on a cable modem. Those IP's in that subnet would be converted to the public IP by nat before it hits the cable modem. The router on a cable modem just uses a default route and doesn't learn routes coming from the outside. So the home router would never know about the other 192.168 network and would just route it internally.

Most Soho NAT routers I have used have an internal routing table, and route packets to the next gateway when they aren't "local":
Tracing route to 192.168.14.129 over a maximum of 30 hops
 
  1     1 ms    <1 ms    <1 ms  Chihiro [192.168.102.1]
  2    23 ms    26 ms    20 ms  173-228-7-1.dsl.static.sonic.net [173.228.7.1]
  3    23 ms    25 ms    23 ms  gig1-4.cr1.lsatca11.sonic.net [70.36.243.13]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6  ^C
 

Per the OP's trace route, 192.168.14.129 isn't "local" (i.e., isn't part of 192.168.9.0/24), so it is routed to the next gateway, and so forth.

I don't think this would be a problem, even for somebody operating their LAN in 192.168.14.0/24. If they tried to reach 192.168.14.n, where there is no host (device) at ".n", I would expect similar to the following result:
Tracing route to 192.168.102.199 over a maximum of 30 hops
 
  1  Akari.aosake.net [192.168.102.36]  reports: Destination host unreachable.
 
Trace complete.
 

That is consistent for the gateway device routing table:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
173.228.7.1     *               255.255.255.255 UH        0 0          0 eth0
192.168.102.0   *               255.255.255.0   U         0 0          0 br0
173.228.7.0     *               255.255.255.0   U         0 0          0 eth0
127.0.0.0       *               255.0.0.0       U         0 0          0 lo
default         173-228-7-1.dsl 0.0.0.0         UG        0 0          0 eth0
 

Basically, 192.168.14.128/25 (what the OP scanned; half of a "Class C") is only reachable from Cox customers in the 68.11.0.0/17 network segment; but not from outside of that network segment, or within 192.168.14.0/24.

More of a problem for Cox, if their customers shouldn't be seeing the stuff there.
iansltx
join:2007-02-19
Austin, TX

iansltx to exocet_cm

Member

to exocet_cm
Seems like there's a gentlemen's agreement among ISPs to use 10.0.0.0/8 for internal stuff (probably omitting 10.0.0.0/22 or thereabouts), leaving 192.168.0.0/16 for SOHO routers etc., as well as 172.16.0.0/12. All three are RFC 1918 space, but 192.168.x.x is the most likely to conflict with LAN-side gear. So while Cox doesn't have to not use it internally, it's a bad idea to do so from their perspective, particularly if those IPs hit servers that should be behind a NAT firewall anyway.

Also, I'm currently on a Cox connection on 98.175.204.0/22 and, while pings to .14.128+ are timing out and traceroutes stop resolving after 10 hops (9 of which are Cox), I'm making it that far, and ending up at 70.183.71.xxx before the trace goes dark. Probably not a good sign. I'd post traceroutes, but the connection I'm on is a bit overloaded so there's a lot of packet loss/high latency going on that would cloud the output.
Rakeesh
join:2011-10-30
Phoenix, AZ

2 edits

1 recommendation

Rakeesh

Member

I never really did understand why SOHO gear likes 192.168 address space. A 10.0.0.0/24 space is easier on the repeated typing, and I haven't seen any ISP's use it for any internal equipment.

That could be a carry over due to an old rule (see RFC 950) whose usage even post-dates CIDR that didn't allow zero's in any of the octets for subnet addresses, which some old equipment enforces (this rule never applied to IP addresses by the way.) You can turn on this rule in Cisco equipment by using the "no ip subnet-zero" command. People mostly started ignoring that rule once it became apparent that IP address exhaustion was a more pressing issue than potential occasional human confusion.

When I build networks in lab settings I always like to start with 10.0.0.0/24 networks for this reason. I leave SOHO gear at whatever the equipment comes configured default since it tends to be easier on configuration.

Annoyingly some like 192.168.1.0/24 and some like 192.168.0.0/24 (again probably a carry over from the no longer used zero subnet rule,) so when I come work on somebody's home network and their equipment is already non-functioning, I hate having to guess which one it will be when doing a static IP for troubleshooting.

It's funny the things we're doing to get around IP address exhaustion. It reminds me of when I would turn in my math homework with a bunch of little tiny scrawlings in the margins because when I was almost finished but I ran out of space on the page, I would start doing the remaining answers inside of the margins of the paper and with really small writing, which would eventually annoy the crap out of some of my teachers when they were grading it. The right thing to do would be to get another sheet of paper (read: migrate to IPv6) but I was just too lazy.
cmos100
join:2004-08-24
Lafayette, LA

1 recommendation

cmos100

Member

A large provider may have thousands of internal interfaces. Just like in a SOHO network it makes sense to have them using private IP addresses, to conserve IP's and it's more secure by not using public IP's that can be exposed the whole world. Once IPV6 hits things will change. One interesting thing about IPv6 is a windows box can not have a smaller subnet than a /64, so there will be huge subnets out there with trillions of IP's per subnet.

exocet_cm
Writing
Premium Member
join:2003-03-23
Brooklyn, NY

exocet_cm to Rakeesh

Premium Member

to Rakeesh
said by Rakeesh:

said by CoxTech1:

That' correct. These IP's are being used within the Cox network and not being used for routing across the public Internet.

Isn't that somewhat broken that I can hit an RFC1918 address from the other side of a non-RFC1918 router?

I mean yeah so long as it isn't being distributed via BGP it's probably within spec as far as IANA is concerned, but it's clearly breaking intranet functionality for at least one customer, who should otherwise be right to assume that the entire address space should be usable. Hell, what if some manufacturer of home network equipment wanted to troll Cox by making 192.168.14.0/24 its default network?

Besides, given that this is an RFC1918 address, I would think that whatever devices you put there aren't intended for public exposure, correct? If so, security best practices would tell me that these shouldn't be reachable by customers in any case.
said by exocet_cm:

So the 14.x IPs we are hitting are Cox's network?
I'll write a firewall rule to not allow that traffic outside of my gateway. :-\

I'd opt for route adjustment instead, but that's just my personal pref.

Route adjustment made. Back to using 192.168.14.x for one of my remote sites.

Optimus2357
Premium Member
join:2010-11-21
West Warwick, RI

1 recommendation

Optimus2357 to Rakeesh

Premium Member

to Rakeesh
Considering the majority of those that use IPv4 don't know what IPv4 is, I don't think "lazy" is the right word, more like historically aware. Look at the DTV transition, where they were almost putting awareness documents on the back of cereal boxes yet I saw a line of people at Walmart the day of the switch, trying to get boxes. Corporations have done a good job of interesting a less then educated public in technology, which causes problems in the long run I think. I call it the Ipad effect. I still wonder how providers will ease the transition over. ::fingers crossed::
Rakeesh
join:2011-10-30
Phoenix, AZ

2 edits

1 recommendation

Rakeesh

Member

said by Optimus2357:

Considering the majority of those that use IPv4 don't know what IPv4 is, I don't think "lazy" is the right word, more like historically aware. Look at the DTV transition, where they were almost putting awareness documents on the back of cereal boxes yet I saw a line of people at Walmart the day of the switch, trying to get boxes. Corporations have done a good job of interesting a less then educated public in technology, which causes problems in the long run I think. I call it the Ipad effect. I still wonder how providers will ease the transition over. ::fingers crossed::

The laziness isn't on the part of consumers, rather it is on the part of technology companies, governments, and ISP's. We could be doing more to push IPv6 faster, but nobody is really putting in much effort. Cox is certainly dragging their feet on it. The UK is really bad, their ISP's are starting to do carrier grade NAT on a large scale without even trying to do dual stack - there are third world countries doing a better job of IPv6 adoption than them.

I think consumer level adoption is mostly already there due to the devices that most people buy already being IPv6 compatible. If you use Linux or any version of Windows Vista and up, as well as pretty much any SOHO network gear made within the last 6 years, you are already IPv6 ready. So far I've only seen one consumer level push away from IPv6, and that comes from a few Alex Jones nutters who think that IPv6 is a plot by the illuminati, nwo, and cisco to take over the world. I'm not joking, you can't make this shit up:

»forum.prisonplanet.com/i ··· 200124.0

I like how they base the number of available IP addresses on how many of those addresses they can successfully ping.
quote:
As I said in an earlier post, I like how hardcore and bold the NWO is. A teeny fraction of the world's internet users use IPv6, and Cisco and the other globalist cyber false-flagger corporations believe all of the world's sheeple will just ease into the new global cattle pen with no resistance.

IPv6 must be resisted.
lawl

Optimus2357
Premium Member
join:2010-11-21
West Warwick, RI

1 recommendation

Optimus2357

Premium Member

I think the technology companies are doing a good job, as most consumer equipment have been IPv6 compatible for a couple years now. Not sure what you mean by Government, but I want them old tarts to stay as far away from tech laws as possible. Yes, most providers could be doing better with implementation, but what do you suggest is the best method? How do you see the IPv6 switch going down that is best for the consumer?
Rakeesh
join:2011-10-30
Phoenix, AZ

1 recommendation

Rakeesh

Member

said by Optimus2357:

I think the technology companies are doing a good job, as most consumer equipment have been IPv6 compatible for a couple years now. Not sure what you mean by Government, but I want them old tarts to stay as far away from tech laws as possible. Yes, most providers could be doing better with implementation, but what do you suggest is the best method? How do you see the IPv6 switch going down that is best for the consumer?

When I say governments, I mean government services. The US government is actually one of the few who has IPv6 covered, shockingly considering how bad our politicians are at understanding the internet, but numerous other governments are not.

Tech companies would include some companies who produce IP enabled devices (e.g. webcams, dvd players) that aren't IPv6 compatible. Vanilla LTE implementation for example is not IPv6 compatible. Strange right? Because LTE is IP based. How on earth did they miss that one? Who knows. As far as I'm aware Verizon and Tmo are the only carriers forcing IPv6 on their LTE networks.

And then of course ISP's such as Cox who haven't even implemented IPv6 at all.

caedmon
@suddenlink.net

caedmon to exocet_cm

Anon

to exocet_cm
To get back to the original post. Why was your traffic even hitting the Cox network? Normally Cox doesn't advertise
subnets to end users. So the only way your traffic should interact with the Cox network is if you did not have a route to
192.168.14.0 and the router uses the default route provided by Cox. Your router should be clueless about any Cox addresses
except the address it receives from Cox through the modem, the default route which points back to an address on the Cox network and any routes you manually add. If 192.168.14.0 is not directly connected to your router then the route you added should not point to the Cox network and everything works well. This is how the 182.168.x.x addresses are supposed to work. You should be able to use every 192.168.x. class c on your local network without problem.

Could you explain what I am missing?
Rakeesh
join:2011-10-30
Phoenix, AZ

1 edit

Rakeesh

Member

The way routing works in this scenario is this: Say his local network is 192.168.1.0/24 and he needs to reach 192.168.14.129. The IP software stack looks at the IP address and notices that bits outside of the range of his network (as specified by the /24 subnet mask) are different so it sends that packet to the MAC address belonging to the default gateway (router).

The router looks at the packet and first checks if it knows of any networks that this IP address would fit in (it looks in its routing table for a network address/subnet mask combination that match) and if it doesn't find a match, then it blindly sends it out the interface that leads to what we call the gateway of last resort, usually listed in the routing table as 0.0.0.0/0. (You can always think of the gateway of last resort as "I don't know where this packet goes, so I'm just handing it to you.")

In this case, the switch port (which is soft configured to be a regular ethernet interface as this is actually a layer 3 switch) going to your cable modem is where it sends it, therefore 192.168.14.129 bound packets go to his first hop router at Cox instead of inside of his local network.