Kea fails to receive incoming traffic

Kea fails to receive incoming traffic

Question: Kea doesn't seem to get incoming traffic. I checked with tcpdump (or other traffic capture software) that the incoming traffic is reaching the box. What's wrong?

iptables / ip6tables

Please check whether your OS has any IPv4 or IPv6 filtering rules. Some operating systems are shipped with firewalls that discard incoming IPv6 traffic by default or block IPv4-based listeners.

For DHCPv6, please check the output of the following command:

sudo ip6tables -L -n

Unfiltered output would result in a response like this:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

One common mistake is to use the iptables tool, which lists only IPv4 firewall rules.

For DHCPv4, the command is sudo iptables -L -n, which will give similar output. It is much less likely that the firewall would be a problem for DHCPv4, since Kea listens using raw sockets unless "dhcp-socket-type": "udp" is set in the interfaces-config block. See here for details.

Red Hat's firewall

More recently, some distributions, such as Red Hat Enterprise Linux, have begun using "nftables". The configured rules can be checked using the nft utility by issuing the following command:

sudo nft list ruleset

The resulting output is quite large, and interpretation of this output is outside the scope of this document.

apparmor and SELinux

Another roadblock to sending and receiving packets may be "apparmor" (Debian compatible) or "SELinux" (Red Hat compatible). These software packages are meant to prevent unauthorized applications from accessing network or local resources without the administrator's knowledge.

apparmor

Check whether apparmor is enabled by executing this command:

sudo apparmor_status

which will show something similar to the following, if enabled:

apparmor module is loaded.
63 profiles are loaded.
45 profiles are in enforce mode.

followed by a list of the profiles that are loaded. To check if apparmor denied a Kea application from performing some action, use dmesg to show kernel logs; look for messages containing the text apparmor="DENIED". How to allow the denied Kea application to perform the necessary action is beyond the scope of this document.

SELinux

To check whether SELinux is enabled and enforcing, execute:

getenforce

where the output may be something similar to:

Enforcing

To find out if SELinux blocked something a Kea application tried to do, use ausearch:

sudo ausearch -m AVC,USER_AVC -ts recent

which might print a message starting with something similar to this partial output:

time->Mon Aug 21 14:24:24 2023
type=AVC msg=audit(1455805464.059:137): avc:  denied 

Look for the text "comm" in the output. It should be one of the Kea processes (e.g., kea-dhcp6) in this case. If something is found, use journalctl to gather more details about the message:

journalctl -t setroubleshoot --since=14:20

The resultant output will contain more detail, including a suggested command to run, such as: "run sealert -l e9d8fa2e-3608-4ffa-9e72-31a1b85e460b".

Use sealert, as suggested, to learn more about the message:

sudo sealert -l e9d8fa2e-3608-4ffa-9e72-31a1b85e460b

The output from this command will likely give some clue as to how to actually resolve the problem.

sudo sealert -l "*"

sudo setenforce 0