S
stevenshell
When managing an Azure Virtual Network (VNet), understanding the intricacies of different ports and their functions is crucial. One often overlooked but vital port is UDP port 65330. This article delves into why awareness of UDP port 65330 is essential. The connectivity will impact ANYTHING using UDP port 65530, however, for this article I am going to discuss how it impacts DNS resolution, as that is a vital core service that relies on UDP for communication.
Azure VNets are designed to facilitate secure and efficient communication between your resources. UDP Port 65330 is a reserved host port on all Azure VNets. Because this port is reserved, ANY communication attempted on this port will be blocked by the VNet. Azure Virtual Network FAQ. DNS primarily uses UDP for most of its operations, including name resolution.
UDP Port 65330 is a high number ephemeral port and is used for both clients and servers to initiate network connections. Your DNS Servers (and clients) can use these ephemeral ports to establish connections to the Azure DNS provider (168.63.129.16) or your own DNS servers running on Azure VM’s, or another custom DNS Solution. DNS name resolution communication will use dynamic UDP port 65330 as the “Source” port to attempt to establish a connection to the DNS server (Azure or Custom).
The default UDP port range for the Windows Operating System is ports 49152 through 65535, which is a total of 16383 available UDP high ports to choose from. When a DNS Server, or DNS Client initiates an outbound DNS request one of the UDP source ports available will be 65330. This means that potentially 1 out of every 16383 requests will fail because Azure will block the request entirely because the request is using UDP port 65330 to initiate a connection to the Azure DNS Service. Service overview and network port requirements - Windows Server | Microsoft Learn. Because of this you may be experiencing random DNS resolution failures, which can lead to communication issues between services in your environment (EX. connecting to Azure Private Endpoints)
Failed DNS requests and timeouts can be a significant headache, leading to delays and failures in resolving domain names. The solution to this is to prevent Windows systems from attempting to use the ephemeral UDP port 65330. This change should be completed on every Windows system (containers included) running in an Azure VNet. Here are steps to mitigate this issue:
You can execute the command below to disable the ability for Windows to use port 65330 to initiate network related requests.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Continue reading...
Why UDP Port 65330 Matters
Azure VNets are designed to facilitate secure and efficient communication between your resources. UDP Port 65330 is a reserved host port on all Azure VNets. Because this port is reserved, ANY communication attempted on this port will be blocked by the VNet. Azure Virtual Network FAQ. DNS primarily uses UDP for most of its operations, including name resolution.
UDP Port 65330 is a high number ephemeral port and is used for both clients and servers to initiate network connections. Your DNS Servers (and clients) can use these ephemeral ports to establish connections to the Azure DNS provider (168.63.129.16) or your own DNS servers running on Azure VM’s, or another custom DNS Solution. DNS name resolution communication will use dynamic UDP port 65330 as the “Source” port to attempt to establish a connection to the DNS server (Azure or Custom).
How does this impact my network communication?
The default UDP port range for the Windows Operating System is ports 49152 through 65535, which is a total of 16383 available UDP high ports to choose from. When a DNS Server, or DNS Client initiates an outbound DNS request one of the UDP source ports available will be 65330. This means that potentially 1 out of every 16383 requests will fail because Azure will block the request entirely because the request is using UDP port 65330 to initiate a connection to the Azure DNS Service. Service overview and network port requirements - Windows Server | Microsoft Learn. Because of this you may be experiencing random DNS resolution failures, which can lead to communication issues between services in your environment (EX. connecting to Azure Private Endpoints)
OK, So now what?
Failed DNS requests and timeouts can be a significant headache, leading to delays and failures in resolving domain names. The solution to this is to prevent Windows systems from attempting to use the ephemeral UDP port 65330. This change should be completed on every Windows system (containers included) running in an Azure VNet. Here are steps to mitigate this issue:
Disable Windows systems from attempting to use port 65330
You can execute the command below to disable the ability for Windows to use port 65330 to initiate network related requests.
netsh int ipv4 add excludedportrange udp 65330 1 persistentValidate that you have UDP port 65330 disabled on Windows
netsh int ipv4 show excludedportrange udpIf you need to undo/delete this Windows port reservation (rollback scenario)
netsh int ipv4 delete excludedportrange udp 65330 1 persistentDisclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Continue reading...