How To Install And Configure Kea DHCP Server

Mar 7, 2023 · 12 mins read

How To Install And Configure Kea DHCP Server

In the video below, we show you how to install and configure the Kea DHCP server in Ubuntu or Debian

What we’ll be covering is how to set up a basic DHCP server that supports IPv4

Although there is a lot more you can do with Kea, including monitoring and managing it from a server with a GUI

Useful links:
https://ubuntu.com/download/server
https://code.visualstudio.com/

Assumptions:
Because this video is specifically about how to install and configure the Kea DHCP server, I’m going to assume that you already have a server available with the operating system installed
Kea is supported on multiple Linux distros, but for this video we’re only focusing on the popular Debian based ones
So you’ll either need a server that is running Ubuntu or Debian

Steps Taken:

Switch To Root
Because I want to cover both Ubuntu and Debian, we won’t be using the sudo command and will instead switch to the root account
This is because sudo is not installed by default in Debian
If you’re on an Ubuntu server, to switch to root type
```
sudo su -
```
Then hit return and enter your own password
If you’re on a Debian server, to switch to root type
```
su -
```
Then hit return and enter the root password
Install Dependencies
Now there are different ways to install Kea but what we’ll do is to install the official packages
But first we need to install some dependencies
```
apt install curl apt-transport-https -y
```
Add Repositories
To make sure we use the latest version and not what the OS knows about, the recommendation is to use the ISC repositories
You can either add these manually or use a script that’s been provided
At the time of recording, the current stable version is 2.2 which is reflected in the following command
```
curl -1sLf 'https://dl.cloudsmith.io/public/isc/kea-2-2/setup.deb.sh' | sudo -E bash
```
NOTE: The URL will change as newer versions are released so do make sure to check the documentation page
Install DHCPv4 Server
Now while you can install all of the packages, Kea is modular in design which allows you to install only what you need
For example, I don’t use IPv6, so I can choose to only install an IPv4 DHCP server
What’s good about this is that if there’s a memory leak or security vulnerability in the IPv6 software for instance, it won’t affect this server

WARNING: Installing a DHCP server into an existing network where DHCP already exists will lead to problems so it’s best to do this in a new subnet

To install an IPv4 DHCP server run the following commands
```
apt install isc-kea-dhcp4-server -y
```
To install other modules check the website
Configure DHCP4 Server
Once the DHCP server is installed, it can be configured, using the file located in the /etc/kea folder
```
cd /etc/kea
```
Each package has it’s own configuration file and the IPv4 configuration is held in the kea-dhcp4.conf file
The existing file isn’t practical to administer so we’ll back this one up and use it for reference
```
mv kea-dhcp4.conf kea-dhcp4.conf.bak
```
Then create our own
```
nano kea-dhcp4.conf
```
A basic configuration to support a single subnet would look something like this
```
{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": ["ens160"]
    },

    "lease-database": {
        "type": "memfile",
        "persist": true,
        "name": "/var/lib/kea/kea-leases4.csv",
        "lfc-interval": 3600
    },

    "renew-timer": 15840,
    "rebind-timer": 27720,
    "valid-lifetime": 31680,

    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "172.16.17.10, 172.16.17.11"
        },

        {
            "name": "domain-search",
            "data": "templab.lan"
        }
    ],

    "subnet4": [
        {
            "subnet": "172.16.21.0/24",
            "pools": [ { "pool": "172.16.21.100 - 172.16.21.199" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "172.16.21.254"
                }
            ]
            
            // Add reservations here
        }
        
        // Add subnets here
    ]
}
}
```
NOTE: The file is stored in JSON format and must be formatted correctly. For instance, parameters must be separated by a comma, except for the last one. Bear this in mind, because although ordering may not matter, if you decide to move parameters around you will likely have to delete and add commas where necessary

TIP: A text editor like Visual Studio Code will make this much easier to configure

In the above example we’ve defined the interface to listen on
You can define multiple ones but these should only be ones that are necessary
The server needs to keep a record of IP addresses that it leases to avoid duplication, particularly if the server or service restarts
It is possible for Kea to use an external database to store leases in but in this example we store them in a file on the server itself and this one will have been created during the installation
To reduce the file’s size, by default a cleanup of the database will be performed every 3600 seconds or 1 hour to remove redundant information. But you can change this
Now although we’re actually using the default settings, these are a useful reference and it makes it easier to know what to change at later date if ncessary
Next are timers, which I’ve changed so that a lease will last longer than 8 hours, enough for a typical office day
In a network where computers frequently change, for example a Guest WiFi, you would want a much lower lease time of maybe 1 hour to avoid running out of IP addresses
On the other hand, if computers rarely change you might set this to 24 hours

NOTE: When changing the valid-lifetime setting make sure that the renew-timer is set to 50% of valid-lifetime and the rebind-timer is set to 87.5% of valid-lifetime

Global options have been defined for DNS servers and the domain name search which all subnets will typically use
This saves having to repeat the same information for each individual subnet
As well as defining the available IP addresses available in a pool, DHCP options can also be defined that are specific to the pool, for example the default gateway and these are defined within an option-data block
Options defined here can overide the global options, for example you could set a different DNS server for a subnet
Exit and save the file but change the permissions of the file because we created it using the root account
```
chown _kea:root kea-dhcp4.conf
```
Interestingly enough, the DHCP service is automatically activated when the software is installed Because we’ve made changes to the configuration, we need to restart the service
```
systemctl restart isc-kea-dhcp4-server
```
Check IP Leasing
Aside from checking a computer to see if it has obtained an IP address, you can also check the leasing database, in this example it is a file
```
more /var/lib/kea/kea-leases4.csv
```
TIP: If you want to know a computer’s client-id, check the database. Each record begins with the IP address, followed by the MAC address and then the client-id

TIP: Typically an operating system will only try to obtain an IP address for a short amount of time and then give up. So you can bounce the interface by disabling and then re-enabling it to restart the DHCP process
Reservations
If you need computers to always have the same IP address but you don’t want to manually configure these on the computer itself then you can reserve IP addresses for them in DHCP
To do this you will need to edit the configuration file
```
nano kea-dhcp4.conf
```
And add these to a reservation block, similar to the following example
```
            "reservations": [
                // MAC address reservation
                {
                    "hw-address": "00:0c:29:ac:bb:8f",
                    "ip-address": "172.16.21.30",
                    "hostname": "win1"
                },               
                
                // client-id reservation
                {
                    "client-id": "01:00:0c:29:4c:26:8a",
                    "ip-address": "172.16.21.31",
                    "hostname": "pop-os"
                }
             ]
```
The block is added after a subnet block and for that reason a comma will need to be added after that block’s ]
In this example, one IP address is reserved based on a MAC address and the other using a client-id

NOTE: An IP address which is reserved, must be outside of the pool range

There are other methods available, but these are the most command ways and you can also provide various option data here to a client such as details of a file to download
Client specific DHCP options can also be used to override subnet and/or global options
If DDNS will be used, a hostname for the computer will be needed so that this can be passed to the DNS server
Defining the hostname within the reservation is particularly helpful with situations where the DHCP server does not learn the client’s hostname

NOTE: Hostnames must be unique and it’s best to match what the computer is using. However, if a computer has multiple network interfaces than you could append the network name as an example to distinguish between them

For the changes to take effect, the service needs a restart
```
systemctl restart isc-kea-dhcp4-server
```
Multiple Pools
A DHCP server will typically support multiple networks, each of which will need to be defined
To do this you will need to edit the configuration file
```
nano kea-dhcp4.conf
```
And add a subnet block, similar to the following example
```
       {
            "subnet": "172.16.25.0/24",
            "pools": [ { "pool": "172.16.25.100 - 172.16.25.199" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "172.16.25.254"
                }
            ]
            
            // Add reservations here
        }
```
NOTE: In this case a comma would need to be added after the } of the previous subnet block

Bear in mind, if clients don’t have direct connectivity to a DHCP server and typically they don’t when there are multiple networks, a DHCP relay agent will need to be configured in the network where the clients are to listen for DHCP broadcasts
These broadcasts will then be picked up and relayed directly to the DHCP server
Once an IP address is obtained, a computer will then contact the DHCP server directly for further updates
For the changes to take effect, the service needs a restart
```
systemctl restart isc-kea-dhcp4-server
```
Additional Security
To increase security, the DHCP server should be running a software firewall such as UFW
For example, the following rules restrict SSH and DHCP access
```
To                         Action      From
--                         ------      ----
172.16.21.1 22/tcp         LIMIT       172.16.18.10              
172.16.21.1 67/udp         ALLOW       172.16.21.0/24            
172.16.21.1 67/udp         ALLOW       172.16.25.0/24   
```
When a computer first needs to obtain an IP address, it will send out Layer 2 broadcasts which the firewall can’t restrict
By default, the DHCP the server will allow RAW sockets and listen to these broadcast requests
Unless the DHCP server will service local DHCP requests i.e. requests in the same subnet it is better to disable this behaviour
To do this you will need to edit the configuration file
```
nano kea-dhcp4.conf
```
Then add the following line into the interfaces-config block
```
"dhcp-socket-type": "udp"
```
NOTE: The placement of the comma depends on where the line is placed

With the above line, only UDP sockets will be allowed and this works best when expecting requests only from DHCP relay agents
For the changes to take effect, the service needs a restart
```
systemctl restart isc-kea-dhcp4-server
```
Authoritative Server
By default Kea will remain silent if a client requests an IP address which is from the wrong network
For example, let’s say you have a laptop connected to a network and it has an IP address obtained through DHCP
You then move it to a network where your Kea server is the DCHP server and the IP addressing is different
Kea knows nothing about this other network and so when the laptop tries to renew its IP address, nothing happens. Instead the laptop is stuck because it has an IP address which does not work and is yet to expire
This behaviour is deliberate because Kea does not necessarily know if the IP is wrong
If you want to avoid this you can make Kea an authorotative DHCP server which will force the laptop in this case to lease a new IP address from Kea
To do this you will need to edit the configuration file
```
nano kea-dhcp4.conf
```
Then instert the following line to a subnet, shared-network or global block
```
"authoritative": true
```
NOTE: The placement of the comma depends on where the line is placed

For the changes to take effect, the service needs a restart
```
systemctl restart isc-kea-dhcp4-server
```

Final Configuration Example
The final configuration example looks as follows

{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": ["ens160"],
        "dhcp-socket-type": "udp"
    },
    
    "authoritative": true,

    "lease-database": {
        "type": "memfile",
        "persist": true,
        "name": "/var/lib/kea/kea-leases4.csv",
        "lfc-interval": 3600
    },

    "renew-timer": 15840,
    "rebind-timer": 27720,
    "valid-lifetime": 31680,

    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "172.16.17.10, 172.16.17.11"
        },

        {
            "name": "domain-search",
            "data": "templab.lan"
        }
    ],

    "subnet4": [
        {
            "subnet": "172.16.21.0/24",
            "pools": [ { "pool": "172.16.21.100 - 172.16.21.199" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "172.16.21.254"
                }
            ],

            "reservations": [
                // MAC address reservation
                {
                    "hw-address": "00:0c:29:ac:bb:8f",
                    "ip-address": "172.16.21.30",
                    "hostname": "win1"
                },               
                
                // client-id reservation
                {
                    "client-id": "01:00:0c:29:4c:26:8a",
                    "ip-address": "172.16.21.31",
                    "hostname": "pop-os"
                }
             ]
            
            // Add reservations here
        },

        {
            "subnet": "172.16.25.0/24",
            "pools": [ { "pool": "172.16.25.100 - 172.16.25.199" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "172.16.25.254"
                }
            ]
            
            // Add reservations here
        }
        
        // Add subnets here
    ]

}
}