Messages

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?

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

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