Flexible topology for RFC 1918 addressing

Hi,

I use 10/8 addresses, here. But, damn near everything I bring into the house arrives on 192.168/16 or 172.16/12. So, it's usually annoying to get it to "play nice".

Compounding this is my desire to usually isolate "foreign" devices until I have had a chance to evaluate their actions/behaviors (malevolence, etc.).

[I often have to "fix" computers that friends have had infected with malware, etc.]

Typically, I use a "disposable" laptop (i.e., one whose contents are not precious and that can quickly be restored with minimal effort) to talk to these devices on a "two device network" (the DUT and the laptop).

This is tedious (at the very least, I have to drag out the laptop and find a place to work on *both* devices -- because I don't normally use laptops, here).

Other suggestions as to how to tackle this with devices that are ALREADY IN USE but while still handling the 1918 differences *and* the desire to isolate and keep the DUT "incommunicado"? I'm leaning towards setting up a small "testing subnet" with its own DHCP server behind a separate router, etc.

Reply to
Don Y
Loading thread data ...

yeah, unless you can put one of the ports on your existing router on a different subnet that;s a good way to do it.

--
umop apisdn
Reply to
Jasen Betts

The testing subnet idea seems appropriate. You'd ideally have a Faraday cage room so the foreigner doesn't latch onto your neighbor's open WiFi...

The RFC for that non-routing 172. region allows a bunch of subnets outside 172.16..., you might consider putting up a DHCP-host that serves out 172.22... with an empty or nearly-empty DNS service. It's not a total jail, but your 172.16... router won't open doors for the suspect.

Reply to
whit3rd

Actually, I hadn't considered that! :< Usually, you can shut the wireless off (BIOS or a dedicated button, somewhere).

Most of the annoying devices are the *appliances*. Things that don't talk DHCP or that have been preconfigured to a particular IP address. I don't want them "dialing out"; nor do I want them poking at my devices.

This has been the appeal of the "two node network" -- the only device that they can poke at has no real value and can quickly be restored.

I'd have to serve up addresses throughout the 1918 region -- including

10/8! -- as I have no idea what the device in question wants to claim for its own use (or, if it wants to be *served* an address. This complicates trying to use "existing devices" (here) as they already have punched holes in the address space. [The laptop approach defers that decision -- TO ME -- until the last moment. Which also means I have to deal with it explicitly (instead of being able to fall back on an "accommodating infrastructure")]

Maybe I should just change one of these "existing" (normally "in use") boxes to dual boot to a benign configuration -- i.e., act *as* the laptop would -- and sidestep the whole issue?

Reply to
Don Y

I still have to ensure that the *existing*/in-use ports don't conflict with whatever the DUT decides it needs/wants. I.e., the best approach might be to masquerade as a different IP on the subnet used by the DUT so that I am "sure" the address of the machine at which I am operating doesn't BY CHANCE conflict with whatever the DUT is using.

[I've brought home servers that were also on 10/8 and had to think twice each time I referenced one of their addresses: "Hmmmm... No, just because I'm typing 10.x.x.x and that happens to coincide with MrWhoopee's address, I should not be expecting *MrWhoopee* to reply! He's not even *on* this two node network!" Sometimes, familiarity leads to confusion/bad assumptions!]
Reply to
Don Y

DHCP much?

So don't put those on any network.

Should work.

--
Les Cargill
Reply to
Les Cargill

Actually, most of my hosts have static IP's -- so I can access them if the name/bootp/DHCP server is down. No fun trying to telnet to a headless box that is waiting for an IP lease!

Then you can't see what they are talking to (or, *trying* to talk to), etc.

It's not quite that easy. The DUT can opt to pick the IP that the machine I am currently *using* has allocated to it (static or DHCP lease... the other machine may have a static IP!).

The "laptop + DUT" approach allows me to defer picking an IP for the laptop until I can see what sort of IP the DUT has (or, is *awaiting*). I.e., I don't see a COTS solution being flexible enough for this.

So, at the very least, NATd in the router and a script to scan the address space for the DUT, try to serve a DHCP lease, etc. -- *then* make the decision as to what my "existing" box should masquerade as in order to coexist with the DUT.

(sigh) EVERYTHING should be designed to fall back to DHCP/bootp. And,

*easily*. But, that's not the case.
Reply to
Don Y

Everything is designed to fall back to a static IP. We will never quite trust this stuff, I don't think.

bootp specifically is a disaster - I've seen it not-work when you substituted a modern switch for a '90s *hub*.

--
Les Cargill
Reply to
Les Cargill

You can't come up with "default" static IPs for every device manufactured (what happens when you own *two* of the same make/model).

OTOH, falling back to DHCP (or any protocol that allows IP's to be allocated from a pool) *at least* ensures connectivity (even if "discovery" becomes an issue).

This avoids the issue of manufacturers having to pick a (seemingly random) default IP out of the air and assign it to *every* model XYZ device they produce (kicking the problem into the customer's lap)

Any broadcast protocol is potentially flakey. I ran BOOTP for my X terminals for probably a decade on 10Base2, then 10BaseT, then 100BaseTX. But, my networks are relatively quiescent and static so you don't have lots of broadcast traffic (from other protocols), etc.

Reply to
Don Y

So don't do that :) I did not personally make everything fall back to a static IP ( which is usually configurable ) but I've observed that this is largely what happens.

... but it may also brick the device for use with Ethernet. I don't know if RARP ( reverse ARP ) still exists or not.

--
Les Cargill
Reply to
Les Cargill

Manufacturers need to have *some* default. Do you pick *one* address for all "ethernet devices" (regardless of device manufacturer, model, etc.)? This makes it simple -- in some sense -- as any new device *will* "reset" to A.B.C.D/E.

But, it means you can never bring two devices up on the same subnet at the same time.

Or, deal with two devices that "crashed" or "were reset" at the same time. Each prevents the other from being accessible.

You could pick *different* addresses for each device (by convention). So, a model X router defaults to A.B.C.D while a model Y router (or NAS or ...) defaults to A.B.C.F. This reduces the problem -- but still restricts you to only *one* of a particular model at a time.

And, doesn't address the issue of different manufacturers opting to "pick" the same defaults (for different/competing products).

"Ah! Assign address ranges to specific manufacturers! This eliminates any potential conflict!

(Gee, OUI comes to mind! I.e., use the MAC address as the "default" to ensure there are no conflicts. But, then we need to map this to an IP address. Hey! How about DHCP?? :> )

No. *You* served up the IP address via the DHCP service. So, *you* know what address was assigned to the device -- and *know* that it is appropriate for the subnet on which you've served up that address! You're not stuck trying to probe specific IP addresses in the hope of stumbling onto the IP that the device has (by default) elected to use.

And, if you buy *20* of a particular device, you know they will all get unique IP's -- because each will have a different MAC and your DHCP service will dole out different leases to each.

(likewise, if they all crash or are reset, you know they will once again "return to the fold" -- they can't talk, otherwise!)

Reply to
Don Y

So is your question "how well can i expect any randumb device to respond in the desired way to DHCP address settings?" or something else?

?-)

Reply to
josephkk

Ideally, I would like to reserve the entire IP address space on an *isolated* subnet (contradiction in terms? :> ) -- so whatever IP address the device is configured to use will be KNOWN to be "available" for use.

Assuming a static IP is in use, *then* engage in a network discovery protocol to identify that address.

When/if this fails (*typically* because a static IP is NOT in use), then serve up a DHCP lease (for "wherever is convenient").

Now, *knowing* where the device resides, cut a hole through the FW that is isolating this "entire IP address space" from my *specific* subnet on the other side.

Finally, translate the IP address of the device I am using on *my* side of the fence into one that resides on the same subnet as the (isolated) DUT.

I.e., "now we can talk".

(The ideal would be to put the firewall in a promiscuous mode so that *my* device could also *observe* the traffic that the DUT -- ALONE on that isolated subnet -- was generating).

In more practical terms, I think you could expect just the RFC1918 portions of the address space to be "likely candidates" for the DUT. This would cover most "appliances" (assuming you can easily "reset" them). The exceptions might be hosts that have static IP's (e.g., typ. Class C). You couldn't "reset" those (at least, not just by "pressing a button") to force them to be better behaved...

Hence the need for the discovery capability (which, perhaps, you could bootstrap with a particular IP subnet "likely" to be in use)

Reply to
Don Y

conflict

approach

DUT

operating

respond

*isolated*

device

protocol

is

the

of

DUT.

*my*

portions

It is not clear to me whether you have devices behind different firewalls or just one behind a firewall and the other out on the net.

Not that you need it but anyone interested RFC1918 is here: <

formatting link
>

If different firewalls are involved and there is no other connection between the internal nets they protect a VPN tunnel may be the answer. Kind of depends on device capabilities though.

?-)

Reply to
josephkk

In my current scenario, the device would sit on an isolated subnet that I would drill *into* from another subnet (which, itself, is isolated from the 'net by a firewall).

I.e., the DUT should not be able to talk to anything besides the *one* device from which I drill into the DUT's subnet. AS IF that one device was on the subnet with the DUT (but, isn't, "physically").

The separate subnet for the DUT would allow it to pick *any* IP that it wanted (assuming it had a static IP) without conflicting with any IP that I was already using (on *my* subnet).

The device that insulates my subnet from the DUT's would (ideally) watch for a DHCP lease request (if the DUT opted for that -- nothing else on that subnet to be *making* such a request!) and grant it. Then, translate the address of the host that I am using on *my* subnet into one compatible with the DUT's subnet (so, now it and I can freely "talk").

In the case of *no* DHCP/bootp/etc. request from the DUT, the insulating device would perform address discovery on the DUT subnet to determine the static IP that the DUT has pre-chosen. Then, do the address translation bit (above), etc.

All I want/expect from the device is IP capability.

I have a couple of different scenarios that come up often.

The first will be an appliance that has no console. I want to be able to talk to it (built-in web service; telnet; etc.) without having to play "20 questions" to arrive at the correct IP address. I usually know how to "reset" the device (and, perhaps, this will even tell me what IP it

*picks* thereafter). But, then I have to reconfigure a "DUT subnet" to support that address (and reflect it back to me on *my* subnet). Most often, these appliances are somewhere in 192.168/16. *Or*, require a DHCP service.

The second is a *host* that has no console. I may be lucky and it may even have it's IP written on a nice little sticker, etc. But, I've still got to be able to physically connect it to without worrying about it conflicting with an existing host on *my* subnet (because any IP that it has already picked is probably also 1918)

This isn't a *huge* problem. It's just an "annoyance". I was hoping for an idea that makes the process a lot less *tedious*. (I play with lots of oddball kit!)

Reply to
Don Y

*my*

portions

would

button")

could

firewalls

isolated

the

play

for

OK. I still do not fully understand your situation. It sounds like you need one really good managed switch ($$$$ to $$$$$) and maybe some DHCP capable mini routers to talk to all the oddball stuff and perhaps a few hubs. I am talking one that can NAT every port individually.

Thanks for reminding me that a lot of the early (primitive) Internet of things will not have decent IP stacks.

?-)

Reply to
josephkk

I've decided to just find a small box that I can run headless and dual-home: one port on *my* subnet and the other on the "DUT subnet". In essence, the same sort of thing that I've been manually doing with a laptop... but, exploit a "console" on an existing machine (telnet) instead of relying on the display/keyboard in the laptop. That way, I can access it from ANY convenient machine.

And, just script the whole process *on* that dual-homed box!

One of these little Atom's would be ideal (size, power requirements, horsepower, etc.) but I would have to resort to a USB ethernet adapter for the second NIC (no internal slots -- it's an SBC)

Reply to
Don Y

Yes, that's just what was suggested: a managed switch. Old ones abound from folk who've upgraded to gigabit; just buy one.

Or, maybe just look in your closet and find that you already have one!

Reply to
whit3rd

I have several managed switches. They won't serve up DHCP leases. Nor will they perform network discovery functions (if the DUT doesn't request a lease, how do I know what it's IP is?). Or, network address translation (what if the DUT has the same static IP as the node from which I am attempting to contact it *or* that which the switch consumes for its own use?).

You need to be able to "run code" in the device that is acting as your proxy. *Then*, these things are (relatively) easy to perform.

Or, be willing to make concessions as to which classes of devices you

*won't* be able to access (and, when you can't access a device, *assume* that it is for one of these reasons -- and not because the device's i/f is down, or the device is defective/crashed, etc.)
Reply to
Don Y

you

DHCP

few

dual-home:

abound

request

translation

use?).

Well that is a poor excuse for a managed switch as i understand the term. Port by port NAT is something unusual though. End devices that do not have DHCP stacks may well use a broadcast system instead, maybe that can be made IP address independant/irrelevant.

Reply to
josephkk

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.