Skip to content

MSSQL Firewall Script: PowerShell and netsh

Technical Article

Drop-in firewall scripts that open the common Microsoft SQL Server, Analysis Services, and Service Broker ports. PowerShell (recommended) and netsh advfirewall versions, plus the original 2013 batch script for reference.

Categories
MicrosoftAutomation
Tags
FirewallSql ServerPowershellNetshServer Ports
MSSQL Firewall Script: PowerShell and netsh

When standing up a new SQL Server, a common chore is opening the right Windows Firewall ports so clients, brokers, and management tools can reach the engine. This article gives three drop-in versions of the script:

  1. PowerShell: the recommended approach for any supported Windows version.
  2. netsh advfirewall: the modern command-line equivalent.
  3. netsh firewall (legacy): the original 2013 script, kept here for historical reference.

Run as Administrator. All three scripts modify host firewall policy and need an elevated console.

Ports the script opens

PortProtocolService
1433TCPSQL Server default instance
1434TCPDedicated Admin Connection (DAC)
4022TCPSQL Service Broker
135TCPTransact-SQL Debugger / RPC
2383TCPSSAS default instance
2382TCPSQL Server Browser Service (named instance discovery)
80TCPHTTP (for HTTP endpoints / Reporting Services)
443TCPHTTPS / SSL
1434UDPSQL Browser enumeration

Trim or extend the list to match what your instance actually exposes. The Browser Service ports are only needed for named-instance discovery; on a default-instance-only server you can drop them.

Works on Windows Server 2012 R2 and later, and any Windows 10 / 11 client. Uses the NetSecurity module's New-NetFirewallRule cmdlet. The script is idempotent: re-running it skips rules that already exist instead of duplicating them.

#requires -RunAsAdministrator
# Opens common Microsoft SQL Server and SSAS ports.
# Compatible with Windows Server 2012 R2+ and Windows 10/11.

$rules = @(
    @{ Name = 'SQL Server (TCP 1433)';        Port = 1433; Protocol = 'TCP'; Description = 'SQL Server default instance' },
    @{ Name = 'SQL DAC (TCP 1434)';           Port = 1434; Protocol = 'TCP'; Description = 'Dedicated Admin Connection' },
    @{ Name = 'SQL Service Broker (TCP 4022)';Port = 4022; Protocol = 'TCP'; Description = 'SQL Service Broker' },
    @{ Name = 'SQL Debugger / RPC (TCP 135)'; Port = 135;  Protocol = 'TCP'; Description = 'Transact-SQL Debugger / RPC' },
    @{ Name = 'SSAS (TCP 2383)';              Port = 2383; Protocol = 'TCP'; Description = 'Analysis Services default instance' },
    @{ Name = 'SQL Browser (TCP 2382)';       Port = 2382; Protocol = 'TCP'; Description = 'SQL Server Browser Service' },
    @{ Name = 'HTTP (TCP 80)';                Port = 80;   Protocol = 'TCP'; Description = 'HTTP' },
    @{ Name = 'HTTPS (TCP 443)';              Port = 443;  Protocol = 'TCP'; Description = 'HTTPS / SSL' },
    @{ Name = 'SQL Browser (UDP 1434)';       Port = 1434; Protocol = 'UDP'; Description = 'SQL Browser enumeration' }
)

foreach ($rule in $rules) {
    if (Get-NetFirewallRule -DisplayName $rule.Name -ErrorAction SilentlyContinue) {
        Write-Host "Rule already exists: $($rule.Name)" -ForegroundColor Yellow
        continue
    }

    New-NetFirewallRule `
        -DisplayName $rule.Name `
        -Direction Inbound `
        -Protocol $rule.Protocol `
        -LocalPort $rule.Port `
        -Action Allow `
        -Profile Any `
        -Description $rule.Description | Out-Null

    Write-Host "Created rule: $($rule.Name)" -ForegroundColor Green
}

Write-Host "`nReview the new rules with:" -ForegroundColor Cyan
Write-Host "  Get-NetFirewallRule -DisplayName 'SQL*' | Format-Table DisplayName, Enabled, Direction"

Scope it to a trusted subnet

The script above allows traffic from any source. In production you almost always want to limit inbound SQL to specific subnets. Add -RemoteAddress to each New-NetFirewallRule call:

New-NetFirewallRule `
    -DisplayName 'SQL Server (TCP 1433)' `
    -Direction Inbound -Protocol TCP -LocalPort 1433 `
    -RemoteAddress 10.20.0.0/16, 10.21.0.0/16 `
    -Action Allow -Profile Domain

Use -Profile Domain (rather than Any) when the server is domain-joined and you only need access on the corporate network.

Removing the rules

If you need to roll back what the script created:

Get-NetFirewallRule -DisplayName 'SQL *', 'SSAS *', 'HTTP *', 'HTTPS *' |
    Remove-NetFirewallRule

netsh advfirewall (modern command-line equivalent)

If you cannot run PowerShell: for example on a stripped Server Core installation without the NetSecurity module loaded: netsh advfirewall gives the same outcome in a batch file. This syntax replaced the older netsh firewall commands in Windows Server 2008 R2.

@echo off
:: Run from an elevated cmd.exe

echo ========= SQL Server Ports =========
netsh advfirewall firewall add rule name="SQL Server (TCP 1433)"        dir=in action=allow protocol=TCP localport=1433
netsh advfirewall firewall add rule name="SQL DAC (TCP 1434)"           dir=in action=allow protocol=TCP localport=1434
netsh advfirewall firewall add rule name="SQL Service Broker (TCP 4022)" dir=in action=allow protocol=TCP localport=4022
netsh advfirewall firewall add rule name="SQL Debugger / RPC (TCP 135)" dir=in action=allow protocol=TCP localport=135

echo ========= Analysis Services Ports =========
netsh advfirewall firewall add rule name="SSAS (TCP 2383)"              dir=in action=allow protocol=TCP localport=2383
netsh advfirewall firewall add rule name="SQL Browser (TCP 2382)"       dir=in action=allow protocol=TCP localport=2382

echo ========= Misc Applications =========
netsh advfirewall firewall add rule name="HTTP (TCP 80)"                dir=in action=allow protocol=TCP localport=80
netsh advfirewall firewall add rule name="HTTPS (TCP 443)"              dir=in action=allow protocol=TCP localport=443
netsh advfirewall firewall add rule name="SQL Browser (UDP 1434)"       dir=in action=allow protocol=UDP localport=1434

Original 2013 script (legacy netsh firewall)

The original script used the netsh firewall family of commands which was deprecated in Windows Server 2008 R2. It still runs on older systems but should not be used on anything modern. Kept here for completeness.

@echo =========  SQL Server Ports  ===================
@echo Enabling SQLServer default instance port 1433
netsh firewall set portopening TCP 1433 "SQLServer"
@echo Enabling Dedicated Admin Connection port 1434
netsh firewall set portopening TCP 1434 "SQL Admin Connection"
@echo Enabling conventional SQL Server Service Broker port 4022
netsh firewall set portopening TCP 4022 "SQL Service Broker"
@echo Enabling Transact-SQL Debugger/RPC port 135
netsh firewall set portopening TCP 135 "SQL Debugger/RPC"
@echo =========  Analysis Services Ports  ==============
@echo Enabling SSAS Default Instance port 2383
netsh firewall set portopening TCP 2383 "Analysis Services"
@echo Enabling SQL Server Browser Service port 2382
netsh firewall set portopening TCP 2382 "SQL Browser"
@echo =========  Misc Applications  ==============
@echo Enabling HTTP port 80
netsh firewall set portopening TCP 80 "HTTP"
@echo Enabling SSL port 443
netsh firewall set portopening TCP 443 "SSL"
@echo Enabling port for SQL Server Browser Service's 'Browse' Button
netsh firewall set portopening UDP 1434 "SQL Browser"
@echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)
netsh firewall set multicastbroadcastresponse ENABLE

Security notes

  • Always scope to a subnet. Allowing 1433/TCP from Any exposes SQL Server to your entire network (and in worst case, the public internet on a misconfigured host). Use -RemoteAddress on the PowerShell rules or remoteip= on the netsh rules.
  • Disable what you do not run. If you do not use SQL Service Broker, drop port 4022. If you do not use the DAC, drop 1434/TCP. Smaller surface area, fewer audit findings.
  • Use named-instance dynamic ports with care. Named instances can pick a random TCP port at start. Either configure a static port in SQL Server Configuration Manager and open that, or rely on the SQL Browser (UDP 1434) and accept the indirection.
  • Group Policy / Intune is better at scale. For more than a handful of servers, push these rules through a firewall GPO or Intune Endpoint Security policy instead of running a script on each box.