Replies to request coming over a relay goes to relay's internal IP, not to original request's source IP

Question

Dhcpd running on Linux gets a dhcp request over dhcrelay which is running on other remote machine.

Oct  6 10:09:46 2012 dhcpd: DHCPDISCOVER from 00:1e:68:06:eb:37
(oguz-U300) via 172.16.17.81

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
10:35:01.112500 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 328) 192.168.0.81.67 > 192.168.0.1.67:
BOOTP/DHCP, Request from 00:1e:68:06:eb:37, length: 300, hops:1,
xid:0xe378fc7e, flags: [none] (0x0000)
          Gateway IP: 172.16.17.81
          Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]

It matches to a subnet and send reply. However reply does not go to the requesting dhcrelay external IP(192.168.0.81). Instead, it goes to the internal interface IP of machine running dhcrelay. And I think because of this remote machine running dhcrelay or the dhcrealy itself discarding packet.

Oct  6 10:09:46 2012 dhcpd: DHCPOFFER on 172.16.17.11 to
00:1e:68:06:eb:37 (oguz-U300) via 172.16.17.81

10:35:02.050108 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 328) 192.168.0.1.67 > 172.16.17.81.67:
BOOTP/DHCP, Reply, length: 300, hops:1, xid:0xe378fc7e, flags: [none]
(0x0000)
          Your IP: 172.16.17.11
          Gateway IP: 172.16.17.81
          Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]

Is this a normal behaviour?

Machine running dhcrelay:

eth1(ext)      Link encap:Ethernet  HWaddr 00:90:0B:21:43:F4
          inet addr:192.168.0.81  Bcast:192.168.0.255  Mask:255.255.255.0
eth2(int)      Link encap:Ethernet  HWaddr 00:90:0B:21:43:F5
          inet addr:172.16.17.81  Bcast:172.16.17.255  Mask:255.255.255.0

 3582 ?        Ss     0:00 /usr/sbin/dhcrelay -i eth2 192.168.0.1

Machine running dhcpd:

eth1      Link encap:Ethernet  HWaddr 00:90:0B:23:97:D1
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0

option domain-name "test.com";
option subnet-mask 255.255.255.0;
authoritative;
ignore client-updates;

ddns-update-style ad-hoc;
default-lease-time 86400;
max-lease-time 86400;

 subnet 192.168.0.0 netmask 255.255.255.0 {
        range 192.168.0.135 192.168.0.169;
        option broadcast-address 192.168.0.255;
        option domain-name-servers 192.168.0.1;
        option domain-name "test.com";
        option routers 192.168.0.1;
 }

 subnet 172.16.17.0 netmask 255.255.255.0     {
        local-address 192.168.0.1;
        server-identifier 192.168.0.1;
        range 172.16.17.10 172.16.17.11;
        option broadcast-address 172.16.17.255;
        option routers 172.16.17.81;
        }

(I put local-address and server-identifier. But this does not help )

Regards,

-- Oguz YILMAZ

UPDATE:

The first problem is found. I have configured dhcrelay only on listening internel interface. It seems (of course) is should also listen to external interface for replies. It appears it is not important where the packet destined to. dhrelay will forward it to internal net.

HOWEVER, I have deleted route on dhcpd server to reach 172.16.17.x subnet. It again tries to send reply to 172.16.17.81. Because it does not know the route it send it from default gateway to the internet.

eth0:  IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP
(17), length: 328) 192.168.1.2.67 > 172.16.17.81.67: BOOTP/DHCP,
Reply, length: 300, hops:1, xid:0x32830125, secs:3, flags: [none]
(0x0000)
eth0:     Your IP: 172.16.17.11
eth0:     Gateway IP: 172.16.17.81
eth0:     Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]

How can I force dhcpd to force to send replies to requesting IP? Because, it is not much meaningful to add routes to subnet we distribute IP for.

Internet - dhcpd - 192.168.0.1 - SOMENET - 192.168.0.81 - dhcrelay - 172.16.17.0/24

192.168.0.1 has no route for 172.16.17.0 and has no interface directly attached to that net.

Answer 1

This is normal. The DHCP Server will use the IP Address present in the Gateway IP (giaddr) to send responses, as written in the specifications. In general, DHCP prefer to use the addresses present in the DHCP/BOOTP payload than the one in the IP and MAC headers.

The Gateway IP address must be the address of the interface connected to the client; so that if a relay has several interfaces connected to clients, then it can simply sends the IP address of the interface where the request was received, and the server will respond to that IP, so the relay can know on which interface the answer must be relayed. This allows the DHCP relay to be stateless.

If you relay reject it, then there is a problem with your relay. A routing problem, maybe ?

---

Update:

HOWEVER, I have deleted route on dhcpd server to reach 172.16.17.x subnet.

This is wrong on many regards. Once clients are configured via DHCP, they may contact the DHCP server directly with unicast, without using the relay. If the DHCP Server cannot answer these queries, bad things could happen, such as client being unable to extend or remove their leases.

Because, it is not much meaningful to add routes to subnet we distribute IP for.

Except this is how DHCP work...