Zenarmor/Eastpect continuously logging “UDP flow connect failed: Address already

[doug411]

I discovered this while investigating intermittent Internet outages lasting several minutes. The outages may be unrelated, because the Zenarmor/Eastpect errors continue even when connectivity is fully restored and working normally.

The recurring errors are:

WARN [UDPConnectionFlow::connect] ... UDP flow connect failed: Address already in use
CRIT [EastpectInstance::onAcceptUDP] ... New UDP flow connect failed for client

Examples include DNS and QUIC/UDP 443 traffic from multiple clients:

2026-08-20T03:33:26.897766 WARN [UDPConnectionFlow::connect] [CLI][proxmox.internal][10.123.50.10:60009] UDP flow connect failed: Address already in use
2026-08-20T03:33:26.897785 CRIT [EastpectInstance::onAcceptUDP] [UDP://10.123.50.10:60009<->10.123.50.1:53] New UDP flow connect failed for client
2026-08-20T03:34:03.398413 WARN [UDPConnectionFlow::connect] [CLI][10.123.10.147:32832] UDP flow connect failed: Address already in use
2026-08-20T03:34:03.398437 CRIT [EastpectInstance::onAcceptUDP] [UDP://10.123.10.147:32832<->142.251.186.101:443] New UDP flow connect failed for client

The errors are occurring every few seconds across multiple VLANs/devices. During one known-good monitoring period, IP connectivity, DNS resolution, HTTPS access, and active YouTube streaming were all functioning normally while these errors continued.

The messages are found in:

/usr/local/zenarmor/log/active/worker*.log

Zenarmor is attached to vtnet2 and WireGuard interfaces, with policies matched by VLAN ID and/or IP ranges.

Is this expected/benign Eastpect behavior, or does it indicate a socket/UDP flow-handling problem that should be corrected? Also, is there any known condition where a high rate of these failures could contribute to intermittent connectivity loss?


OPNsense: 26.7
Zenarmor: 2.6.2
Zenarmor Agent: 2.6.1

[sy]

Hi,

This issue is triggered during heavy UDP traffic when the client reuses the same source port for new requests. Since Zenarmor maintains UDP state tracking, these duplicate tuple requests initially get blocked due to state collision. However, because the client continuously retries on the same port, the state table clears or re-binds the flow, causing the traffic to pass through anyway.

[doug411]

Thanks, that explains the behavior. Is there any configurable UDP state timeout, flow-table setting, or other recommended mitigation to reduce these collisions, or is this expected behavior that can only be addressed in the Zenarmor engine? In my case the warnings occur continuously and can spike to 700–800 failed UDP flows in a minute during heavy DNS activity

[doug411]

also... I am using NAT port-forward/DNAT rules to redirect client UDP/53 traffic to the local OPNsense DNS resolver. Could this contribute to the reported Eastpect state collisions by causing DNS queries originally destined for different resolvers to collapse onto the same translated 5-tuple when a client reuses a UDP source port?  Is there a way to reduce the volume of the collisions?