Old Tired Question: 'Not configured to listen on any interfaces'

[Alex Bligh]

Simon,

--On 25 February 2011 16:02:19 +0000 Simon Hobson <dhcp1 at thehobsons.co.uk> 
wrote:

> Alex Bligh wrote:
>
>>> NAT == Broken, NAT with overlapping subnets == doubly broken
>>> NAT is expressly incompatible with the two most important rules of IP
>>> addressing - global uniqueness and globally routeable.
>>
>> We do what customers want. Note RFC1918 != NAT.
>
> OK, I inferred that, but the fact that you have overlapping subnets also
> means the network is broken - IP addresses are neither unique nor
> globally routable.

The whole point of RFC1918 is that multiple networks can use the
same space. To be clear, customer A's numbering in 1918 space can
intersect with customer B's, and the networks are not connected
at all (they are virtual and isolated).

>>> When you get a renewal request from a client at (say) 192.168.1.57, how
>>> do you route the packet back to it ? I'm guessing you don't and rely on
>>> the client reverting to broadcasts before it's lease runs out, in which
>>> case your DHCP isn't working as well as you thought.
>>
>> Nope. We route the packet back to the relay agent that sent it (using
>> that relay agent's source IP address, just like is done normally).
>
> So you are intercepting the unicast packets at the router then ? For
> renewals, the client communicates directly with the server, and a relay
> agent is not required at all. Some net gear has the ability to sniff
> traffic, and modify DHCP packets - typically by inserting option 82.

Sort of.

We have a virtual device which behaves like a dhcp server, but is
actually relaying the packets. As far as the client is concerned, it
is talking to a dhcp server.

Given we are only doing fixed leases, renewals aren't important in
our config, but I see no reason why such a config could not be
adapted for dynamic leases.

As a general point though the question of whether it is necessary/useful
for the client to reach the dhcpserver directly is going to be
dependent on the deployment in question and is largely orthogonal
to whether the "real" server needs to have an understanding of
network topology (e.g. subnet statements).

> Unless you can reliably tie a client to a subnet then you can't provide
> it with an address _that will work_. In your case you have abstracted
> that by MAC address and knowing which network a device belongs to - so in
> effect you have described the subnet config in two places (the routers
> and your database) and to quote you : which means there is the
> probability they will get out of sync. Of course, should a client get
> moved, then your system would hapilly lease it an address that's invalid
> for the network it's on.

Sure, except for the fact the routers are using the same database,
so don't get out of sync in my deployment.

> Taking your example, if the client can get a different subnet depending
> on some external influence (has the user authenticated for example) then
> the only secure way to deal with that is to use VLANs. If you use a
> shared subnet, then the user just has to change their address manually
> and they've bypassed your non-security. Once you have the user in a
> specific VLAN, then the subnet will identify it's location (in IP space).

I don't pretend to be a WiFi guru but I believe WiFi equipment can
dump you on a different VLAN depending on authentication/SSID, or
(e.g.) build an L2TP tunnel. And all that auth can be backed by
a DB. This should, however, act as a warning to me in coming up
with examples of technology that I am not familiar with.

> But I think this discussion is getting a bit off topic, and probably
> isn't going to bring anything new to light.

Sure.

The interesting point for me I can summarise thus: dhcp was originally
designed such that
1. The server ran on the same network as the clients
2. The server would hold the canonical configuration

In many use cases it would be better if neither of these assumptions
need hold. However, ISC dhcpd, being designed a while ago, and
being a reference implementation, tends to make this hard. Subnet
0.0.0.0/0 is a useful hack, but probably only if you know what you
are doing.

-- 
Alex Bligh