Azure Virtual Desktop WSS Agent disconnecting with error "Server has not sent a packet to Tunnel"..."for 32 secs"...."Closing dead tunnel" very often
Article ID: 416426
Updated On:
Products
Issue/Introduction
The customer AVD monitoring team has implemented some WSS Agent logs capture and analysis and since the beginning of September 2025 the reported count of connection failure has grown to unseen levels indicating something no longer operating as needed in the infrastructure.
Environment
WSS Agent
A large count of AVD devices in production egressing to the Internet using Azure firewall and a set of provided Azure ip addresses.
We can see the following type of messages reported at level above 500,000 per day:
Server has not sent a packet to Tunnel#19(DOMAIN\user) for 32 secs (last seen at 2025-09-17T13:19:04Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#18(DOMAIN\user) for 32 secs (last seen at 2025-09-17T12:55:50Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#16(DOMAIN\user) for 32 secs (last seen at 2025-09-17T12:36:03Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#15(non-interactive-user) for 32 secs (last seen at 2025-09-17T12:28:24Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#13(DOMAIN\user) for 32 secs (last seen at 2025-09-17T12:22:46Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#14(non-interactive-user) for 32 secs (last seen at 2025-09-17T12:17:24Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#11(non-interactive-user) for 32 secs (last seen at 2025-09-17T12:10:51Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#12(DOMAIN\user) for 32 secs (last seen at 2025-09-17T12:03:26Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#9(DOMAIN\user) for 32 secs (last seen at 2025-09-17T11:48:21Z). Closing dead tunnel
Server has not sent a packet to Tunnel#10(non-interactive-user) for 32 secs (last seen at 2025-09-17T11:42:38Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#7(non-interactive-user) for 32 secs (last seen at 2025-09-17T11:30:48Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#8(DOMAIN\user) for 32 secs (last seen at 2025-09-17T11:29:40Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#6(DOMAIN\user) for 32 secs (last seen at 2025-09-17T10:36:52Z). Closing dead tunnel.
Server has not sent a packet to Tunnel#5(non-interactive-user) for 32 secs (last seen at 2025-09-17T10:33:58Z). Closing dead tunnel.
Cause
The Azure infrastructure is causing regular failure on the source NAT devices that are causing traffic flows to be expired, removed from the flow table.
In turn this causes the outbound packets from the AVD flow to be dropped on the egress path, so they are not received on the Broadcom infrastructure, equally the Broadcom concentrators are sending traffic back from the proxy tot he AVD source-NAT address and those packets are not seen on the AVD client.
There is also another failure mode that precedes the above failures, whereby the source-NAT egress device starts sending data on the wrong egress flow.
For example:
- Initial state:
- Non-Interactive-User Tunnel is connecting to Cloud SWG on source-port 40000
- Non-Interactive-User Tunnel is source-NATED (using a specific Azure public ip) and connected to Cloud SWG on source-port 45000
- User tunnel is connecting to Cloud SWG on source-port 52000
- User tunnel is source-NATED (using a specific Azure public ip) and connected to Cloud SWG on source-port 57000
- After some times the fault occurs and we have some that resembles this fail case:
- Non-Interactive-User Tunnel is connecting to Cloud SWG on source-port 40000
- Non-Interactive-User Tunnel is source-NATED (using a specific Azure public ip) and traffic is sent to Cloud SWG on port 57000
- User tunnel is connecting to Cloud SWG on source-port 52000
- User tunnel traffic is dropped as the NAT table no longer contains an entry for it
- This ends when:
- User tunnel reconnects after 32 seconds as its egress session is broken
- Non-Interactive-User tunnel reconnects after 32 seconds as the Cloud SWG concentrator cannot decipher the received datagrams received on the incorrect tunnel
Resolution
The problem is appearing on the Azure infrastructure on the egress-NAT device and is currently being investigated by Microsoft.
We have no doubt that this problem will be resolved on their side, but this KB is not going to attempt to track the resolution Azure side, as we are not directly involved in the issue.
Feedback
