dhcp1 at thehobsons.co.uk
Sun Sep 30 07:40:22 UTC 2007
Ashley M. Kirchner wrote:
>I have to keep those IPs. I can't change them to contiguous, I
>can't do anything with those devices, they're set by vendors.
There's no such thing as "can't" in my book, though situations where
you need to change things that you don't control are a PITA and to be
avoided if possible. The fact that you can't change them also means
that you can't change the subnet mask for the network they are on
since that would require as much effort as changing the IP as well.
> By your answer then, it means I can NOT use the entire
>192.168.10.0/24 range for dynamic allocations because that would
>also include those static IPs. Which to me means I would have to
>set multiple ranges across the /24 address space so to exclude the
>static IPs. Correct? In my case I can do .10.30 - .10.90, then
>skip and set another range from .10.120 - .10.230 and stop there
>since the high numbers are once again reserved.
> This whole switching to DHCP started when someone upstairs said
>they wanted a wireless access point available to clients,
Ahh, the "orders from above" problem - I think we've all suffered
from that affliction :-(
>however it has to be limited but at the same time permissive. Let me explain:
> The access point needs to allow both known as well as unknown
>clients, with the known ones being co-workers, and unknown being
>anyone that walks into the building with a device. If the client is
>a known client, provide full routing and DNS to them. If the client
>is unknown, then provide an IP that allows it to access a shared
>NFS/Samba drive and that's it. They don't get internet or any other
> So, the server I'm setting this on already has 3 network interfaces on it:
> eth0 - public IP
> eth1 - 192.168.10.0/24 -> internal network switch
> eth2 - 192.168.20.0/24 -> internal backup switch
> * those are two completely different switches by the way
> At the moment, our entire internal network lives off of eth1
>which routes through eth0. eth2 is used between servers for backup
>purposes. They communicated with each other via that interface,
>however there is no routing for that interface on any of the servers
>- in other words, if I shutdown all interfaces on a server and only
>leave their .20.0/24 interface up, they can no longer hit the
>internet, only see each other. This is the desired design, not
>something broken. We did this on purpose.
That's OK, it's actually fairly common.
> So, ideally I want an unknown client to get an IP that's in the
>.20.0/24 range so that it can "see" the server and able to access
>its NFS/Samba share, however it wouldn't be able to get to the
>internet or our internal network. And if the client IS known, give
>it an IP in the .10.0/24 range and proper routing (DNS, gateway,
>etc.) so they can see the rest of the network and get outside access.
Problem there is that the client will be on the same physical network
irrespective of what address it is given - hence if you give it a
192.168.20.x address then the client won't be able to do anything,
not even talk to the servers which are on a different physical
First off, a reminder that DHCP is NOT a security protocol - you
CANNOT prevent a device from using the network by simply giving it
wrong information or no lease at all. It's trivially easy for users
to figure out what the network settings are and manually configure
their device to suit.
What I would suggest it setup a small pool of addresses in the
192.168.10.0 subnet for use by visitors. You can specify different
settings (such as bogus gateway, different DNS servers) for this pool.
Alternatively, setup a completely different subnet for visitors, and
use an access point that supports VLANs and multiple SSIDs (eg
Linksys WAP200) - that way you can have one wireless network for
staff, and a different one for visitors.
More information about the dhcp-users