Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

ISP's Routing Private Addresses?

By byte in Technology
Sun Nov 12, 2000 at 04:39:47 AM EST
Tags: Internet (all tags)

While working on my Red Hat IP_MASQ box this weekend I was shocked to discover that my ISP, a large cable modem access provider, is apparently forwarding private network numbers across their networks. Is this common? Doesn't this fly in the face of RFC 1918? How many other ISP's do this? And are there any security issues associated with forwarding private address IP packets?

Earlier this week I renumbered my home network from 192.168.0.x to 10.x.x.x due mostly to my new company using the former address space for their internal networks. I was trying to get a VPN client to work at the time and figured that I'd have better luck using the 10.x.x.x network for home rather then trying to get the VPN client to work with the 192.168.x.x network. So afterwards I simply thought my ping replies from were just some rogue box still on my network that I had forgotten to change. However, a traceroute from the IP_MASQ box just deepened my concerns.


traceroute to (, 30 hops max, 38 byte packets

1 ( 32.456 ms 12.499 ms 10.893 ms
2 bb1-fe0-0-100bt.rdc1.sfba.home.net ( 9.277 ms 23.973 ms 11.117 ms
3 c2-pos6-1.snjsca1.home.net ( 9.627 ms 10.839 ms 9.978 ms
4 ( 10.402 ms 9.371 ms 16.897 ms
5 ( 25.644 ms 26.784 ms 25.380 ms
6 bb1-pos2-3.rdc1.bc.home.net ( 30.024 ms 28.766 ms 31.057 ms
7 ( 30.443 ms 28.734 ms 30.255 ms
8 ( 43.649 ms ( 35.896 ms 45.543 ms

This was pretty much the last thing I expected to see. According to the trace, traffic is moving over all three of the reserved private network spaces. Now I realize that it's pretty common practice these days to use private address spaces behind a NAT box (I'm doing it myself both at work and at home) but I was not aware that ISPs were doing this too. My concern is as to if this is good practice on the part of the ISP and if using private addresses within the ISP's transport networks is a good idea. I admit that off the top of my head I can't see any reason to be concerned but then again I don't consider myself the expert on routing issues. When I brought these concerns to my ISP all I got from the technical support staff was:

1) You're in violation of the AUP
2) We have no security issues
3) If you continue to ask us about these issues we'll terminate your service

I've actually been pretty happy with the service and want to make it very clear that I'm not just some disgruntled customer. Quite the opposite; I'm impressed with the performance of the cable box and would definitely recommend the service to friends, etc. I was pretty surprised by their response and can't for the life of me understand why they seemed so hostile towards my questions. But I still would like some answers to my questions and if not from the ISP perhaps from K5. Is it OK to route private addresses across even a small part of the Internet?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Is it good practice for ISPs to Use Private Address Space?
o Yes, what are you complaining about? 17%
o No, these guys should be shot on sight! 42%
o Why are you bothering me? 5%
o Stop touching me! 35%

Votes: 57
Results | Other Polls

Related Links
o Also by byte

Display: Sort:
ISP's Routing Private Addresses? | 21 comments (20 topical, 1 editorial, 0 hidden)
The typical 'we have no problems' answer (2.85 / 7) (#1)
by General_Corto on Sat Nov 11, 2000 at 11:29:24 PM EST

It seems that your ISP is taking the approach of "if we don't let people do a certain thing, then we can be less security-conscious without them knowing," which is never a Good Thing. I'm fortunate - the ISP I go through (ADSL) is *very* nice about things like this, and they don't really care about what you do behind the IP address you've been assigned... in fact, they'll even help with configuration issues that involve networks.

I'm spying on... you!
10.x.x.x is a common practice; plus notes. (4.11 / 9) (#2)
by Christopher Thomas on Sun Nov 12, 2000 at 12:57:34 AM EST

Using the 10.x.x.x address space seems to be a common practice; my own connectivity supplier does this too (though they were more polite when I asked them about it).

It turns out that their modem has two addresses - one is its standard IP, which is visible to the outside world, and one is a class A subnet address, which the ISP uses to address it when they need to tinker with its configuration remotely.

I don't really see a problem with this, as it's all outside my firewall anyways, but I can see how it might be a hassle if I was trying to route to external class A IPs across a VPN. The solution to that is just to set up your routing table carefully (accepting/using class A IPs only from/with the VPN virtual network device).

Were I in your position, I'd probably just use one of the other class C ranges (192.168.[1-255].x) if I was sure the company wasn't going to expand its range, or one of the class B ranges (172.[16-31].x.y) if not.

BTW - the VPN software we used at my old workplace (vpnd et. al.) had trouble routing through 192.168.0.x; use a number other than 0 to avoid hassles (this is a "feature" of the VPN software, which probably has a legitimate purpose that I don't remember offhand).

Lastly, the terms of service of all of the 'net providers around here explicitly prohibit both servers and NATs on the receiving end. If you rub it in their face that you have one, they'll _have_ to threaten you. It's pretty much a "don't ask, don't tell" scenario up here (Toronto, Canada).

I simply neglected to mention that the Linux box I was trying to connect was a masquerading firewall.

DOCSIS requires this. (3.66 / 6) (#3)
by enterfornone on Sun Nov 12, 2000 at 01:06:02 AM EST

The DOCSIS standard requires that the modem has it's own IP address. For the ISP I'm familiar with, and most other I beleive, you will get a 10.* address for the modem and a public address for the NIC the modem is connected to. The 10.* addresses will not be routed on the Internet, just on the ISPs network.

efn 26/m/syd
Will sponsor new accounts for porn.
Sounds like you are both misconfigured. (4.63 / 11) (#4)
by bgalehouse on Sun Nov 12, 2000 at 01:21:41 AM EST

When configuring a natting firewall, you should refuse any incoming packets from private addresses, and should ensure that none escape into the wild.

It is, of course, good to do this packet blocking also at the ISP router. That they don't is bad security. But it is only affects you if your firewall is has a poor ruleset. So go fix it :-)

Letting private address packets escape your firewall probably is against your AUP. I haven't heard of anyone trying to forbid natting, but I suppose that it is only a matter of time before somebody does.

Absolutely Correct (4.00 / 3) (#9)
by byte on Sun Nov 12, 2000 at 05:01:54 PM EST

No disagreements here, I should tighten the firewall's ruleset to prevent this kind of thing in the future. While I still believe that the ISP does have some responsibility to investigate security issues the primary responsibility for my system's security lies with me. Not using a strong ruleset on the firewall is a attack/hack waiting to happen and I can't really blame anyone but myself if I don't take appropriate steps to reduce the chances.

[ Parent ]
doesn't look unusual (3.50 / 6) (#6)
by h2odragon on Sun Nov 12, 2000 at 02:20:39 AM EST

My upstream uses 10.x addresses in various places across their network, but they filter at their upstream (they say). The fact that I can see their private address space and speak to their routers worries them, in this case, because I know more than they do. :)

Their philosophy seems to be (and I agree, really), that it's not worth too much trouble to filter from their customers, because anyone who misuses that "trust" can be tracked down fairly easily.

Your provider's response to your concerns is extreme. If they're using RFC1918 space in their networks and care about customer usage of those numbers they're responsible for firewalls or whatever's needed, just like they'd do for their own public address spaces. Your "large cable provider" is known to me through an attempt to help another of their customers to be far above par in responses to security concerns. Perhaps that's a local thing or they've become more laid back in the past year.

Two things (4.00 / 4) (#7)
by sbeitzel on Sun Nov 12, 2000 at 03:07:15 AM EST

Thing 1: your exposition is a little confusing. After thinking about this for a little while, I have to agree that it all seems weird. If I'm running several boxes with dual NICs such that I've got three networks, where network A is the Internet, network B is 10.*, and network C is 192.168.*, and that the gateways are laid out so that there is a machine bgw that bridges A and B, and cgw that bridges B and C, I would not expect a machine on the C network to be able to ping any machine on the B network other than bgw. If there is some node on B other than bgw which is pingable by a node (other than cgw) on the C network, then either the router implementation is incorrect or my understanding of the specification is incorrect. I'd be happy to receive enlightenment upon this point.

Thing 2: when you bring up the question of security issues, about what are you asking, exactly? True, one doesn't really expect to have packets forwarded to a 10.* or 192.168.* address, but is it your router/firewall that's busted? Your security is your own lookout, and although I (and the world at large, I'm sure) appreciate your concern, please understand that the security of your neighbor's system is outside your responsibility.

Routing settings, etc. (3.00 / 1) (#8)
by byte on Sun Nov 12, 2000 at 04:56:36 PM EST

The routing coonfiguration is pretty simple, basically one default route out to my ISP and that's it. In this configuration the router will pass any traffic not designated for the internal 10.x.x.x network out to the external interface, private addresses and all. Never thought to block them as my understanding was that ISPs drop packets destined for private networks. Looks like my understanding was obviously in error.

As to the security issues, quite frankly I can't see any problems with the ISP setting things up this way but again I do not profess to be the expert on routing issues. I know the ISP had some problems a year or so ago with a customer running RIP and my guess is that it was due to both the customer and the ISP using the same addresses on their networks. As I said, I'm interested to know what everyone else thinks just in case I'm missing something here.

[ Parent ]

Just to clarify the security issue... (2.00 / 1) (#11)
by bgalehouse on Sun Nov 12, 2000 at 08:54:05 PM EST

If you are assigning private IPs, you get the disadvantage of nobody being able to initiate connections to them. The advantages are fewer purchased IPs and higher security - if they cannot address a packet to you, they cannot mount an active attack against you.

So, leaving your firewall open to privately addressed packets simply looses one of the advantages. If you had a network of default config openbsd boxen, letting the packets in would probably have a pretty small effect on the overall level of security.

Basically, it is no worse than running without a firewall. On the other hand, if you have a buch of PCs with netbios ports, or a vpn server that forwards things when the IP header matches certain subnets, you might not like the idea of running without a firewall.

Letting them out is impolite, and perhaps against AUP. But it is only unsafe in that you might piss somebody off.

If the ISP routers have private addresses for internal routing, that is fine. But it makes it even more valuable for them to filter privatly addressed packets coming from customer machines. Depending on their topology, this might require extra hardware, so they may have something of an excuse.

[ Parent ]

upstream backbone == private network (3.00 / 1) (#10)
by eann on Sun Nov 12, 2000 at 06:04:37 PM EST

Just because it's what lowly users like us consider to be "backbone" doesn't mean it's still not somebody's private network. When you consider the number of nodes and interconnections, they probably save a fairly hefty pile of "legitimate" addresses that they can then sell to customers instead of writing off as network overhead. The routing tables are the same either way, and it's a hell of a lot cheaper than trying to switch the entire world to IPv6.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.

But private IP's shouldn't be routed. (4.25 / 4) (#13)
by Phil Gregory on Mon Nov 13, 2000 at 12:30:53 AM EST

As per RFC 1918 (Address Allocation for Private Internets),
Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error.

If the ISPs are using private IP addresses, they should protect them from the public IP address space.

--Phil (Fortunately, my firewall does. I do get to read the logs that show how many other people don't.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
[ Parent ]
Bah! (2.00 / 2) (#14)
by eann on Mon Nov 13, 2000 at 01:28:14 PM EST

If companies adhered to the letter of every RFC, then we'd all have secure web browsers that worked and we'd hardly ever have to think about spam. What fun would that be?

The routers must route the private addresses, otherwise they wouldn't be able to route to each other. Could/should they be configured so that customers aren't allowed to pass private stuff through? Probably. On the other hand, it brings into question what the scope of the "private network" actually is. If the customers aren't multi-homed, one could make a reasonable case that it includes them.

Is it most likely just greed and/or laziness on the part of the backbone company? Yeah, but that's not a problem for me. The only real danger I see is with security (How do you hunt down a skript kiddie at, but I make it a general rule not to trust upstream providers for that.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.

[ Parent ]
Justifications for IPv6 (none / 0) (#21)
by Xenophon Fenderson, the Carbon(d)ated on Tue Nov 14, 2000 at 09:58:36 AM EST

Network address translation is, at best, a stop-gap measure. In the long term, it will do Bad Things to your network (e.g. I/O bottlenecks) and to the people who must maintain your network (e.g. renumbering). For a well-written paper enumerating business and technical reasons for adopting IPv6, see The Case for IPv6 by King, et al.

Sorry to jump all over you, but IPv6 is coming, and in my mind, the cost of adoption is much less expensive (in the long run) than maintaining the current patchwork of NATs and non-hierarchical routes.

Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, mhm21x16, and the Patron Saint of All Things Plastic fnord
I'm proud of my Northern Tibetian heritage!
[ Parent ]
I see this all the time. (4.85 / 7) (#12)
by Inoshiro on Sun Nov 12, 2000 at 09:22:59 PM EST

I have ipchains deny and log all incoming packets from reserved networks on the internet side of my firewall. I often see what look to be requests from misconfigured NAT boxes which don't really NAT so much as packet forward. Blind packet forwarding is, of course, a huge security hole that leads to people being able to easily get past your firewall and inject packets into your (supposedly safe) LAN.

The best solution is to just add proper ingress rules for restricted networks, and have proper egress rules for outgoing packets:

ipchains -A input -p all -j DENY -l -s -i eth1
ipchains -A input -p all -j DENY -l -s -i eth1
ipchains -A input -p all -j DENY -l -s -i eth1
ipchains -A input -p all -j DENY -l -s -i eth1
ipchains -A input -p all -j DENY -l -s -i eth1
ipchains -A output -p all -j DENY -l -d -i eth1

(Note: eth1 in that example is the internet side. The output rule should also be adjusted for the correct subnet mask )

[ イノシロ ]
Good suggestion! (2.00 / 1) (#20)
by byte on Tue Nov 14, 2000 at 03:09:20 AM EST

Implemented this 5 min ago. Thanks for the tip!

[ Parent ]
There is *NO* problem here. (3.00 / 1) (#15)
by mindstrm on Mon Nov 13, 2000 at 01:46:07 PM EST

Your ISP is free to route 10.x (or *anything else*) within it's own network, for whatever reasons and in whatever way it wants.

The fact that it's reserved simply means that you can NOT expect your IPS to route them for you. No inter-network routing of reserved address space.

The problem here is that your firewall is forwarding these packets to their gateway. Why is it doing this? You described trying to set up a VPN.. and that will work just fine, but to do that, this stuff should be tunneled.

It looks to me like you are trying to route reserved traffic from your network into your isp's network, and finding that, instead of blocking it, they are also using that network.

This is not a misconfiguration on their part, it is a misconfiguration on yours.

Hummmm.... (4.00 / 1) (#18)
by byte on Tue Nov 14, 2000 at 02:02:48 AM EST

Personally I could care less if my ISP uses private network addresses for transport segments of their network. I was more surprised at what I saw and the response from my ISP when I asked them about it then anything else. As I stated, I wondered if this use of private addresses was kosher and if there were any security issues associated with doing this. The consensus seems to be that there aren't any security issues associated with doing this so I'm satisfied. :-)

As to the firewall settings, yeah, I need to tighten them. Frankly I never even imagined I would need to block private addresses; I was not aware at the time that the ISP was using them. The reason I discovered this was because I was trying to reach a host via VPN that by coincidence was also reachable on the ISPs network. I didn't have the kernel configured for VPN support (didn't know then that I needed to) and just happened to PING a private address host while testing the VPN link (confused the hell out of me at the time as I thought the VPN tunnel was working). Oh well, live and learn.

[ Parent ]

As a matter of interest ? (3.00 / 1) (#16)
by Simon Kinahan on Mon Nov 13, 2000 at 05:58:53 PM EST

Did your ISP say just what you did that was in violation of your AUP ? I'm generally interested in people's experieces with this, as I do a couple of things which, whilst not against my ISP's AUP, could give them an excuse to terminate my service if they wanted to.


If you disagree, post, don't moderate
Nope (4.00 / 1) (#17)
by byte on Tue Nov 14, 2000 at 01:32:16 AM EST

They were actually pretty vague on exactly how I was in violation of the AUP. I specifically asked to for the verbage that prohibited me from running a NATed network off the cable modem and never received a decent reply. The customer service agent I chatted with did state that I should purchase an additional IP address for each system attached to the cable modem but I could not find anything in the AUP that manadated this. Go figure.

[ Parent ]
routers (3.00 / 1) (#19)
by rtscts on Tue Nov 14, 2000 at 02:20:43 AM EST

if it hasn't been mentioned already....

routers often use private IP's for themselves, they do not normally need to communicate with hosts outside their owners network (they just forward packets, they really don't need an IP for themselves very often), so using a public address for every router will waste IPs.

Normally. When you do a traceroute, you are using a rather nifty little trick involving the TTL (time to live) field of packets (you can find out the details of traceroute for yourself).

When a packet expires at a router, that router will send you an ICMP message saying the packet has died - this packet will come from the router's private address. At no other time will a router ever need to communicate with you using it's own address.

So to solve this problem, tell your firewall to accept ICMP traffic from private addresses, and deny packets of all other protocols from private addresses.

don't worry. i know exactly what i'm d@#^(!#NO CARRIER
ISP's Routing Private Addresses? | 21 comments (20 topical, 1 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!