---
title: "IPv6 filtering and DHCPv6"
slug: "kea-dhcpv6-doesnt-get-incoming-traffic"
description: "Many operating systems include firewalls that discard incoming IPv6 traffic by default."
tags: ["DHCPv6", "IP6tables", "kea dhcp"]
updated: 2023-08-28T21:08:47Z
published: 2023-08-28T21:08:47Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#interface-configuration) 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.

          Check all alerts or temporarily disable SELinux

          

If you are not able to find any messages specific to Kea, and you still believe it is SELinux causing the problem, you can check all SELinux messages with this command:

```
sudo sealert -l "*"
```

If, after looking through these messages, you still don't find anything related to Kea, then it may not be SELinux causing the problem. You can temporarily disable SELinux to see if that helps:

```
sudo setenforce 0
```

which should set enforcement to `Permissive`. This will not survive a reboot, however.