DHCP an NAT

[David W. Hankins]

On Tue, Jul 15, 2008 at 12:53:07PM +0200, Nathan Burgener wrote:
> Now the server gets the Discover from the client with the following 
> informations:
> Source IP 172.168.1.1
> Destination: Address from DHCP server
> Relay Agent IP Address: 192.168.3.1
>
> The DHCP server will now send back the offer. But the servers sends it to 
> 192.168.3.1 and not to the address 172.168.1.1
> How can I change that?

I think by the time you find out the full answer to this question,
you will not want to change that, and would rather put a separate,
small DHCP server on the behind-NAT side.

The first problem is your giaddr one.  To work around this, the IETF
standard way is to use the relay agent "link selection sub option",
which I do not think Cisco helper-address supports.  But if it does,
you would have to config the relay to set giaddr (which is the reply
address) to the public address, and to set the link selection
sub-option to the rfc1918 address.  ISC DHCP 3.1.x supports the link
selection sub-option.

The second problem is when your NATed clients renew they will unicast
their renewal through the NAT device.

NAT does not ruin DHCP contents as the source address and port are
ignored (ciaddr is used).  However.

The server, according to RFC2131 MUST's, will reply to the client UDP
port, not the NAT mapped port.

The cisco helper address listens to the _DHCP Server_ UDP port, as
that is what bootp relays do, so the packet will be dropped.

One workaround for this is to set the server-identifier to the relay
agent's internal IPv4 address (192.168.3.1).  This fools the clients
to send their renwals to the relay agent directly, which will relay
the packets to the DHCP server.  However, this makes the DHCP server
think every RENEWING client is actually REBINDING, and so it may
react differently to the clients.  You have to be pretty careful about
this kind of implementation in some complicated topologies, especially
where clients have multiple interfaces.


Another full workaround might be to connect the 192.168.3.x network
to the DHCP server directly, as on an 802.1q tagged virtual
interfaces, IP tunnels, an alternate direct router instead of NAT
(so the DHCP server has a route for 192.168.3.x), or somesuch.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins