🔥 SQL Server Troubleshooting Part 2 — The Four Invisible Layers That Block TCP 1433
Recap from Part 1: SQL Server on 10.10.1.3 is listening on 0.0.0.0:1433. The app server on 10.10.1.4 can ping it — but TCP 1433 times out. Windows Firewall is off on both machines. So what's left?
Four layers you cannot see from netstat. Four layers that silently drop packets. In Part 2, we peel them back one by one — with 18 commands, real enterprise war stories, and cloud examples from AWS, Azure, and GCP.
⏮️ Part 1 Recap — In 60 Seconds
If you skipped Part 1, here's what you missed — and why it matters for what comes next.
In Part 1 we proved six things:
- SQL Server is definitely listening on
0.0.0.0:1433(all IPv4 interfaces) - The DB server's own IP
10.10.1.3responds toTest-NetConnectionlocally - The app server
10.10.1.4can ping the DB server (ICMP works) - But
Test-NetConnection 10.10.1.3 -Port 1433from the app server returnsTcpTestSucceeded : False - Windows Firewall is disabled on both machines
- The connection from app server SSMS also fails — so this is not an IIS-only problem
The math is now simple: SQL is fine, ICMP is fine, Windows Firewall is off, and yet TCP 1433 doesn't work. Something between the two hosts is dropping the packets.
Key insight from Part 1: Windows Firewall is only one of five layers that can filter TCP traffic. If you've eliminated the OS-level firewall and it still fails, you have four more layers to check — and that's exactly what Part 2 covers.
🧱 The Four Invisible Layers
When TCP 1433 fails after Windows Firewall is off, the packet must be getting dropped by one of these four layers. Think of them as a stack of filters — the packet has to pass through all four before it reaches SQL Server.
Windows Firewall (with a twist)
You turned it off — but Windows Firewall has three profiles: Domain, Private, and Public. Turning off "the firewall" via the GUI or via one profile does NOT disable the other two. Also, third-party firewall products (Kaspersky, ESET, Sophos, CrowdStrike) often run alongside Windows Defender and don't get disabled when you flip the Defender toggle.
Get-NetFirewallProfileHyper-V Virtual Switch
If your SQL Server is a VM, its virtual NIC attaches to a Hyper-V Virtual Switch. If the switch is set to Internal or Private, the VM has no path to the physical network at all. If VLAN IDs are mismatched, packets go into the wrong broadcast domain and silently vanish.
Get-VMSwitch · Get-VMNetworkAdapterPhysical Switch VLAN ACLs
Enterprise networks often use VLANs to segment traffic — e.g. databases in VLAN 100, app servers in VLAN 200. If a VLAN ACL (VACL) or inter-VLAN routing rule blocks port 1433, packets drop at the switch — before they ever reach the server. Your Windows Firewall is entirely irrelevant at this layer.
switch config: show vlan · show aclCloud Security Groups & EDR Shields
If any part of your stack runs in AWS, Azure, or GCP, Security Groups and Network Security Groups sit outside the guest OS and cannot be seen from inside Windows. Similarly, modern EDR products (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint) include network filtering that survives a Windows Firewall disable.
AWS SG · Azure NSG · GCP VPC FWTCP/IP has seven layers (OSI model), but in practice, packets are filtered at only four of them: Layer 2 (MAC/VLAN), Layer 3 (IP routing), Layer 4 (TCP/UDP ports), and Layer 7 (application). Firewalls historically work at Layer 3/4, but modern cloud security groups blur this — Azure NSG rules can reference application tags like "SqlManagement" instead of raw port numbers.
📖 A Real War Story from the Field
A financial services company migrated their trading platform to Azure. The SQL Server VM (Azure IaaS) and the IIS App Server VM lived in the same virtual network, same subnet, and had Security Groups applied from the same template. Everything worked in staging. On go-live day, the app server couldn't reach SQL on 1433. The DBA disabled the Windows Firewall on both VMs. Still failed.
They spent four hours ruling out SQL configurations, checking sys.sql_logins, rebooting the VMs, and even replacing the SQL Server instance. Nothing changed.
The culprit? An Azure NSG rule attached to the SQL VM's NIC (not the subnet) that had been added two weeks earlier for a completely unrelated reason. It contained a Deny rule for TCP 1433 with priority 500, inherited from a stale security policy. Because Deny rules in Azure NSGs can override Allow rules depending on priority, this single stale rule broke the entire connection.
The moral of the story: cloud security groups live outside the guest OS. You cannot see them with netstat, ipconfig, or any Windows command. They must be inspected through the cloud provider's console or CLI.
🌳 The Part 2 Decision Tree
Follow this tree from top to bottom, testing one layer at a time. Stop as soon as you find the culprit.
Test-NetConnection 10.10.1.3 -Port 1433
Wireshark or netsh trace on both ends. Where do the SYNs stop arriving? That tells you exactly which hop is filtering.
⚡ 18 Diagnostic Commands — Windows Firewall, Hyper-V & Cloud
Below are 18 commands grouped into four categories: Windows Firewall diagnostics, Hyper-V checks, cloud CLI commands, and advanced packet tracing. Every command has a copy button, real sample output, and interpretation.
Production safety first: Never disable a firewall on a production server. Always use additive rules — create a temporary allow rule, test, then remove it. Part 2 shows you exactly how.
☁️ Cloud Platforms Compared — AWS vs Azure vs GCP
If your SQL Server lives in a cloud environment, the filtering layer you need to check depends on which cloud. Here's the cheat sheet.
AWS — Security Groups
Attached to ENIs (network interfaces), not instances. Stateful — return traffic is automatic. Only Allow rules exist. The gotcha: Security Groups can be attached to multiple ENIs, and removing a rule from one SG doesn't affect another SG attached to the same ENI (all SGs are evaluated as a union).
aws ec2 describe-security-groups --group-ids sg-xxxxAzure — Network Security Groups (NSGs)
Attached to subnets OR NICs (both get evaluated). Stateless by default. Support both Allow and Deny rules with priority numbers 100-4096 (lower wins). The gotcha: an NSG on the subnet AND an NSG on the NIC both apply — traffic must pass both. A stale Deny on either one breaks everything.
az network nsg rule list --nsg-name myNSG -g myRGGCP — VPC Firewall Rules
Applied at the VPC level and use tags or service accounts as the target selector. Rules are stateful and evaluated hierarchically (VPC firewall → hierarchical firewall policies). The gotcha: unlike AWS/Azure, GCP doesn't have a Security Group equivalent attached to NICs — everything is centralized at the VPC layer, and hierarchical policies can silently override lower-level rules.
gcloud compute firewall-rules list --filter="name~sql"AWS Security Groups have a default outbound rule that allows all traffic to 0.0.0.0/0. But it's a single rule — if you delete it while cleaning up a restrictive policy, outbound traffic from the SQL Server stops working too. This is one of the most common causes of "SQL Server can't reach its own license server" tickets raised with AWS support.
Azure NSGs used to be stateful in their earliest (pre-2017) implementation, then Microsoft changed the architecture. Today's NSGs are officially documented as stateful for connection tracking but appear stateless in some scenarios due to how flow logs are written. Confusing? Yes. Always test return traffic explicitly, never assume.
⚠️ 7 Common Pitfalls (and How to Avoid Them)
- "Firewall is off" ≠ "all profiles are off." Windows has three profiles — Domain, Private, Public. Disabling one in the GUI often leaves the others active. Use
Get-NetFirewallProfileto check all three at once. - Forgetting third-party firewalls. Kaspersky, ESET, Sophos, and CrowdStrike Falcon all have their own network filter drivers. Disabling Windows Defender does nothing to them.
- Assuming Hyper-V defaults are fine. A newly created VM's switch type and VLAN ID are silent default decisions. External switch = connected to physical network; Internal/Private = isolated.
- Confusing subnet with VLAN. Two VMs can be on the same /24 subnet in the guest OS but on different VLANs in the hypervisor — the packets never meet.
- Only checking one cloud layer. Azure NSG applies at both subnet and NIC level. Missing one means you see only half the picture.
- Testing with
ping. ICMP success tells you nothing about TCP 1433. Always test the port, not just the host. - Never capturing packets. When all else fails, Wireshark or
netsh tracereveals exactly where SYNs stop arriving. Do this early, not as a last resort.
Pro tip: Keep a text file with these seven pitfalls at the top of every incident. The instinct during a fire is to skip layers — the disciplined approach is to work through them one by one.
❓ Frequently Asked Questions
The questions engineers ask most often when SQL 1433 fails with the firewall off.
🎓 More Free Resources from FreeLearning365
Over 100 free resources for developers, DBAs, sysadmins, and students — no registration, no paywall, no nonsense.
Job Interview Preparation — Programming, Cloud, Data, ERP
Full interview prep for SQL, DBMS, Networking, Cloud, and Programming — used by thousands of engineers worldwide.
Start Prep →Free Programming Tutorials
JavaScript, Angular, Python, SQL, Data Analysis & More — complete free tutorials and structured learning paths.
Learn Now →100+ Free Online Tools & Utilities
For developers, SEO specialists, and students — 100+ free tools with zero registration required.
Explore Tools →Class 1-12 Notes, Lecture Sheets & Suggestions PDF
SSC, HSC, Dakhil, Fazil — all subjects, all classes, in one place. Completely free.
View Notes →Free Question Bank — BCS, HSC, SSC, JSC, PSC
Question sets and solutions for dozens of competitive exams, all free.
Browse Bank →Advance Your IT Career with Professional Training
Specialised IT training courses for engineers wanting to level up — cloud, data, and software architecture.
See Training →🏁 Part 2 Wrap-Up — What You Now Know
Part 2 answered the hardest question in SQL Server remote-connection debugging: when the OS firewall is off, what else can still block TCP 1433?
- ✅ Windows Firewall has three profiles — disabling one doesn't disable the others
- ✅ Third-party firewalls and EDR products run their own network filtering outside Windows Defender's control
- ✅ Hyper-V Virtual Switch types (External vs Internal vs Private) determine whether a VM can reach the physical network at all
- ✅ VLAN ACLs on physical switches can silently drop inter-VLAN traffic at Layer 2 — invisible to the guest OS
- ✅ Cloud Security Groups (AWS SG, Azure NSG, GCP VPC FW) operate outside the VM and must be inspected through the provider's console or CLI
- ✅ Wireshark and netsh trace are the ultimate truth — they show you exactly which hop is dropping SYNs
Up next — Part 3: We shift focus back to SQL Server itself. Even when the network is perfect, SQL Server might still refuse connections because of TCP/IP protocol binding, authentication mode, login state, or dynamic port issues. Part 3 walks through SQL Server Configuration Manager and every relevant T-SQL diagnostic query.
0 Comments
thanks for your comments!