Relay agents, NAT, and offers to giaddr

[Simon Hobson]

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

Yes

>(in which case this architecture is
>fundamentally flawed?)

It 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
>is reachable)?

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.