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

[Simon Hobson]

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.

>Indeed I believe dhcpd *requires* that each relay agent as a unique
>source IP of the relayed request, or I don't see how it would ever get any
>packets back at all.

Correct.

>>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.

>To give you an example that has nothing to do with my deployment, suppose
>you run a fleet of wireless access points, all of which act as DHCP relays.
>Some NAT, some don't, dependent perhaps on the client authentication which
>gets put into a dchp option. Let's assume dchp packets go back over some
>tunnel to the central dhcpd server. Assuming you can select a dhcp pool (or
>a fixed address) based solely on what's in the dhcp request (including the
>options), why does the dhcp server need to know about subnet arrangements
>(by which I mean the subnet statement, not option-subnet-mask which has to
>be filled in)? The reason not to describe it in the config is simply that
>otherwise you have to describe the subnet config in at least 2 places
>(dhcpd.conf and how the routers are set up), which means there is the
>probability they will get out of sync.

I understand what you are saying, but surely you are doing nothing 
more than moving the deckchairs around. If you identify the clients 
'details' by (eg option 82) then you have just created a situation 
where you must keep that management system in sync with the router 
config.

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.

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).

Clearly these days the original model isn't optimum for all users 
(hence the faff if you want to assign address by Option 82) - that's 
why various changes have been made or proposed.

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

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.