Lab 04: DHCP - rune-seregina/sys-255-fa24 GitHub Wiki
Objective
In this lab, I configured a DHCP server on my network, and tested configuration and connectivity by using DHCP on my workstation and tracking the exchange using Wireshark.
Vocab:
- DHCP Release: not one of the main 4 functions of DHCP, it is a message sent by the client to the DHCP server to request the release of an IP address that was configured by the DHCP server
- DHCP Discover: this is a broadcast message sent by a client that has not yet been configured by DHCP in order to discover the location (MAC address) of the DHCP server.
- DHCP Offer: After receiving the DHCP Discover message from the client, the DHCP server will broadcast a DHCP offer (must be a broadcast since the client does not yet have an IP address), which contains information on what IP address is available for allocation and other network information.
- DHCP Request: A DHCP Request is a message from the client that requests the available IP address for itself. This is sent as a broadcast to inform all DHCP servers on a network.
- DHCP ACK: The DHCP server sends an acknowledgement to the new address of the client
Resources used:
- cyber.local architecture: basic routed network:
- SYS Labs: https://docs.google.com/document/d/1fGtUcwb7131nRH1fk4nGSGXXOA4GkZb4n1snCJmlGeU/edit#heading=h.hy017y8xp7fo
IP Assignments:
- WAN IP (synonymous with fw interface 1/em0): 10.0.17.112/24
- LAN IP (synonymous with fw interface 2/em1): 10.0.5.2/24
- wks01-rune IP: 10.0.5.100/24 (or as assigned by DHCP)
- wks01/ads01/dhcp01 default gateway: 10.0.5.2/24
- dns: 10.0.5.5/24
- ad01-rune ip: 10.0.5.5/24
- dhcp01-rune ip: 10.0.5.3
Accounts:
- wks01: rune.seregina@rune
- wks01: rune.seregina-admrune
- ad01: rune\administrator
- dhcp01: rune@dhcp01
Configuring DHCP
- install dhcp services
- config file:
- start and check dhcp services (systemctl start dhcpd, systemctl status dhcpd)
- enable service to start on boot (systemctl enable httpd)
- configure firewall to allow dhcp: firewall-cmd --add-service=dhcp --permanent
- restart firewall (firewall-cmd --reload)
Further DHCP Research
- 1) DORA
- as covered in the vocab section, DORA stands for DHCP Discovery, Offer, Request, and ACK. These are the fundamental steps of DHCP, showing the transaction between a client and a server during an initial connection. On Wireshark, this can be explored by viewing the packets, and examining their source and destination IP addresses (which ones are broadcasts and why?) as well as the DHCP header.
- 2) Working with UDP
- DHCP uses UDP as its transport model
- UDP is connectionless - a type of data transmission in which there is no extra "checks" to establish a connection/ensure there is a working receiver. Useful for DHCP since one side of the communication is not yet configured for data transmission
- DP also allows for broadcasts, an important part of the DHCP process
- UDP server port: 67
- UDP client port: 68
- 3) DHCP is an extension of BOOTP
- In Wireshark, evidence of the BOOTP protocol are seen in "Message-Type" and "Bootp flags".
- Basically, Bootp is included in DHCP for backwards compatability.
Troubleshooting
- At first, DHCP was giving me "DHCP failed with exit code 1" errors when trying to start DHCPD. To fix this, I ended up stopping and restarting DHCPD which showed me where the error was when I ran the journalctl -xe command, where it pointed me to a missing semicolon in my config file. When I fixed this, the problem was resolved.
- When changing WKS-01 over to automatic IP configuration, DHCP was not yet enabled. To fix this, I checked the "firewall-cmd --list-all" command to see that DHCP was not properly added to the services. I realized that the first time I reloaded the firewall I used "firewall-cmd --restart" instead of the correct syntax, "firewall-cmd --reload".
- Neither the /var/log/messages nor the /var/log/secure directories existed on dhcp01, even with elevated privileges. Instead, I used "systemctl status dhcpd" to find information on dhcpd and "journalctl -u sshd" to find information on ssh.
Reflection
This lab was a bit trickier as syntax is very easy to get wrong and often hard to troubleshoot where exactly things went wrong. I had some prior experience with DHCP that didn't expand a lot during this lab but I was not aware of the DORA acronym so I am glad to have more experience about the DHCP process using DORA.