Page MenuHomeVyOS Platform
Create Task
Maniphest T8547

Random DHCPNAK and Connectivity issues after migrating from v1.3.8 (ISC) to v1.5.0 (Kea) - failed to select a subnet for incoming packet
Closed, DuplicatePublicBUG
Actions

Description

Hello everyone,

I’m currently testing a migration from VyOS v1.3.8 (rolling) to VyOS v1.5.0 (latest). This migration involves the transition from ISC DHCP to Kea DHCP.

Scenario:
The environment consists almost entirely of Ricoh printers. In v1.3.8, everything works flawlessly. However, in v1.5.0, printers start failing randomly.

Symptoms:

  • A printer that was working fine suddenly loses access to HTTP, SMB, and Printing services.
  • The printer still responds to ICMP (ping) perfectly.
  • Checking the logs, I see a constant loop of DHCPACK followed immediately by DHCPNAK for the same client.
  • If I roll back to v1.3.8, the issue disappears instantly.

Network Topology:

  • VLAN 128 (Printers): 10.1.128.0/22
  • Address Group/Static Mappings are heavily used.
  • VyOS Interface: eth0.128 with IP 10.1.128.1/22.

Relevant Configuration:

set interfaces ethernet eth0 vif 128 address '10.1.128.1/22'
set interfaces ethernet eth0 vif 128 description 'LAN_PRINTERS'

set service dhcp-server listen-interface 'eth0.128'

set service dhcp-server shared-network-name LAN_PRINTERS authoritative
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 lease '3600'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 option default-router '10.1.128.1'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 option domain-name 'test.com'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 option name-server '10.1.128.1'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 range 0 start '10.1.130.200'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 range 0 stop '10.1.130.250'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 static-mapping 10.1.128.10-IMP-1 ip-address '10.1.128.10'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 static-mapping 10.1.128.10-IMP-1 mac '06:09:64:XX:XX:XX'

(...)

set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 static-mapping 10.1.128.100-IMP-100 ip-address '10.1.128.100'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 static-mapping 10.1.128.100-IMP-100 mac '58:38:79:XX:XX:XX'
set service dhcp-server shared-network-name LAN_PRINTERS subnet 10.1.128.0/22 subnet-id '128'

set service dns forwarding allow-from '10.1.128.0/22'
set service dns forwarding cache-size '0'
set service dns forwarding dhcp 'eth0.128'
set service dns forwarding listen-address '10.1.128.1'
set service dns forwarding name-server 8.8.8.8
set service dns forwarding name-server 1.1.1.1
set service dns forwarding system

Logs ("Loop"):
When the failure occurs, Kea logs show it successfully allocates the lease, but then fails to select the subnet for the subsequent DHCPREQUEST from the same IP it just assigned:

Apr 23 20:56:51 kea-dhcp4[6367]: INFO [kea-dhcp4.leases] DHCP4_LEASE_ALLOC ... lease 10.1.128.50 has been allocated
Apr 23 20:56:53 kea-dhcp4[6367]: ERROR [kea-dhcp4.bad-packets] DHCP4_PACKET_NAK_0001 ... failed to select a subnet for incoming packet, src 10.1.128.50, type DHCPREQUEST
Apr 23 20:56:53 kea-dhcp4[6367]: INFO [kea-dhcp4.packets] DHCP4_PACKET_SEND ... trying to send packet DHCPNAK (type 6) from 10.1.128.1:67 to 10.1.128.50:68

Additionally, I see these errors regarding the socket filter:

DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Pkt4FilterLpf to receive UDP4 data

Questions:

  1. Is there a known issue with Kea and /22 (or larger) subnets when using many static mappings in VyOS 1.5?
  2. Why would Kea fail to "select a subnet" for a RENEW/REQUEST of an IP that belongs to the subnet it's listening on?
  3. Could the Pkt4FilterLpf error indicate an issue with how VyOS 1.5 handles LPF (Linux Packet Filtering) on VIF interfaces?

Any help or insight would be greatly appreciated before I have to officially abandon the 1.5 migration.

Complete LOG:

Apr 23 20:13:24 kea-dhcp4[6367]: 2026-04-23 20:13:24.455 ERROR [kea-dhcp4.packets/6367.140710936632320] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Pkt4FilterLpf to receive UDP4 data
(...)
Apr 23 20:55:42 kea-dhcp4[6367]: 2026-04-23 20:55:42.166 ERROR [kea-dhcp4.bad-packets/6367.140710885787328] DHCP4_PACKET_NAK_0001 [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0x146: failed to select a subnet for incoming packet, src 10.1.128.50, type DHCPREQUEST
Apr 23 20:55:42 kea-dhcp4[6367]: 2026-04-23 20:55:42.167 INFO  [kea-dhcp4.packets/6367.140710885787328] DHCP4_PACKET_SEND [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0x146: trying to send packet DHCPNAK (type 6) from 10.1.128.1:67 to 10.1.128.50:68 on interface eth0.128
Apr 23 20:56:51 kea-dhcp4[6367]: 2026-04-23 20:56:51.955 INFO  [kea-dhcp4.leases/6367.140710877394624] DHCP4_LEASE_ALLOC [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0x18c: lease 10.1.128.50 has been allocated for 3600 seconds
Apr 23 20:56:51 kea-dhcp4[6367]: 2026-04-23 20:56:51.956 INFO  [kea-dhcp4.leases/6367.140710877394624] DHCP4_LEASE_REUSE [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0x18c: lease 10.1.128.50 has been reused for 3529 seconds
Apr 23 20:56:53 kea-dhcp4[6367]: 2026-04-23 20:56:53.496 INFO  [kea-dhcp4.packets/6367.140710894180032] DHCP4_PACKET_RECEIVED [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0x18d: DHCPREQUEST (type 3) received from 10.1.128.50 to 10.1.128.1 on interface eth0.128
Apr 23 20:56:53 kea-dhcp4[6367]: 2026-04-23 20:56:53.496 ERROR [kea-dhcp4.bad-packets/6367.140710894180032] DHCP4_PACKET_NAK_0001 [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0x18d: failed to select a subnet for incoming packet, src 10.1.128.50, type DHCPREQUEST
Apr 23 20:56:53 kea-dhcp4[6367]: 2026-04-23 20:56:53.497 INFO  [kea-dhcp4.packets/6367.140710894180032] DHCP4_PACKET_SEND [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0x18d: trying to send packet DHCPNAK (type 6) from 10.1.128.1:67 to 10.1.128.50:68 on interface eth0.128
Apr 23 20:57:31 kea-dhcp4[6367]: 2026-04-23 20:57:31.414 INFO  [kea-dhcp4.leases/6367.140710902572736] DHCP4_LEASE_ALLOC [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xb4: lease 10.1.128.50 has been allocated for 3600 seconds
Apr 23 20:57:31 kea-dhcp4[6367]: 2026-04-23 20:57:31.414 INFO  [kea-dhcp4.leases/6367.140710902572736] DHCP4_LEASE_REUSE [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xb4: lease 10.1.128.50 has been reused for 3489 seconds
Apr 23 20:57:32 kea-dhcp4[6367]: 2026-04-23 20:57:32.967 INFO  [kea-dhcp4.packets/6367.140710885787328] DHCP4_PACKET_RECEIVED [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xb6: DHCPREQUEST (type 3) received from 10.1.128.50 to 10.1.128.1 on interface eth0.128
Apr 23 20:57:32 kea-dhcp4[6367]: 2026-04-23 20:57:32.967 ERROR [kea-dhcp4.bad-packets/6367.140710885787328] DHCP4_PACKET_NAK_0001 [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xb6: failed to select a subnet for incoming packet, src 10.1.128.50, type DHCPREQUEST
Apr 23 20:57:32 kea-dhcp4[6367]: 2026-04-23 20:57:32.967 INFO  [kea-dhcp4.packets/6367.140710885787328] DHCP4_PACKET_SEND [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xb6: trying to send packet DHCPNAK (type 6) from 10.1.128.1:67 to 10.1.128.50:68 on interface eth0.128
Apr 23 20:57:59 kea-dhcp4[6367]: 2026-04-23 20:57:59.733 INFO  [kea-dhcp4.leases/6367.140710877394624] DHCP4_LEASE_ALLOC [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xd1: lease 10.1.128.50 has been allocated for 3600 seconds
Apr 23 20:57:59 kea-dhcp4[6367]: 2026-04-23 20:57:59.733 INFO  [kea-dhcp4.leases/6367.140710877394624] DHCP4_LEASE_REUSE [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xd1: lease 10.1.128.50 has been reused for 3461 seconds
Apr 23 20:58:01 kea-dhcp4[6367]: 2026-04-23 20:58:01.263 INFO  [kea-dhcp4.packets/6367.140710894180032] DHCP4_PACKET_RECEIVED [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xd2: DHCPREQUEST (type 3) received from 10.1.128.50 to 10.1.128.1 on interface eth0.128
Apr 23 20:58:01 kea-dhcp4[6367]: 2026-04-23 20:58:01.264 ERROR [kea-dhcp4.bad-packets/6367.140710894180032] DHCP4_PACKET_NAK_0001 [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xd2: failed to select a subnet for incoming packet, src 10.1.128.50, type DHCPREQUEST
Apr 23 20:58:01 kea-dhcp4[6367]: 2026-04-23 20:58:01.264 INFO  [kea-dhcp4.packets/6367.140710894180032] DHCP4_PACKET_SEND [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xd2: trying to send packet DHCPNAK (type 6) from 10.1.128.1:67 to 10.1.128.50:68 on interface eth0.128
Apr 23 20:58:27 kea-dhcp4[6367]: 2026-04-23 20:58:27.985 INFO  [kea-dhcp4.leases/6367.140710902572736] DHCP4_LEASE_ALLOC [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xed: lease 10.1.128.50 has been allocated for 3600 seconds
Apr 23 20:58:27 kea-dhcp4[6367]: 2026-04-23 20:58:27.985 INFO  [kea-dhcp4.leases/6367.140710902572736] DHCP4_LEASE_REUSE [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xed: lease 10.1.128.50 has been reused for 3433 seconds
Apr 23 20:58:29 kea-dhcp4[6367]: 2026-04-23 20:58:29.524 INFO  [kea-dhcp4.packets/6367.140710885787328] DHCP4_PACKET_RECEIVED [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xee: DHCPREQUEST (type 3) received from 10.1.128.50 to 10.1.128.1 on interface eth0.128
Apr 23 20:58:29 kea-dhcp4[6367]: 2026-04-23 20:58:29.524 ERROR [kea-dhcp4.bad-packets/6367.140710885787328] DHCP4_PACKET_NAK_0001 [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xee: failed to select a subnet for incoming packet, src 10.1.128.50, type DHCPREQUEST
Apr 23 20:58:29 kea-dhcp4[6367]: 2026-04-23 20:58:29.524 INFO  [kea-dhcp4.packets/6367.140710885787328] DHCP4_PACKET_SEND [hwtype=1 58:38:79:xx:xx:xx], cid=[01:58:38:79:xx:xx:xx], tid=0xee: trying to send packet DHCPNAK (type 6) from 10.1.128.1:67 to 10.1.128.50:68 on interface eth0.128

Apr 23 20:58:44 vyos-configd[732]: Received message: {"type": "init"}
Apr 23 20:58:47 vyos-configd[732]: config session pid is 7462
Apr 23 20:58:47 vyos-configd[732]: config session sudo_user is admin
Apr 23 20:58:47 vyos-configd[732]: commit_scripts: ['interfaces_ethernet_eth0']
Apr 23 20:58:47 vyos-configd[732]: Received message: {"type": "node", "last": true, "data": "VYOS_TAGNODE_VALUE=eth0/usr/libexec/vyos/conf_mode/interfaces_ethernet.py"}
Apr 23 20:58:49 netplugd[4646]: eth0.128: state ACTIVE flags 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,10000 -> 0x00001002 BROADCAST,MULTICAST
Apr 23 20:58:49 netplugd[7786]: /etc/netplug/netplug eth0.128 probe -> pid 7786
Apr 23 20:58:49 kea-dhcp4[6367]: 2026-04-23 20:58:49.290 ERROR [kea-dhcp4.packets/6367.140710936632320] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Pkt4FilterLpf to receive UDP4 data
Apr 23 20:58:49 netplugd[4646]: eth0.128: state PROBING pid 7786 exited status 256
Apr 23 20:58:49 netplugd[4646]: Could not bring eth0.128 back up
Apr 23 20:58:49 vyos-configd[732]: [interfaces_ethernet]
Apr 23 20:58:49 vyos-configd[732]: scripts_called: ['interfaces_ethernet_eth0']
Apr 23 20:58:49 vyos-configd[732]: Sending reply: SUCCESS with output

Details

Version
1.5.0
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

danielcshn created this task.Apr 24 2026, 12:55 AM
danielcshn changed the edit policy from "Custom Policy" to "Maintainers (Project)".Apr 24 2026, 12:55 AM
pasik subscribed.Apr 24 2026, 6:22 AM
Viacheslav assigned this task to sarthurdev.Apr 24 2026, 10:01 AM
Viacheslav triaged this task as High priority.
danielcshn added a comment.Apr 26 2026, 6:11 PM

I have performed a final set of aggressive tests to rule out any network or mask calculation issues. The results confirm a deep-seated logic error in Kea's unicast handling on VyOS 1.5.0.

I downgraded the entire interface and DHCP configuration to a standard /24 (10.1.148.0/24). Even with this simple setup, the failure persists exactly as before:

  • Broadcast REQUEST (from 0.0.0.0): Kea accepts it, allocates the lease, and sends an ACK.
  • Unicast REQUEST (from 10.1.148.50): Received immediately after via the same interface (eth0.148), but Kea fails with failed to select a subnet and issues a NAK.

Additional Parameters Tested (No change):

I applied the following settings to try and stabilize the unicast handshake:

  • server-identifier '10.1.148.1': To force Kea to recognize itself as the valid destination for unicast.
  • ignore-client-id: To prevent discrepancies between the MAC reservation and the client-id provided in the unicast stage.
  • ping-check: Enabled to monitor the client's state.

Observed Behavior:

The client (Ricoh printer) actually "takes" the IP after the first ACK and responds to ICMP, but the subsequent NAK from Kea effectively kills the session for all other services (HTTP/Printing/SMB). The printer enters a "zombie state" where it has an IP but no authorized DHCP lease.

Final Verification (Rollback):

By simply disabling the VIF on the 1.5.0 node and enabling it on a 1.3.8 (ISC DHCP) node with the exact same /22 configuration and hardware, everything works instantly. Both VyOS routers (v1.3.8 and v1.5.0) are running as Virtual Machines on Proxmox VE.

sarthurdev added a comment.Apr 28 2026, 12:38 PM

Have you tested this behaviour in rolling as well?

We have reverted a faulty Kea patch affecting subnet selection.

matthew subscribed.Apr 28 2026, 1:44 PM
danielcshn added a comment.Apr 28 2026, 6:51 PM

Hi,

I have tested all three current branches, and here are my findings:

  • VyOS 1.5.0 GA (TLS): The issue is persistent here. It seems the fix/revert you mentioned hasn't reached the TLS release yet, even though it includes Kea v3.0.3.
  • VyOS Stream 2026.03: Works fine (Subnet selection is OK), but it uses Kea v3.0.2, which is vulnerable to CVE-2026-3608.
  • VyOS Rolling 2026.04.13: Works perfectly. This confirms that the 'revert' you mentioned is active and working in the rolling branch.

It’s quite concerning that the TLS release (which is supposed to be the stable production target) includes the security update to Kea 3.0.3 but lacks the critical patch/revert for subnet selection on VIF interfaces.

Are there any plans to backport this revert to the 1.5.0 TLS immediately? Using a Nightly/Rolling build for a production environment. Is there an ETA for VyOS Stream 2026.04?

sarthurdev closed this task as Not Applicable.Apr 29 2026, 10:48 AM

Thanks for checking that. To get help resolving this under the LTS image I would recommend putting in a support ticket.

As this is due to the faulty Kea patch and that has already been resolved, I'll close this task.

sarthurdev closed this task as a duplicate of T8472: Kea DHCPv4 - failed to a select a subnet for incoming packet.Apr 29 2026, 10:49 AM