DHCP/IPv4 Server Initial Configuration

Overview/commentary

This basic process may be starting to get to be a bit familiar. Similar steps have been covered by:

However, those guides simply involved setting up a simple DHCP/IPv4 for a single remote NIC. This guide covers setting up a server that can serve addresses from at least one subnet, and optionally multiple subnets.

Log in

Running an SSH client from that “physical” computer (which is the computer running the “virtual machine” software) may be nicer than trying to use VNC, particularly if using SSH permits superior “copy and paste” functionality.

If you have an IP address assigned to a TUN/TAP device, then a connection can be made to the SSH server that is running on the (virtual) machine that will be running the “DHCP/IPv4 server”.

The recommended approach is not to use the other virtual machine, because the other virtual machine will be reseting the network settings when testing the client. Instead, use another device on the same subnet. The prime candidate is the “physical” computer that is running the “virtual machine” software, which will be on the same subnet if a TUN/TAP device is used.

Remote systems might not be able to make such an SSH connection because routing isn't set up yet. Also, even if routing was set up to have traffic go through the firewall, that SSH connectivity would be affected when the firewall resets the network settings on a NIC. (However, if SSH is made using IPv6, that IPv6 communication could be unaffected by an action that resets the IPv4 parameters.)

Back up
ls -l /etc/dhcpd*.conf
[ ! -e /etc/dhcpd.conf ] && [ -r /etc/examples/dhcpd.conf ] && sudo cp -pi /etc/examples/dhcpd.conf /etc/./
sudo cpytobak /etc/dhcpd.conf
Edit the configuration
echo ${VISUAL}
sudoedit /etc/dhcpd.conf

Edit the file.

Here is a sample configuration file that shows addresses used for a subnet, as well as two hosts that will be provided with specific addresses.

# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.
#

option domain-name "sample.example.zz";
option
domain-name-servers
192.0.2.4,192.0.2.5,192.0.2.6,8.8.4.4;

subnet 198.51.100.0 netmask 255.255.255.0 {
option routers 198.51.100.1;

range 198.51.100.129 198.51.100.199;

host static-client {

# firewall VM second NIC

# device identifying address (MAC-48)
hardware ethernet 52:54:00:12:11:01;
# VMNUM is fifth hexadec' pair^^

# device IPv4 address
fixed-address 198.51.100.1;

# DNS Servers
option domain-name-servers
 208.67.222.222,208.67.220.220,8.8.8.8,8.8.4.4;
# Above list contains OpenDNS and GoogleDNS.  More addresses @ CyberPillar.com
# at /dirsver/1/mainsite/techns/netwrkin/netistrc/namtoadr/dns/dns.htm#dnsdusbl
}

host static-client {

# DNS Server

# device identifying address (MAC-48)
hardware ethernet 52:54:00:12:14:01;
# VMNUM is fifth hexadec' pair^^

# device IPv4 address
fixed-address 198.51.100.4;

# default gateway
option routers 198.51.100.1;
}
}

There's quite a bit to customize there. Get the “network documentation” handy, because information from that documentation may be helpful for properly customizing some of the values in this text file.

  • domain name: this was something that should have been selected by now (from the instructions for naming the project/network)
  • The domain-name-servers are DNS servers. The DNS servers don't need to exist quite yet. The values here are intended to be given to most machines on the subnet.
    • These don't technically need to be on the same subnet as anything else. They could even be publicly accessible DNS servers. Therefore, the example shown demonstrates having addresses in a different subnet from the other machines. However, it is quite likely that many networks will have DNS servers that use addresses that are part of the same subnet as the other virtual machines on the network.
  • Subnet: The subnet should have already been chosen. (See: Deciding the subnets (which basically just hyperlinks to: choosing subnets (for the child machines).)
    • A tutorial about subnetting may take a while (current general time estimate: 30-60 minutes?), but is available: Network basics
  • The “option routers” line refers to the “gateway of last resort”, more commonly known as the “default gateway”. (This is specified by RFC 2132 “DHCP Options and BOOTP Vendor Extensions” section 3.5: “Router Option” (code 3).) The address is IPv4 (since RFC 2132 section 3.5 indicates that each listed address is to be 32 bits).
  • The range specifies what addresses to will be handed out. With this DHCP server, reserved addresses must not be in this range. Having a design/plan/chart might be nice for deciding how to assign addresses in a controlled way, instead of making selections haphazardly. To that end, early addresses and system addresses: first half of octet might be helpful in making such decisions.
  • The “host static-client” sections contain information about specific devices. If the devices supply the hardware ethernet address, then the value of the fixed-address will be supplied as the IPv4 address to use, and the value of the option routers will be supplied as the “default gateway” to use.
    • The value of the hardware ethernet is a MAC-48 address. This same syntax is used for anything that supplies a MAC-48 address, even if a device is using Wi-Fi and not Ethernet. (Don't worry about the word ethernet.)
    • In this example, a value of the DNS Server is provided. If you've been following the guide closely, the ${VMNUM} (and, as a result, the MAC-48 “hardware ethernet” address) and IP addresses may not have been chosen yet. However, creation of the next server is something that the guide expects to happen soon. You could skip that step, but it might be better to just make those decisions now, and support that machine (even though the machine doesn't exist quite yet) starting right now.
      • An earlier section discussed choosing a machine name.
      • choosing VMNUM (also discussed at: making first virtual machine)
      • When determining which IP address a system will have, the chosen IP address should be within the subnet that was already decided upon. The “host bits” should be unique from any other machine in the same subnet. (That simply means that the last part of the address should be unique, which will make the entire address unique from anything else that uses the same bits at the first part of the address.) These resources may be helpful in coming up with the ending portion of an IP address.
      • In the previous example, the “firewall” does not have a value for the “option routers”. That is because the firewall is a multi-NIC machine, and it is presumed that the “default gateway” setting will be related to a different NIC. This is somewhat unusual; most machines should have the “option routers” provided (as shown by the sample configuration for the DNS server).
Info about other DHCP options

When some people see some of the available DHCP options, they become interested in using this widely supported technology to automatically assign values that might typically get assigned manually. A classic example of this is the idea of having the addresses of NTP servers be distributed via DHCP communications. This would seem to be available: RFC 2132 “DHCP Options and BOOTP Vendor Extensions” section 8.3: “Network Time Protocol Servers Option” (code 42).)

The problem is that clients do not typically support using the NTP server information that DHCP clients might provide. For some further reading, you may check out:

In short: using NTP server information that DHCP clients can be done, by using the ISC DHCP client (for Unix), although it takes a bit of effort to set this up on the client side. (Simply inputting the NTP servers manually is likely to be less work.) So, this approach is typically not worth doing, even though the necessary support on the DHCP server isn't very challenging to implement.

Test configuration file
ls -l /etc/dhcpd*.conf
dhcpd -n
echo ${?}

If that gives the results of zero, then go ahead and try running the server:

NIC must listen

Before successfully starting the DHCP/IPv4 server, the NIC that will be receiving the DHCP/IPv4 traffic must be ready to listen for traffic. If that NIC does not yet have its IPv4 set, then fix that before trying to run the server.

Run the server

Then, try running the server. Note that in this example, which includes the interface name as part of the filename, the name of the TUN/TAP device shows up twice in a single command line. Customize both locations.

sudo dhcpd
echo ${?}
ps -auxww | grep -i dhcpd | grep -v grep
Some notes about using ps

Note that although the above syntax will work okay with OpenBSD, ps syntax differences are significant enough that no single syntax is preferred by all the Unix implementations. Users of other operating systems may need to adjust the example shown. (Common modifications may include taking out the hyphen right after the word ps and/or removing some parameters, such as one or both of the w characters.)

Multiple redirections are shown. The final redirection is discussed in the section about “Having grep exclude itself”.

Troubleshooting (if the server isn't running)
dhcpd -n
echo ${?}

If the configuration file is valid, then dhcpd outputs no text, and the echo command will output a zero. If there a configuration error detected, then the echo command will output a one. Even better yet, the dhcpd will likely report the problem.

If the expected dhcpd is not running, check for error messages. (The program might not be considerate enough to provide a “verbose” option.)

tail /var/log/daemon | grep -i dhcpd
tail /var/log/messages | grep -i dhcpd

Note: The above commands are designed for a not-very-busy server. If other programs are likely to be writing to the log file, then some additional care may be needed to view the messages.

If this is not the first attempt to run the server, then pay attention to the number in the square braces right after the word “dhcpd”. That is a PID, and so it should presumably change each time you run the program. If you're not seeing the number change, you might be looking at older messages. You can also pay attention to the time stamp, if that helps any.

Optional: Some people might want to run “ tail -f /var/log/messages ” in another terminal. Then, after making changes to the text file, press the Enter key a few times so that new messages are easily visually distinct from older messages. Finally, the command can be exited with Ctrl-C. This is a very optional step that some people like to do, but people should not worry about this too much if there's some challenge/difficulty (such as if there is no terminal multiplexer, and so getting a second terminal would be a challenge).

Testing the server

On the firewall, view the current IP configuratino for the second NIC:

ifconfig em1

Then, go ahead and run the DHCP client:

sudo dhclient em1

If the system already had the desired IPv4 address, and the end result was that the system seemed to receive the desired IPv4 address, it may be worthwhile to just make sure. Remove the IPv4 address manually, and then re-request the address, to make sure that is being successfully handed out.

sudo ifconfig em1 inet delete
ifconfig em1
sudo dhclient em1
ifconfig em1

If results are still working well, then have this be the default behavior when the firewall reboots. (See: OpenBSD manual page for /etc/hostname.* files.)

ls -l /etc/hostname.*
[ -e /etc/hostname.em1 ] && cat /etc/hostname.em1
[ ! -e /etc/hostname..em1 ] && echo !echo Initializing \${if}...| sudo -n tee -a /etc/hostname.em1
echo dhcp NONE NONE NONE| sudo -n tee -a /etc/hostname.em1
echo up| sudo -n tee -a /etc/hostname.em1

Then you can view the file, and (optionally) edit it.

cat /etc/hostname.em1
echo ${VISUAL}
sudoedit /etc/hostname.em1

Test the results.

sudo ${SHELL} -c ". /etc/netstart em1"
Further adjustments
Start DHCP automatically

(This process essentially ends up being effectively similar to Starting DHCP automatically.)

Start DHCP automatically in OpenBSD

(This is assuming that the configuration file is already customized.) Details have been known to vary in different OpenBSD versions. (Older versions might require a NIC name.)

cpytobak /etc/rc.conf.local
echo dhcpd_flags=\"\"| sudo -n tee -a /etc/rc.conf.local
Setting the IP address

Make sure the computer running the DHCP/IPv4 address has the intended IP address(es). Actually, since DHCP/IPv4 uses broadcast, the server may function usefully even if it has the wrong IP address. (This is rather unusual for a server that a client needs to contact, because most protocols are not using IPv4 broadcast.) However, if there is any future desire to use DHCP Relay, then the server may need to respond to the expected address. Besides, there's no compelling reason for the server to be at an unexpected address, so the right configuration may as well be used.

ls -l /etc/hostname.*
[ -e /etc/hostname.em0 ] && cat /etc/hostname.em0
sudo cp -pi /etc/hostname.em0 /etc/hostname-orig.em0
echo inet 192.0.2.8 255.255.255.0 NONE| sudo -n tee -a /etc/hostname.em1
echo up| sudo -n tee -a /etc/hostname.em1

Then you can view the file, and (optionally) edit it.

cat /etc/hostname.em0
echo ${VISUAL}
sudoedit /etc/hostname.em0

If there is a previous line that starts with the word dhcp then replace that line with the line that specifies the statically assigned address. (That should be before the up line, which should be before the rtsol line if that exists.)

Test the results.

sudo ${SHELL} -c ". /etc/netstart em0"
Troubleshooting DHCP/IPv4
Abadondoned addresses

If you are playing around with static addressing before using DHCP/IPv4, and then you start the DHCP/IPv4 server before releasing the statically assigned address, then it is possible the DHCP/IPv4 will notice that the address is in use. (A simple ARP check, performed by the DHCP/IPv4 server, may cause this to happen.) In that case, the DHCP/IPv4 may decide to not hand out the address, even for some time after the statically-assigned address has stopped being used.

$ sudo cat /var/log/messages | tail
...
MMM  D hh:mm:ss sysname dhcpd[PID##]: Abandoning IP address 192.0.2.129 for 43200 seconds: pinged before offer
...
$

The abandonment is recorded in /var/db/dhcp.leases and could be significant if a system is supposed to be using a specific IP address. Solutions include adjusting the range (so that a different IP address may be handed out), or waiting for the abandonment to expire. Presumably adjusting the /var/db/dhcp.leases (which is a file using standard “plain text”) is another viable option.

Related material found on the web: DHCP ping leads to abandonment of an address. (Andy Hood's forum post, about same message, suggests being willing to assign an address if the system using the address is the same system that made the DHCP request. Perhaps that might have some issues (perhaps when DHCP Relay is in use?), but it could sensibly solve this problem in other cases.)

Reviewing changes

At some earlier parts of this guide, the guide pointed out some times when updating the “file integrity checker” database may be sensible. There may have been relatively little benefit to updating the database, except that it would allow later reports to be made smaller.

This time, the recommendation is different. This guide does recommend proceeding with making an update to the “file integrity checker” database. That way, a report an show which files have been altered during the customizing of this particular machine.

On the machine running the DHCP/IPv4 server:

Newer method
aidedbup dhcpinit
echo ${PAGER}
aiderpvw | ${PAGER}

(showing AIDE's report)

Older method

This time, there is actually a point to reviewing AIDE's report, other than just going through the process of seeing what a report looks like. Check out the details. The report should provide details that basically describe the activity that occurred on the system. Since this is activity that has been done rather recently, it ends up basically being a report of actions that have been performed recently.

Placing updated files off the boot drive

At this time, files like /etc/dhcpd.conf (which has just been heavily customized) may be stored in /etc/ right alongside other files that have not been updated recently (such as, perhaps, the /etc/fstab and/or /etc/hosts files.)

Updating documentation

In the list of software, go ahead and mention the DHCP server being used (e.g., “OpenBSD's dhcpd based on ISC's”)

(At least for now, this guide doesn't provide documentation about what network traffic is being used. This is because special firewall rules don't need to be added to the standard template, perhaps in part because of DHCP's use of BPF.)

Apply fixes

See also: DHCP Client: Custom Config to fix some issues on other systems.