VPN Gateway: Persistent Connectivity Issue Despite Connection Status Indicating Connected

Question

VPN Gateway: Persistent Connectivity Issue Despite Connection Status Indicating Connected

Chris Windle 0

Problem description

I am experiencing an ongoing issue with my Azure VPN Gateway, where the site-to-site VPN has been out of service for 4 days. Although the connection status shows as connected, it is not transmitting any traffic.

Environment

Azure VPN Gateway for a site-to-site VPN connection; on-premises device: Ubiquiti Dream Machine; traffic tested between private networks in Azure and on-premises.

What I've already tried

I have documented the start time of the issue, device types, and the symptom of a connected tunnel not passing traffic. No support response or configuration changes are recorded in the case. I have reviewed Azure's guidance on troubleshooting connected VPNs that do not pass traffic, including verifying peer IP definitions, route tables, shared keys, and traffic selectors. I have also reset the Azure VPN Gateway and restarted the on-premises VPN device without success. Additionally, I have verified routing, network configurations, and tunnel definitions, and I am aware of recent Azure maintenance events that do not explain the prolonged outage.

Current status

I am seeking assistance from Microsoft to investigate the underlying cause of the traffic failure, specifically whether Azure VPN Gateway is receiving UDP 4500 IKE_AUTH requests from my on-premises gateway. I need confirmation on packet receipt, details on the negotiation failure indicated by error 0x35ED, and guidance on resolving the issue to restore traffic flow.

0 comments

1 answer

Your answer

Answer 1

Hi @Chris Windle

You don't have to wait for support to find out whether Azure is receiving your IKE_AUTH packets. VPN Gateway has two built-in tools that show exactly that. Error 0x35ED (13805) is the IKE "negotiation timed out" code, which usually means one side sent its packets and never got a reply. These tools will show which side went quiet.

Option A: IKE diagnostic logs (easiest to read)

On the virtual network gateway, open Diagnostic settings and send IKEDiagnosticLog and TunnelDiagnosticLog to a Log Analytics workspace.
Let it run for 10 to 15 minutes while the UDM tries to connect.
Run the sample query from Microsoft's doc (Category == "IKEDiagnosticLog") and filter on your on-premises public IP.
Read the prefixes: [RECEIVED] lines are packets that reached Azure from your UDM, [SEND] lines are Azure's replies. If you see SA_INIT but no [RECEIVED] IKE_AUTH on port 4500, the UDP 4500 traffic isn't reaching Azure.

Option B: packet capture on the connection

In Azure PowerShell, run Start-AzVirtualNetworkGatewayConnectionPacketCapture against the connection, with a filter on your on-premises public IP.
Leave it for at least 10 minutes (Microsoft's suggested minimum), then stop it with Stop-AzVirtualNetworkGatewayConnectionPacketCapture and a SAS URL for a storage container.
Open the PCAP in Wireshark and filter on udp.port == 4500.

If the packets never arrive, look at the path on your side. Check whether the ISP changed your public IP (it must still match the Local Network Gateway), whether a modem or router in front of the UDM is now doing NAT, and whether a recent UniFi firmware update changed the IKE settings. If they arrive and Azure replies but the UDM never answers, the problem is on the UDM.

Does your UDM have a public IP directly on its WAN port, or does it sit behind an ISP modem/router?

If the logs show where the IKE_AUTH exchange stops, please consider accepting it as the answer. If Azure is receiving everything and still timing out, let me know and I'll be happy to keep helping.

Reference: