Reconfig of dhcp.conf

Glenn Satchell Glenn.Satchell at
Thu Nov 26 13:15:52 UTC 2009

>Date: Thu, 26 Nov 2009 07:43:33 -0500
>From: Chris Arnold <carnold at>
>On 11/26/09 4:00 AM, "Simon Hobson" <dhcp1 at> wrote:
>> Chris Arnold wrote:
>>> So i know it is listening/sending on 192.168.124. Therefore, will
>>> need a trust to dmz policy and a dmz to trust policy? I did that and
>>> made no difference.
>> You will need the firewall to allow the relevant packets, AND act as
>> a relay - it's not a simple matter of just forwarding packets, the
>> relay agent modifies them as it goes. There may be a requirement for
>> untrust->firewall, firewall->untrust, trust->firewall, and
>> firewall->untrust permit rules - as well as untrust->trust and
>> trust->untrust to allow unicast traffic between clients and server
>> when it comes to renewal time.
>>> Would it be better to have dhcp on the trust network,
>> Since the server is already physically connected, it would seem the
>> simplest way round it. Just turn off the relay agent in the firewall
>> and configure the DHCP server to serve that subnet/segment directly.
>All this would be fine but even the clients on the dmz (which is where the
>dhcp server is. There should be no need of a policy for this) are not
>getting ip's. So, I am back at square 1, not sure if this is a dhcp issue or
>a firewall issue.

Based on your network diagram, the dhcp server is directly attached to
the two subnets. Therefore no dhcp traffic goes through the firewall,
so no firewall config is required.

Firewall(trust port)-----------
(dmz port)                       |   |||
    |                            |  dhcp clients
    |                            |
    |                            |
|--        |
|   |||                          |
|  Dhcp clients                  |
|--(eth0)Dhcp in question(eth1)--|

So you need to debug this.

See that you can ping the interfaces on the router. Make sure you have
the interfaces on the dhcp server plugged into the right networks.

Check that there are no syntax errors in the dhcpd.conf:

dhcpd -t

Check that the dhcpd.conf that you are editting is the one that dhcpd
will actually use. It could be /etc/dhcpd.conf, /etc/dhcp/dhcpd.conf,
/usr/local/etc/dhcpd.conf and so on.

Find the log file and look at the startup messages. Make sure there are
no errors. See if there are DHCPDISCOVER messages being logged.

Do a packet dump on each interface looking for UDP traffic on ports 67
and 68. See if the client requests are actually coming in.

PS Please don't delete all the old bits from the email, not everyone
keeps every message in the thread...


More information about the dhcp-users mailing list