At my current job, we distribute a product based on a Linux server with multiple VMs defined (using KVM / libvirt). We are planning to expose limited ports to the customer's network, and use iptables to direct inbound traffic to the appropriate internal VM. My question: is there a class of private subnets that I can use for the internal host-only network that is least likely to conflict with a client IP subnet? Specifically, if I choose a /24 out of any of the RFC-1918 defined private subnets (such as 192.168.x.x), there is a chance of conflicting with a customer-used range.

I noticed that several current VM implementations default to 192.168.122.x -- is this due to an RFC that I'm not familiar with, and therefore this is a safe range to use (that most network admins would avoid)? Or did the various VM vendors just pick that range randomly? I guess I'm looking for an IP range that is more private than the existing private (RFC1918) addresses.

The only other thought I had was to use one of the "Test Net" IP ranges reserved for documentation purposes (RFC 5737). Note, that I'm not worried about a customer's network blocking these IPs, as this is only internal to our server (packets get NATted before leaving the box). However this does seem more unorthodox than just sticking with the default 192.168.122.x/24 subnet.


My advice would be to just make this configurable by the customer. Expose it as part of the install script, and then have something to reconfig all the VMs inside, nice and tidy. Or send a tech out every time you do a new install - I'd use a script if I were you.

If you, as a vendor, told me that your device was hard-coded to use a network that I was already using, I'd be some-mighty pissed.

OK - in short, there's no IP space that you can use that will guarantee you won't overlap or otherwise impact a client network, short of using a public IP range that you actually own (and don't use), which is unlikely. Anything you can think of that's supposed to be reserved? Some bright light may already be using that on their own network, because they thought the same thing! Or some other vendor that they're using thought the same thing! You can either try a lot of techniques that will cause the least breakage, or you can do it right, which is allowing the customer to do their own IP config. You could make it default to the one you want to use and assume that most of the time it won't break anything, sure, which is the situation you're heading towards anyway.

  • Our installs are already highly customized, and we pre-configure the server's external IP based on the customer's requirements document. I thought about adding the internal IP range to the requirements doc, but many of our customers aren't sophisticated enough for that to make sense to them (and internal policies dictate a many month lead time for any documentation updates such as this -- we are in a highly regulated industry). Was hoping that this would be an easy way out. – Derek Pressnall Nov 26 '12 at 4:54
  • Edited my answer. – mfinni Nov 28 '12 at 18:21

What's wrong with a totally different private space for internal? For clients I use example and others I will assign some other 10 space subnet. I could be misreading what you are looking for but there would be no reason not to assign something like that.

  • That is what I'm trying to do, is have an internal address space that is guaranteed to not conflict with whatever the customer has for their site -- for example, if I use, and the customer has that range assigned to some of their workstations, those workstations won't be able to communicate with our app. And I don't mind assigning a different range internally if there is a conflict, I'm just looking for a good default range that would minimize the chance of conflict. Hence, one idea was to use one of the RFC 5737 "Test" addresses. – Derek Pressnall Nov 26 '12 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.