Relay agents, NAT, and offers to giaddr
dhcp1 at thehobsons.co.uk
Thu Sep 14 23:17:54 UTC 2006
Chris De Young wrote:
>We have a problem where a proposed architecture is not currently
>working, and I want to determine whether or not what they are trying
>to do is legal.
It isn't legal - it's a broken network
>We have a DHCP client connected to a network with a relay agent, all
>on private address space, then later there's a NAT box, and then later
>there's the DHCP server on a public address.
>---------- --------------- ------- ----------------------
>| Client |----| Relay-agent |---| NAT |-----| Public DHCP server |
>---------- | 10.1.1.1 | | | | 128.196.128.x |
> --------------- ------- ----------------------
>The relay agent does NOT do the routing for this segment (it's a
>wireless controller), that's done at the NAT box.
>The problem is that the relay agent puts 10.1.1.1 into the giaddr
>field of the DISCOVER packet, so when the server gets it, it sends the
>OFFER back to 10.1.1.1. Alas, from the server's point of view, it has
>no route to the 10.* network.
>My questions is: is the server *required* to send the offer back to
>the address in giaddr
>(in which case this architecture is
>, or can it be configured to send the offer to
>the source IP address in the forwarded discover packet that it
>received instead (which has been natted to public space by then and so
You've got access to the source code - get hacking ?
Seriously, NAT == broken
In IP terms, NAT is fundamentally incompatible with both of the TWO
rules of IP - that every device must have a globally unique address,
and every device should be capable of getting a packet to any other
device (with the modern amendment where that is subject to
administrative restrictions - ie firewalls).
Your rfc1918 addresses are neither unique nor routable, therefore it
is a broken network<period>.
As an aside, I can recall (some time back) a query where a dhcp
server was expected to service two different private addressed
domains with overlapping address ranges. In other words, the server
and routers needed to cope with having two different 192.168.1.0/24
networks (for example) and somehow know which one a packet was
related to !
You can do several things to work around this.
1) Add sufficient routing table entries to make the private addresses
routable (bypassing NAT) between the server and the other network.
2) If the above is not possible (eg there is an intervening network
that won't route the addresses and you don't have control over it)
build some sort of tunnel (aka VPN) to do it.
3) Use real addresses
4) Move the server
5) Get hacking ! However, I can't remember is the server puts GIAddr
in the reply packets - if not then if you send to another address the
relay agent no longer has the information about the network to
broadcast the reply on. In the general case, the source address of
the packet does not have to be the same as GIAddr.
More information about the dhcp-users