Using RFC 1918 IP Addresses on Internal Routers?

braek asks: "Our network has expanded to the point that I have about 6 separate network links to remote networks. I would like to avoid using public IP addresses for the routers to conserve my limited global IP addresses, and I don't expect any additional IP's for a while. :( What do you guys think about assigning internal routers a private, RFC 1918 IP address, like 10.0.0.1 or something? (For security, RFC 1918 addressess would be filtered at the border routers.)"

"I am testing this right now, and routing seems to work fine, the only problem I can think of, is when someone does a traceroute, it will show up like:

10   120 ms   131 ms   120 ms  152.63.67.97
11   130 ms   130 ms   131 ms  66.141.21.1
12     *        *        *     Request timed out.
13   130 ms   130 ms   140 ms  66.141.21.185

Hop 12 is the router with the private RFC 1918 address, and I am assuming it is not responding to a traceroute because the IP is not globally routable. However, all the clients behind the router have complete, unabashed network access. What problems may one encounter if implementing this kind of addressing scheme?"

Comments

As long as you have just plain connections

[Tairan]

it should be fine. You wont need Inet access on these lines - just plain point to point leased line from your telco. My previous company used to do this. Many other large companies still do. Basically, they provide you with the equivilant to a really long patch cable. I'd suggest setting up all your branch offices to point to a single master office, where your bridge/gateway for inet access is. That way you can filter/proxy/monitor/whatever you want, and still have a secure network

We do this...

[john@iastate.edu]

One thing to note is if you are using DHCP the forwarded packets will have the 10.x.x.x address (assuming that is the primary address of the router interface).

You'll just need to use the 'shared network' statement (or equivalent if you are not using ISC's dhcpd) to take care of this.

This is asking for trouble (ICMP and stuff)

[bkw]

Since most routers (should!) drop packets from or to non-routable address-space, you might run into problems with MTU-discovery and the like, which are a real bitch to debug. Also things like ECN may break. Somebody's public transfernets in private ip-space gave me headaches more often than not, which is already too much.

I'd advise to choose clever subnetting and NATing of your available space, it will save you and the rest of the net lots of pain, although private space might seem to work smoothly at first. The problems will show up when you least need them, but they will.

Re:Can and Must

[ryanmoffett]

Not quite. Let's say you compromise a host on the 10/8 network. If it attempts to make an outbound TCP connection to an IRC server, the IRC server will not be able to respond back to the 10/8 host because RFC1918 routes are going to be filtered at some point back to the client and the TCP 3-way handshake won't even complete. UDP attacks in one direction from the client to the public would be possible, but the RFC1918 source address would most likely be caught by an ingress filter at the remote end.

Now, most likely, that 10/8 host gets NAT'd to a public address through a firewall. In this case, the IRC scenario is not only possible, but a real tactic used to get past firewalls. Some, firewalls such as the Cisco PIX make it easy to not care about your outbound traffic, so a client making outbound connections to IRC servers isn't necessary going to even be noticed. This is why you have to implement egress filtering on your firewalls and/or routers to block what your users have access to should they ever get trojaned.

Hmm..

[_ganja_]

There isn't really a problem with what you are doing, the only thing I don't really like about doing this is the management aspects when the implimentation gets a little large. More on that in a bit but first, technically, the golden rule here is as long as these addresses are of course unique and stay in your own AS you'd be fine, I'd personally go one further and would keep them only in your IGP just to be safe in case someone screws your bgp filters etc.

I'm a CCIE and been networking 11 years now, 6 with Cisco and I'd only do this is if I really had too and here's why: management of address space. I'm sure (hope) your management of all your public address space is organised and clear. Furthermore nobody would dream of adding a box to the network with a public address without asking you or another admin who would assign one, which case you would go to your speadsheet (or QIP / another tool), allocate one and record the details. With private address space people tend to just add boxes and subnets and pick an address from random out of the air. This is where time consuming issues come about with overlapping address space. If your network is going to stay small and you have full control over all the addresses then you shouldn't have much of a problem but if the network is going to grow a larger, think about the extra admin you might have to do and also if you were to be hit by a bus would the next guy understand it.

You have some cisco semi-hacks to help you out also such as unnumbered links and also note /31 subnets are available in newer IOS revisions. At the end of the day I don't know how large you're network and it's exact design, its your choice at the end of the day, just make sure it won't bite you in the ass in the future.

1918 addressing and when it should be used..

[gkuchera]

The whole purpose of the RFC 1918 "private networks" was to allow companies to connect to the internet without having to have a "registered" ip address for every machine on there network. It was also implemented to help prevent people from grabbing random addresses like 3.0.0.0 and using them for there internal addresses.

Companies will then use the private addresses on there internal networks. This concerves the public addresses for the direct addressing on the internet.

Routers will route anything that they are not speciffically told not to. The general consensis is that you should not route private addresses past your border routers (ie to the outside world). Likewise you can't expect that anyone will be able to get to your machine if it have a private address. ie. 10.1.1.1.

The only people that expressly don't route private addressing are the core internet people. This is done usually done by filtering out these addresses at the edge of each of the large internet providers. Typical firewalls will filter out private addressing as well.

Don't assume just because you are using the private addressing on your network that you are safe. This is simply not true. Generally if you are using private addressing on your internal network there is a router or firewall between you that converts your private address into a registered one(NAT). Someone that is paying attention at this point will figure out that if the core providers filter out the private addresses and if I am on a machine with a private address that I won't be able to go very far on the net(unless there is a address translation inbetween).

There are several ways that NAT's can be assigned one is dynamic (more secure) and one is static. I assure you that if your machine has a statically assigned NAT address and there is no firewall between you and the net that your machine might as well be on the net directly.

Subject: Should isp's use private addressing? Well this is a hard question to answer. If they have a office lan that is behind a firewall that very well could be privatly addressed...

Should they use private addresses on interlink segments. Personally I say no because I really hate it when traceroutes don't return addresses. Although if you want to hide a couple of routers or firewalls in your path it's not a horrible way to do it.

Private networks and security: The only security that private networks provide you is this. If the people that are trying to hack into you are beyond a firewall or provider that filters private networks your are safe until they break into a machine on your network that has registered addresses. Then they have as much access as you network will allow. (note that alot of times this machine may be on your network beyond your defences.

Finally: before you decide to inplement large networks that use private addressing you need to think about who you may be connecting to yourself. On a network each machine must have a unique address for life to be happy. If you have a several thousand host network addressed in the 10.0.0.0 range and your company buys another company that alsi uses the 10.0.0.0 range of addressing life can get very very complicated. I know this from experience.

my two cents... I hope this makes sence.
-Geoff Kuchera

Trace will show RFC1918 if YOUR ISP uses it...

[Bob_Robertson]

RFC1918 addresses will show up any time your ISP uses it.

RFC1918 source/destination packets are dropped at the *edge* routers, not "every" router. By edge I mean AS-Number borders, my experience is that anyone with the technical know-how and need for their own AS-number also usually knows to filter those packets to and from their BGP peers and default providers.

Yes, to and from. For laughs I used to put logging on the border routers, to catch packets to/from RFC1918 addresses, as well as BGP advertizements of RFC1918 address blocks. It was amazing the otherwise reputable ISP's and major companies who forgot to filter those things out! Lets just say that it was one reason for my buying my first AMD chip!

Bob-

Re:I've done this

[jismay]

Don't even bother fooling around with the scheduler. Just make a .bat file that adds the static route (or does anything you want!) and put it in the startup group. Start->startup->*.bat. Nice and simple, with no fuss or muss.

Re:Only one issue

[matts.nu]

BGP4 has nothing to do with dropping rfc1918 source addresses. BGP4 is used for routing on destination address only, not source address. As the above traceroute showed packets from 10/8 are routed just fine.

For the original poster, you don't need to filter packets with rfc1918 source addresses.

Re:I've done this

[doon]

C:\>route -?

Is your friend, look at the -p option which will make the route persistant accross boots of the system. Doesn't work win Win95 though

so a route -p add should solve your problem nicely :)

RFC1918 on Internet Routers == BAD BAD BAD

[marius]

This comes up on NANOG's mailing list about once a week. Search the archives.

The most important thing it breaks is PMTU discovery, which may cause stalls in your IP transmissions through that router.

Static Nat

[eufaula]

I wont get into the pros/cons of using these addresses (as that is covered enough on the nanog.org list). but, you can statically nat the addresses so they are translated into a routeable address.

this is how you do it on a cisco on your WAN router. (assuming that you know to configure it):

ip nat inside source static 10.x.x.x 12.34.56.78

now you have a static where internally 10.x.x.x is the ip of the router, but the outside world can see it as 12.34.56.78

a quick google search brought up this -- http://www.cisco.com/warp/public/556/9.html