Interactive Troubleshooter

Published: Sep 1, 2026

Firewall Rules Blocking Traffic: How to Trace

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to systematically trace, isolate, and remediate blocked network traffic across firewalls. Identify silent drops in Windows Filtering Platform (WFP), iptables/nftables drop rules, cloud Security Group misconfigurations, and perimeter firewall policy blocks.

Full Diagnostic Tree & Step-by-Step Overview

Where in your network infrastructure is the connection being dropped or filtered?

Local Host Operating System Firewall (Windows Defender Firewall, Linux iptables/nftables, or ufw)
Enterprise Perimeter / Hardware Firewall (Palo Alto, Fortinet FortiGate, Cisco ASA, pfSense)
Cloud Infrastructure Firewall / VPC Security Group / Network ACL (AWS VPC, Azure NSG, GCP VPC)

Which Host Operating System firewall is dropping the network traffic?

Windows Server / Windows 11 Firewall (Silent TCP SYN drops or WFP block rules)
Linux Host Firewall (iptables, nftables, or UFW dropping packets)

Trace Windows Firewall Drops via Windows Filtering Platform (WFP) Auditing

Solution:

Root Cause: Windows Filtering Platform (WFP) Silent Packet Drop or Missing Inbound Rule

Windows Defender Firewall operates on top of the Windows Filtering Platform (WFP). When traffic matches a default block policy or a conflicting block rule, WFP silently drops packets without notifying the application, resulting in TCP connection timeouts (SYN sent, no SYN-ACK returned).

# Step-by-Step Fix:

Enable WFP Packet Drop Audit Policies:

Open Command Prompt as Administrator and enable failure auditing for WFP drops:

cmd
   auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
   auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable

Reproduce the Traffic and Inspect Security Event Logs:

Initiate the blocked network connection from the remote host.

Open Event Viewer (eventvwr.msc) > Windows Logs > Security.

Filter log for Event ID 5157 (WFP blocked a packet) or Event ID 5152.

Identify the specific Filter ID causing the block in the event details.

Map the Filter ID to the Exact Blocking Rule:

Export the active WFP filter database to XML via Command Prompt:

cmd
   netsh wfp capture start

Open wfpdiag.xml and search for the <filterKey> matching the Filter ID from Event 5157.

Add Explicit Allow Rule via PowerShell:

Create an overriding inbound rule for the destination port:

powershell
   New-NetFirewallRule -DisplayName "Allow App Port 8080" -Direction Inbound -LocalPort 8080 -Protocol TCP -Action Allow -Enabled True

Trace Linux Kernel Packet Drops using iptables TRACE Target and dmesg Logs

Solution:

Root Cause: Implicit Default Drop Policy or Misconfigured Netfilter/iptables Chain

Linux kernel Netfilter framework processes incoming, outgoing, and routed packets through tables (raw, mangle, nat, filter). A misconfigured chain rule or restrictive default policy (POLICY DROP) silently discards frames at the kernel level.

# Step-by-Step Fix:

Inject TRACE Rule into Netfilter RAW Table:

Enable tracing for packets matching the target IP and destination port:

bash
   sudo iptables -t raw -A PREROUTING -p tcp -s 192.168.1.50 --dport 443 -j TRACE
   sudo iptables -t raw -A OUTPUT -p tcp -d 192.168.1.50 --dport 443 -j TRACE

Monitor Real-Time Kernel Drop Logs:

Watch kernel log output as you initiate the connection:

bash
   sudo dmesg -wT | grep -E "TRACE:|PACKET_DROP"

Observe which table, chain, and rule number processes the packet last before termination.

Trace Packets in modern nftables Environments:

If using nftables, run the real-time packet trace tool:

bash
   sudo nft add chain inet filter trace_chain { type filter hook prerouting priority -301 \; }
   sudo nft add rule inet filter trace_chain ip saddr 192.168.1.50 meta nftrace set 1
   sudo nft monitor trace

Update Firewall Configuration (UFW / iptables):

Insert an explicit allow rule at the top of the INPUT chain:

bash
   sudo iptables -I INPUT 1 -p tcp --dport 443 -j ACCEPT
   # Or if using UFW:
   sudo ufw allow in from 192.168.1.50 to any port 443 proto tcp

What type of perimeter firewall drop or state machine issue are you experiencing?

Implicit Deny policy block, rule priority collision, or asymmetric routing state drop
Layer 7 Next-Gen Inspection block (App-ID mismatch, SSL Decryption failure, or Threat Prevention profile drop)

Trace Perimeter Firewall Policy Matches via CLI Flow Tracer and On-Box PCAP

Solution:

Root Cause: Top-Down Security Policy Hit (Implicit Deny) or Asymmetric State Table Drop

Stateful perimeter firewalls evaluate traffic top-down. If no explicit rule permits the connection, the packet hits the default cleanup rule (interzone-default deny). Alternatively, if return traffic takes a different physical path (asymmetric routing), the firewall drops packets due to missing TCP SYN state initialization.

# Step-by-Step Fix:

Run Policy Match Simulation via Firewall CLI:

Palo Alto Networks (PAN-OS): Test security policy evaluation for source/destination IP and port:

text
   test security-policy-match source <SRC_IP> destination <DST_IP> protocol 6 destination-port <PORT>

Fortinet (FortiGate): Run debug flow trace in CLI:

text
   diagnose debug reset
   diagnose debug flow filter addr <DST_IP>
   diagnose debug flow filter port <PORT>
   diagnose debug flow trace start 100
   diagnose debug enable

Inspect Flow Output for Drop Reasons:

Look for log indicators such as Denied by forward policy, Implicit Deny, or No session matched / TCP state mismatch.

Run Hardware On-Box Packet Capture (PCAP):

Filter by target IP to confirm whether traffic arrives on the ingress interface and gets discarded before egress.

Remediate Rule Order or Asymmetric Paths:

Move specific allow rules above broad deny rules.

If asymmetric routing is present, enable non-SYN TCP state bypass or adjust upstream routing metrics to ensure symmetric flow paths.

Isolate Layer 7 NGFW App-ID and Threat Prevention Profile Blocks

Solution:

Root Cause: Layer 7 NGFW Inspection Drop (App-ID Mismatch or SSL Forward Proxy Failure)

Next-Generation Firewalls (NGFWs) inspect packet payloads beyond Layer 4. If a service runs on a non-standard port (e.g., SSH over port 80), or if SSL/TLS handshake certificates fail validation during Outbound Decryption inspection, the firewall drops traffic under Application Control or Threat Prevention profiles.

# Step-by-Step Fix:

Query NGFW Threat and Traffic Logs:

Filter traffic logs by destination IP and look for action drop or reset-server.

Check the App-ID / Application column to see if the traffic was misidentified (e.g., unknown-tcp or web-browsing instead of custom-app).

Review Threat Prevention and Antivirus Logs:

Check Vulnerability Protection and Antivirus logs for sub-category blocks such as HTTP-Header-Injection or SSL-Invalid-Cert.

Configure Application-Default Policy Rules:

Update the security policy rule to allow specific App-IDs rather than restricting solely to TCP ports, or set Service to application-default.

Bypass Decryption for Sensitive / Failing Endpoints:

If TLS inspection breaks connection handshakes due to certificate pinning, add the destination domain to the No-Decryption Exclusion List.

Which Cloud Provider networking layer is dropping the traffic?

AWS VPC (Security Group stateful drop or Network ACL stateless subnet block)
Microsoft Azure (NSG rule drop) or Google Cloud Platform (GCP VPC Firewall priority block)

Trace AWS Packet Drops using VPC Flow Logs and Reachability Analyzer

Solution:

Root Cause: AWS Stateful Security Group Rule Mismatch or Stateless NACL Return Path Block

AWS networking uses two filtering layers: Security Groups (stateful, applied to ENIs) and Network Access Control Lists (NACLs) (stateless, applied to subnets). While Security Groups automatically allow return traffic, NACLs require explicit rules for both Inbound traffic and Ephemeral Outbound return ports (TCP 1024-65535).

# Step-by-Step Fix:

Query CloudWatch Insights on VPC Flow Logs:

Execute CloudWatch Log Insights query to isolate REJECT actions:

text
   fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, action, logStatus
   | filter dstAddr = '10.0.1.50' and action = 'REJECT'
   | sort @timestamp desc
   | limit 20

Execute AWS VPC Reachability Analyzer Path Trace:

Run path analysis via AWS CLI from Source ENI/EC2 to Destination ENI/EC2:

bash
   aws ec2 start-network-insights-analysis --network-insights-path-id nip-0123456789abcdef0

Inspect the output for status NOT_REACHABLE and examine the specific ExplainingCode (e.g., ENI_SECURITY_GROUP_MISMATCH or NACL_INBOUND_ENTRY_NOT_FOUND).

Audit Inbound/Outbound Stateless NACL Rules:

Ensure the subnet NACL contains an outbound rule allowing ephemeral ports 1024-65535 back to the source subnet.

Update Security Group Inbound Rule:

Add an explicit ingress rule on the target instance's Security Group targeting the correct source CIDR or Security Group ID.

Trace Azure NSG and GCP VPC Drops using Network Watcher and Flow Logs

Solution:

Root Cause: Cloud Network Security Group (NSG) Priority Overrides or GCP Default Rule Collisions

Azure Network Security Groups (NSGs) evaluate rules by numerical priority (100–4096). A lower-numbered Deny rule (e.g., Priority 200) overrides higher-numbered Allow rules (e.g., Priority 500). In GCP, firewall rules use integer priorities (0–65535) where lower numbers take precedence.

# Step-by-Step Fix:

Run Azure Network Watcher IP Flow Verify:

Test packet flow feasibility using Azure CLI:

azurecli
   az network watcher test-ip-flow --direction Inbound --protocol TCP --local 10.0.0.4:80 --remote 192.168.1.5:52341 --vm TargetVMName --resource-group MyResourceGroup

The output will return Access Denied along with the exact NSG Rule Name causing the block.

Run GCP Connectivity Tests (Network Intelligence Center):

Test reachability between GCP instances via gcloud CLI:

bash
   gcloud network-management connectivity-tests run test-http --source-instance=vm-src --destination-instance=vm-dst --destination-port=80

Inspect the analysis result for FINAL_STATE: DROP and the matching firewall rule name.

Re-order Firewall Rule Priorities:

In Azure NSG or GCP VPC Firewall, adjust your desired Allow rule to have a lower numerical priority value than any conflicting Deny rule.

Verify Direct Rule Binding on Subnet and NIC:

Ensure subnet-level NSGs in Azure do not conflict with Network Interface (NIC)-level NSGs.

Related Diagnostic Guides

Google Account Suspicious Activity? How to Check for Unknown Devices

Microsoft Account Hacked? How to Recover and Secure Your Account

Fast Charging Not Working? How to Check USB PD and Quick Charge Support

Laptop Using Integrated Graphics Instead of Dedicated GPU? Here's How to Fix It

Google Family Link Not Blocking Apps? Here's How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website