DHCP

Dynamic Host Configuration Protocol (DHCP) is used to provide basic network parameters to devices on a network in an automatic way. DHCP servers can be found built in to simple routers as well as available for complex network servers. DHCP can be used to provide anything from the basic IP address and netmask through to any of hundreds of different parameters needed by a machine.

DHCP Client

The FireBrick can be a DHCP client. This means its basic network parameters can be set as a result of it requesting information from a DHCP server on the network. This is done be selecting DHCP client in any subnet. There is no point in selecting DHCP client on more than one LAN subnet and more than one WAN subnet as once the details are obtained they change all subnets marked as DHCP on that interface.

Once an address is allocated, the IP and netmask are set in the subnet configuration, and these can be viewed using the web interface.

In addition, the following parameters are also set :-

The subnet allows each of these settings to be ignored if required.

The provided renewal and expiry are followed, but are limited to a maximum. If renewal fails, then at expiry the IP and netmask are removed from the DHCP client subnets, and requests are retried. Renewals are normally to the server address, but can be forced to be broadcasts as an option on the subnet (some cable modems need this). If power cycled, all allocations are discarded and new requests sent.

For reference, the FireBrick requests a CLASS of "FireBrick" for its address - this can be useful for configuration of some DHCP servers. The FireBrick sends its own configured name as the client name on requests. It obviously works with another FireBrick as its server.

Checking

When offered an address, the FireBrick will normally do an ARP check on the address to confirm it is available. If it is already known at OFFER or ACK stage then the FireBrick will decline the address and start again. This feature can be disabled, as some cable modems will proxy ARP all addresses, even the ones being allocated !

Routes

Individual routing entries can be marked DHCP. When an address is allocated, these routing entries are updated automatically. This feature allows explicit routes to gateways and subnet, etc, to be used whilst having a DHCP allocated gateways and subnets.

DHCP Server

As a DHCP server, the FireBrick has a number of innovative features. It is not configurable to provide every possible DHCP parameter to clients, but can provide the basic parameters needed as well as some unique features useful on a network.

Basic operation

Any subnet can have a range of addresses specified. Only addresses within the subnet, avoiding network, broadcast and the FireBricks own address, are considered. Multiple subnets on the same interface allow different blocks to be allocated - i.e. the same subnet details can be repeated with different blocks of DHCP server allocations so as to make multiple blocks in the same subnet range. There is no harm if the DHCP ranges overlap as an address is only considered once.

The FireBrick will allocate IP, netmask, Router (itself), name server (itself), syslog server (itself), time server (itself) and domain name. However, the subnet can be configured not to provide router, name server, syslog server, domain name, or time server if required. The FireBrick provides itself for most of these addresses as it acts as a relay for them to the configured addresses (or as a server for time). This allows these to be set and changed manually or as a DHCP client on another interface without having to change each allocated machine.

Protection

Before OFFER and ACK of an address the FireBrick checks by ARP if the address is free. If not, then the REQUEST is refused, and the client must try again. Any addresses found in use are marked as such with a maximum lease time.

Reservation

If the FireBrick offers an address, it is marked as reserved (i.e. just expired) for that client. If the client does not request the address, then the slot is reserved, and may only be reused if addresses run out. This helps stop two overlapping requests from different clients trying to get the same address.

If the client declines an address then the address is blacklisted (marked as just expired but with no MAC). This means it will only be considered if no addresses are left. If the same client then asks for an address again it will not get the address it just declined (unless it is the only address left). This is important as some clients may have other ways to identify an unacceptable address and so would otherwise get stuck in a loop requesting an address and getting the same unacceptable address over and over again.

In both cases the allocation is marked as "just expired" and so the allocation can be immediately re-used if there are no addresses left. It simply makes them the last choice.

Persistence

Address allocations are persistent. Even when expired, the address allocated is not re-used for another machine unless there are no addresses available. This makes the allocations permanent, which is a very useful, albeit unusual, feature of a DHCP server.

Requested

If a machine requests an address, then it is honoured if that address could be allocated (within ranges, and rules for allocation and available for allocation). This means that if a set of machines were using a different DHCP server, and switch to the FireBrick - it will usually keep the same allocations. The can be very useful in maintaining persistence if replacing a FireBrick, and also for maintaining addresses if the FireBrick is operating as a backup server.

Logging/Status

The allocated addresses are available via the web interface, showing not only the IP and MAC address but also the expiry and the client name (if specified). This allows an immediate overview of all allocations. Individual allocations can be manually cleared. Allocations and releases are also logged.

Backup operation

The FireBrick can be marked as a backup server - only allocating addresses if another server has not yet done so. This is done by ignoring the first request (time 0) from any client.

Restricted addresses

Each subnet has a name, and it can be marked for restricted DHCP allocation. This restricts allocation to machines who's client name starts with the subnet name (case insensitive). This allows allocation of addresses to groups of machines based on the machine name.

If a machine sends a discover with no name, and it was previously allocated an address, the name is assumed to be the same - this covers some print spoolers that only send their name on the REQUEST and not the DISCOVER phase. i.e. it can be allocated by removing the restricting briefly, and then it will be able to renew or re-allocate after reinstating the restriction.

If the requesting machine has a name that matches a restricted subnet on that interterface, then it will only be allocated an IP from one of the restricted subnets for which it's name matches. If the requesting machine does not match a restricted subnet, then it can only be allocated from unrestricted subnets.

Sharing

The FireBrick server follows rules correctly for multiple DHCP servers, unlike some servers. This should mean it is not a problem if it is on a LAN with another server. Its protection mechanism even allows this where the allocation addresses over lap.

Running out

If no unexpired addresses are left or the DHCP allocation table is full, addresses are not offered (or if requested are NAKed). However, if all addresses have been used but some are expired, then the oldest address is re-allocated.

No clock

If the clock is not set then the lease time is the same, but is not known by the FireBrick. It effectively treats all allocations as permanent and will never re-use one even if it runs out. When the clock is set, all such allocations are set for the normal expiry from that point.

Mirroring

The DHCP server can be configured in mirror mode. This means it will be set when the FireBrick is allocated an address as a client on its other interface. In this mode, the IP address of the FireBrick on the mirroring interface is set to the router address from the other interface, and the DHCP server range is set to the single address allocated to the FireBrick on the other side.

This is normally configured such that WAN is DHCP client , and LAN is DHCP mirror and DHCP restrict and a blank WAN to FireBrick portmap to LAN. The client gets an address on the WAN, and sets the gateway, etc. The LAN side is set as the router and allocates a PC the FireBrick's WAN address. The PC then uses the FireBrick as a gateway which forwards to the real gateway. The FireBrick receives traffic for the PC and via a general portmap relays to the PC (subject to filtering rules).

Normally the PC's name is the name of the LAN mirroring subnet, allowing only that PC to get that address. Another LAN subnet is then set up with private addresses and DHCP server range and NAT. This allows other machines on the LAN to get addresses and work on the internet using NAT.

The main PC therefore follows the allocation from, say, a cable modem, allowing full incoming and outgoing non NAT traffic to operate. The continual renewal of addresses from the FireBrick even when the PC is off means the address does not change (with some cable modems) and so can be treated as a fixed address.

In case the address is changed from time to time, the lease and renewal on the mirror interface are issued to renew/expire 10 seconds after the DHCP client side, allowing a quick change of IP on the internal machine if the FireBricks IP is changed by DHCP.

Factory reset modes

The factory reset procedure allows the FireBrick to start up with a DHCP server on LAN and/or DHCP client on WAN enabled. See connectors section.