{"id":944,"date":"2026-10-26T22:42:08","date_gmt":"2026-10-26T22:42:08","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=944"},"modified":"2026-10-26T22:42:08","modified_gmt":"2026-10-26T22:42:08","slug":"windows-server-rpc-endpoint-mapper-dynamic-port-hardening","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/windows-server-rpc-endpoint-mapper-dynamic-port-hardening\/","title":{"rendered":"RPC Endpoint Mapper and Dynamic Port Ranges: Locking Down Windows Server Firewalls Without Breaking It"},"content":{"rendered":"
\n

Opening TCP 135 on a Windows Server firewall does not enable RPC. Port 135 is only the endpoint mapper: the client asks it which port a given interface is listening on, and the answer is a dynamically allocated port somewhere in the 49152\u201365535 range. Block that range and every RPC call fails with a timeout that looks exactly like a dead server. This page covers how the mapper hands out ports, the registry keys that pin the range, how to scope firewall rules so they follow the service rather than the port, and what breaks when the range is narrowed too far. The same RPC plumbing applies on any hosted guest, including the Windows Server VPS images at windows-vps.org<\/a>.<\/p>\n

Why Port 135 Alone Never Works<\/h2>\n

An RPC client performs a three-step dance. It connects to the endpoint mapper on TCP 135, sends the interface UUID and version it wants, and receives back a port number. It then opens a second connection to that port, which was chosen at boot from the dynamic range. A firewall that permits 135 and denies 49152\u201365535 allows the first step and blocks the second, so the error surfaces as RPC server is unavailable<\/code> after a 30\u201360 second timeout rather than a clean refusal.<\/p>\n

# See what the mapper hands out right now\nGet-NetTCPConnection -State Listen | Where-Object {$_.LocalPort -ge 49152} |\n  Sort-Object LocalPort | Select LocalAddress,LocalPort,OwningProcess |\n  ForEach-Object { $_ | Add-Member -PassThru NoteProperty Proc (Get-Process -Id $_.OwningProcess).Name }<\/code><\/pre>\n
Well-known RPC services get their own reserved ports. Everything else \u2014 DCOM servers, third-party backup agents, custom service hosts \u2014 lands in the dynamic range and moves after a reboot unless it is pinned.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Service<\/th>\nPort<\/th>\nNotes<\/th>\n<\/tr>\n<\/thead>\n
Endpoint mapper<\/td>\n135 TCP<\/td>\nAlways required, both directions for cross-server RPC<\/td>\n<\/tr>\n
WMI \/ DCOM (Winmgmt)<\/td>\n135 + dynamic<\/td>\nWMI over DCOM cannot be pinned; use WinRM instead<\/td>\n<\/tr>\n
Netlogon<\/td>\n445, 135, 49152+<\/td>\nDomain join and secure channel need the dynamic range<\/td>\n<\/tr>\n
DFS Replication<\/td>\n5722, 135<\/td>\nPlus dynamic RPC for the management interface<\/td>\n<\/tr>\n
Hyper-V management<\/td>\n2179, 135, dynamic<\/td>\nVMMS uses dynamic ports for the VMI<\/td>\n<\/tr>\n
Backup agents (most)<\/td>\n135 + vendor port<\/td>\nCheck vendor docs; many also need 445<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Pinning the Dynamic Range<\/h2>\n
Windows Server 2008 and later default the ephemeral range to 49152\u201365535. Narrowing it to a block you can firewall is done with two registry values under HKLM\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters<\/code>. The format is a 32-bit value where the high 16 bits are the start port and the low 16 bits are the count.<\/p>\n
$start = 5000; $count = 1000\n$val = ($start -shl 16) -bor $count\nSet-ItemProperty 'HKLM:\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters' -Name TcpipDynamicPortRange -Value $val -Type DWord\n# netsh equivalent, same effect, reboot required\nnetsh int ipv4 set dynamicport tcp start=5000 num=1000\nnetsh int ipv4 set dynamicport udp start=5000 num=1000\nnetsh int ipv4 show dynamicport tcp<\/code><\/pre>\n
A range of 1000 ports is comfortable for a single-role server. Do not go below 500: port exhaustion under load produces WSAEADDRINUSE<\/code> failures in event log and TCP connect errors that have nothing to do with the firewall.<\/p>\n
Reserving a specific port for a specific RPC interface is a separate mechanism. Each interface registers under its own key and the Ports<\/code> subkey, with a Ports<\/code> REG_MULTI_SZ naming the interfaces:<\/p>\n
$k = 'HKLM:\\SOFTWARE\\Microsoft\\Rpc\\Internet'\nNew-Item $k -Force | Out-Null\nNew-ItemProperty $k -Name Ports -PropertyType MultiString -Value @('5000-5999') -Force\nNew-ItemProperty $k -Name PortsInternetAvailable -Value 'Y' -PropertyType String -Force\nNew-ItemProperty $k -Name UseInternetPorts -Value 'Y' -PropertyType String -Force<\/code><\/pre>\n
This key is the one most documentation refers to, and it must agree with the Tcpip value \u2014 a mismatch causes the service to fall back to a random port outside both ranges.<\/p>\n
Scoping Firewall Rules to the Service, Not the Range<\/h2>\n
The cleaner approach on modern Windows is to let the firewall follow the process. A rule with -Program<\/code> and a dynamic local port matches only traffic owned by that executable, which means the dynamic range can stay open on the local side without exposing every RPC server on the box.<\/p>\n
New-NetFirewallRule -DisplayName 'RPC - Backup Agent' -Direction Inbound -Action Allow `\n  -Protocol TCP -LocalPort 135,49152-65535 -RemoteAddress 10.20.0.0\/24 `\n  -Program 'C:\\Program Files\\Vendor\\agent.exe' -Profile Domain,Private\n\nNew-NetFirewallRule -DisplayName 'RPC - Admin subnet' -Direction Inbound -Action Allow `\n  -Protocol TCP -LocalPort 135 -RemoteAddress 10.20.0.0\/24 -Profile Domain,Private<\/code><\/pre>\n
Restrict by -RemoteAddress<\/code> before you restrict by port. The majority of RPC exposure on a VPS is not a port range problem, it is that 135 and 445 are reachable from the public internet. Scoping to the management subnet removes the risk without touching the range at all.<\/p>\n