How to configure firewalls for University DHCP service

Expand All

Your firewall will need to pass traffic associated with clients performing initial discovery (before they have an address on your subnet) as well as subsequent transactions.

Bridging firewalls

A bridging firewall should permit the following packets to pass. These examples are based on the 163.1.14.0/255.255.254.0 subnet with gateway 163.1.15.254; you will need to replace these with your own network, netmask and gateway addresses.

Outgoing:
UDP 0.0.0.0 68  > 255.255.255.255 67
UDP 163.1.14.0/255.255.254.0 > 129.67.1.2 67
UDP 163.1.14.0/255.255.254.0 > 163.1.2.2 67
Incoming:
UDP 163.1.15.254 67 > 163.1.14.0/255.255.254.0 68
UDP 129.67.1.2 67 > 163.1.14.0/255.255.254.0 68
UDP 163.1.2.2 67 > 163.1.14.0/255.255.254.0 68

Routing firewalls

The firewall itself will be acting as the gateway for internal hosts and must therefore be able to forward the traffic to the external DHCP servers. If purchasing such a firewall you will need to ensure that it can do this, or else implement your own DHCP server in-house.

Initial DHCP discovery

A basic DHCP exchange will on the local subnet appear as follows:

   UDP 0.0.0.0:68 (00:00:39:1C:0C:32) > 
       255.255.255.255:67 (FF:FF:FF:FF:FF:FF) DHCP DISCOVER

At this point the client has no IP address and so uses a source address of 0.0.0.0 and source port of 68 (often referred to as bootpc, the BOOTP client port - BOOTP being the forerunner of DHCP). The packet is sent as a UDP broadcast on port 67 (bootps). Normally this packet will be seen by any host on the local subnet.

Because the OUCS DHCP Service has two servers acting for many different subnets, the packets must be passed from the local subnet to the servers at OUCS. This is done at the router, which will forward any broadcast packet received on an interface to the central DHCP servers (163.1.2.2 and 129.67.1.2: any change to their IP addresses will be announced in advance on the itss-announce mailing list). The forwarding is performed as unicast packets from the router to each server in turn.

Server response: DHCP offer

Because the central DHCP service is provided by two DHCP servers, normally a client will receive two offers of an IP address in response to its initial DISCOVER request. There are exceptions if one server is down, or has no free addresses available.

Because the DHCP servers see the request as originating from the router address, they will return it to the router interface on the subnet in question. The router is responsible for forwarding the responses to the client. For a client on the 163.1.14.0/255.255.254.0 subnet, the responses will be along the following lines:

   UDP 163.1.15.254:67 (00:D0:BC:00:11:22) > 
       163.1.15.99:68 (00:00:39:1C:0C:32) DHCP OFFER
   UDP 163.1.15.254:67 (00:D0:BC:00:11:22) > 
       163.1.15.94:68 (00:00:39:1C:0C:32) DHCP OFFER

Note that the destination IP address is that which the server is offering to the client while the destination MAC address is that of the client's network interface. Thus the packet will reach the client even though it does not yet have its IP address.

Client response: DHCP request

This stage is similar to the first, except that the client now requests a particular IP address from the DHCP server. Additionally, some clients will use this method to request the IP address they previously used (for instance last bootup); if it is denied (DHCP NAK) they will fall back to the first stage.

   UDP 0.0.0.0:68 (00:00:39:1C:0C:32) > 
       255.255.255.255:67 (FF:FF:FF:FF:FF:FF) DHCP REQUEST

Server completion: DHCP acknowledgement

Here the server acknowledges the client's request for an IP address. The basics of the packet are the same as for a DHCP OFFER. Once a client receives this packet, it keeps the IP address given until the expiry of the DHCP lease or until it sends a subsequent DHCP request.

   UDP 163.1.15.254:67 (00:D0:BC:00:11:22) > 
       163.1.15.99:68 (00:00:39:1C:0C:32) DHCP ACK

A variation at this stage is for the server to send a DHCP NAK (not acknowledged) which denies the client the IP address it requested.

DHCP lease renewal

This is similar to the first DHCP REQUEST but with a crucial difference: the client knows its IP address and that of the server. As the DHCP server is on a different subnet, requests bear the MAC address of the router.

   UDP 163.1.15.99:68 (00:00:39:1C:0C:32) > 
       129.67.1.180:67 (00:D0:BC:00:11:22) DHCP REQUEST

   UDP 129.67.1.180:67 (00:D0:BC:00:11:22) > 
       163.1.15.99:68 (00:00:39:1C:0C:32) DHCP ACK

A DHCP NAK may be returned by the DHCP server if the lease cannot be renewed, at which point the client should abandon its IP address (and may send a DHCPDISCOVER).

Get support


If you cannot find the solution you need here then we have other ways to get IT support

Get IT support