FIREWALL
TROUBLESHOOTING
GUIDE
Comprehensive Reference for Security Engineers
Version 2.0 | 2025 Edition
Classification: Internal / Restricted
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
Table of Contents
1. Firewall Fundamentals
1.1 Firewall Types & Architectures
1.2 Traffic Flow Concepts
1.3 Stateful vs. Stateless Inspection
2. Diagnostic Methodology
2.1 OSI-Layer Troubleshooting Framework
2.2 Evidence Collection Checklist
3. Rule & Policy Troubleshooting
3.1 Rule-Base Analysis
3.2 Shadow & Redundant Rules
3.3 NAT Troubleshooting
4. Connectivity & Routing Issues
4.1 Asymmetric Routing
4.2 MTU & Fragmentation
4.3 VPN Connectivity
5. Performance Troubleshooting
5.1 CPU & Memory Bottlenecks
5.2 Session Table Exhaustion
5.3 Interface & Throughput Issues
6. Logging, Monitoring & Alerts
6.1 Log Analysis Techniques
6.2 SIEM Integration
6.3 Alert Tuning
7. Platform-Specific Commands
7.1 Cisco ASA / FTD
7.2 Palo Alto Networks
7.3 Fortinet FortiGate
7.4 Check Point
7.5 iptables / nftables (Linux)
8. Security Incident Response
8.1 Triage & Containment
8.2 Forensic Evidence Preservation
9. Change Management & Hardening
9.1 Pre/Post Change Checklist
9.2 CIS Benchmark Quick-Wins
10. Quick-Reference Appendix
A Common Port Reference
B ICMP Type/Code Reference
C Escalation Matrix Template
CONFIDENTIAL – INTERNAL USE ONLY Page 2
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
1. Firewall Fundamentals
1.1 Firewall Types & Architectures
Understanding the type of firewall in your environment is the essential first step before any troubleshooting activity.
Each architecture imposes different constraints on traffic inspection, logging granularity, and the commands available
for diagnosis.
Type Inspection Layer Typical Use-Case Key Limitation
Packet Filter L3 / L4 Edge ACLs, router ACLs No session state
Stateful Inspection L3 – L4 (session) Perimeter, DMZ Limited app visibility
Application-Layer GatewayL3
(ALG)
– L7 Proxy deployments Latency overhead
Next-Gen Firewall (NGFW)L3 – L7 + Identity Modern perimeter / ZTNA Complexity, licensing cost
Web Application Firewall (WAF)
L7 (HTTP/S) Protecting web apps Protocol-specific only
Cloud-Native FW L3 – L7 AWS / Azure / GCP workloads Vendor lock-in
1.2 Traffic Flow Concepts
Every packet traversing a firewall follows a deterministic processing pipeline. Deviating from the expected path is the
root cause of most connectivity issues. The standard pipeline for a stateful NGFW is:
1. Ingress interface → pre-routing sanity checks (TTL, checksum, IP options)
2. Destination NAT (DNAT) lookup – translate destination before routing
3. Route lookup – determine egress interface and next-hop
4. Session table lookup – existing session accelerated; new flows proceed to policy
5. Security policy evaluation – top-down, first-match
6. Application identification & deep inspection (NGFW)
7. Source NAT (SNAT) – translate source before egress
8. Egress interface → QoS / shaping → wire
■ Key Insight
NAT always occurs BEFORE security policy on most platforms. Always account for translated addresses
when writing rules. A rule matching [Link] may never fire if traffic arrives post-DNAT as [Link].
1.3 Stateful vs. Stateless Inspection
Stateful firewalls track the state of network connections (TCP handshake, UDP pseudo-state, ICMP echo) and allow
return traffic automatically. Stateless packet filters evaluate each packet in isolation.
■ Common Mistake
Administrators sometimes add explicit 'return traffic' rules on stateful firewalls, creating redundant or
conflicting entries. On stateless ACLs (router ACLs, AWS Security Groups in certain modes) return rules
ARE required.
CONFIDENTIAL – INTERNAL USE ONLY Page 3
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
2. Diagnostic Methodology
2.1 OSI-Layer Troubleshooting Framework
A structured, layer-by-layer approach prevents wasted effort and ensures root causes are not overlooked. Always
start at Layer 1 and progress upward unless strong evidence points to a specific layer.
Layer What to Verify Key Tools
L1 – Physical Cable, SFP, interface errors, duplex mismatch show interfaces, CDP/LLDP
L2 – Data Link VLAN tagging, MAC learning, spanning tree show mac-address-table, show spanning-tree
L3 – Network IP addressing, routing table, ARP ping, traceroute, show route
L4 – Transport Port reachability, TCP handshake, UDP reach nc / ncat, telnet, nmap
L5-6 – Session/Pres. TLS handshake, SSL offload, certificate errors openssl s_client, sslyze
L7 – Application HTTP status codes, DNS, app-specific errors curl, dig, app logs
2.2 Evidence Collection Checklist
Before making any changes, collect the following evidence to support accurate diagnosis and change-rollback
capability:
Pre-Troubleshooting Evidence Checklist Status
Export current rule-base / ACL configuration (with timestamps) ■
Capture interface counters and error statistics ■
Pull session table snapshot (connection counts, half-open sessions) ■
Collect relevant log excerpts (±15 minutes around incident) ■
Document NAT translation table state ■
Record routing table and ARP/neighbour table ■
Note CPU, memory, and session utilisation percentages ■
Identify maintenance windows and recent changes (last 72 hours) ■
Obtain source/destination IP, port, protocol from the affected party ■
Confirm whether the issue is consistent or intermittent ■
CONFIDENTIAL – INTERNAL USE ONLY Page 4
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
3. Rule & Policy Troubleshooting
3.1 Rule-Base Analysis
Most firewall connectivity issues trace back to incorrect or missing rules. Follow this decision tree when traffic is being
blocked unexpectedly:
Step 1: Identify the 5-tuple (src IP, dst IP, src port, dst port, protocol).
Step 2: Apply any active NAT translations to determine the post-NAT 5-tuple.
Step 3: Use the platform's policy-lookup or packet-tracer tool with the post-NAT tuple.
Step 4: Identify the matching rule. If 'implicit deny', no rule matches – add or modify a rule.
Step 5: If a rule matches but traffic still fails, inspect the action (allow vs. inspect vs. reset).
Step 6: Verify security profiles attached to the rule (AV, IPS, URL filtering) are not blocking.
Step 7: Check application-based rules – is the application correctly identified?
3.2 Shadow & Redundant Rules
Shadowed rules are never matched because a preceding rule already handles the same traffic. They accumulate
over time and obscure the intended policy. Use the following indicators:
■ Shadow Rule Indicators
Hit count = 0 after weeks of production traffic
Rule has a more-specific match than a rule listed ABOVE it
Destination 'any' rule appears before a specific destination rule
Protocol 'any' rule appears before a specific protocol rule
✔ Cleanup Strategy
Export hit-count data over a 90-day window. Zero-hit rules are candidates for removal (after confirming
they are not for low-frequency events like break-glass access). Always archive before deletion.
3.3 NAT Troubleshooting
NAT misconfiguration is one of the top causes of firewall connectivity failures. The following table outlines common
NAT problems and their resolutions:
Symptom Likely Cause Resolution
Traffic not reaching server DNAT rule missing or wrong destination Verify packet-tracer, check DNAT logs
Return traffic dropped Asymmetric routing – return path bypassesEnsure
firewallsymmetric routing; use PBR
Source IP seen incorrectly by server
SNAT applied when not desired Check SNAT policy order; add no-NAT rule above
NAT pool exhaustion All PAT ports consumed Expand PAT pool; add overload addresses
Hairpin / U-turn failing Loopback NAT not configured Enable hairpin NAT or DNS doctoring
CONFIDENTIAL – INTERNAL USE ONLY Page 5
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
4. Connectivity & Routing Issues
4.1 Asymmetric Routing
Asymmetric routing occurs when outbound and return traffic traverse different firewall interfaces or different firewalls
entirely. Stateful firewalls drop packets for sessions they have no state for.
■ Asymmetric Routing Symptoms
Established TCP connections terminate unexpectedly
ICMP echo works but TCP/UDP sessions fail
Logs show 'TCP out-of-state' or 'no session found' drops
One-way audio in VoIP (RTP asymmetry)
Mitigation strategies:
• Implement Policy-Based Routing (PBR) to force symmetric paths.
• Use ECMP with flow-based hashing keyed on 5-tuple.
• Deploy firewall clustering with session synchronisation (active/active HA).
• Use asymmetric routing bypass (ARP proxy) only as a last resort – it reduces security.
4.2 MTU & Fragmentation
MTU mismatches cause intermittent failures: small packets succeed while large packets (bulk transfers, TLS
handshakes) are silently dropped. IPsec VPNs and GRE tunnels reduce the effective MTU.
Command / Syntax Description
ping -M do -s 1400 Send 1400-byte ping with DF bit set (Linux)
ping -l 1400 -f Send 1400-byte ping with DF bit set (Windows)
ip link set eth0 mtu 1500 Set interface MTU (Linux)
ip tcp adjust-mss 1452 Clamp TCP MSS on Cisco IOS interface
set interface mtu 1500 Set MTU on Palo Alto interface
Table 4-1: MTU Diagnostic Commands
✔ IPsec MTU Rule of Thumb
ESP tunnel mode overhead: ~58 bytes (IPv4) or ~78 bytes (IPv6). For a standard 1500-byte link, set tunnel
interface MTU to 1422 (1500 – 78). Always enable TCP MSS clamping on VPN tunnel interfaces.
4.3 VPN Connectivity Troubleshooting
VPN failures are categorised into two phases: IKE Phase 1 (ISAKMP – authentication and key exchange) and IKE
Phase 2 (IPsec – data encryption). Identify which phase fails to narrow the cause.
CONFIDENTIAL – INTERNAL USE ONLY Page 6
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
Symptom Probable Cause Resolution
Phase 1 fails – no response UDP 500/4500 blocked, peer IP wrongCheck ACL for IKE ports; verify peer IP
Phase 1 fails – proposal mismatchEncryption/hash/DH group mismatch Align proposals; enable debug crypto isakmp
Phase 1 ok, Phase 2 fails Transform-set or PFS mismatch Match Phase 2 proposals and PFS settings
Phase 2 ok, no traffic Crypto ACL / proxy-id mismatch Ensure interesting traffic ACLs mirror each end
VPN drops intermittently Dead-peer-detection, re-key timing Tune DPD and lifetime; check NAT-T keep-alive
Traffic encrypted but wrong direction
Route or policy ordering issue Verify VPN-route preference vs. default route
CONFIDENTIAL – INTERNAL USE ONLY Page 7
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
5. Performance Troubleshooting
5.1 CPU & Memory Bottlenecks
High CPU on a firewall can manifest as packet loss, increased latency, or complete outages. Identify the process or
plane (data plane vs. management plane) consuming resources.
• Management-plane CPU spike: Usually caused by SNMP polling, logging storms, or management-GUI overload.
Throttle polling intervals; move logging to syslog.
• Data-plane CPU spike: Often caused by content-inspection features (SSL decryption, IPS, AV). Profile which
policy rules use heavyweight inspection and scope them.
• Packet-buffer exhaustion: Caused by traffic bursts. Enable RED/WRED and verify hardware queue depths.
• Memory leak indicators: Steadily growing memory over days/weeks without traffic increase. Schedule
maintenance reload if no hotfix available.
5.2 Session Table Exhaustion
When the session table reaches capacity, new connections are dropped silently. This often mimics a firewall policy
block but is actually a resource exhaustion condition.
■ Session Exhaustion Warning Signs
Legitimate traffic suddenly drops with no policy changes
Session table utilisation > 90% (visible via dashboard or CLI)
Large number of half-open TCP or long-idle UDP sessions
DDoS or scanning activity flooding the session table
✔ Immediate Mitigations
Reduce session timeouts for UDP (30s default → 15s), ICMP (10s → 5s), and half-open TCP (30s → 10s).
Enable SYN-cookie or SYN-proxy to prevent half-open floods filling the table.
Add a scavenge policy for idle sessions over 3600 seconds.
5.3 Interface & Throughput Issues
Interface errors degrade throughput and can cause intermittent connectivity. Review these counters regularly:
Counter Meaning Action
Input errors CRC / frame errors Physical layer – check cable, SFP, duplex
Output drops Transmit queue full Egress congestion – check QoS / bandwidth
Overruns Receive ring overflow CPU not draining fast enough – check CPU load
Runts / Giants Undersized / oversized frames MTU mismatch or duplex mismatch
Input discards Buffer drops Ingress rate exceeds capacity – upgrade or rate-limit
Output errors Output FIFO full QoS policy too aggressive – adjust shaping
CONFIDENTIAL – INTERNAL USE ONLY Page 8
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
6. Logging, Monitoring & Alerts
6.1 Log Analysis Techniques
Firewall logs are the primary forensic source for both security and connectivity investigations. Structured log analysis
reduces mean-time-to-resolution (MTTR) significantly.
Command / Syntax Description
grep 'DENY' [Link] | awk '{print $5}' | Top denied source IPs
sort | uniq -c | sort -rn | head 20
grep '443' [Link] | grep 'PERMIT' | wc Count of permitted HTTPS flows
-l
zcat [Link].*.gz | grep '[Link]' | All denies for a specific IP (compressed logs)
grep 'DENY'
awk '$7 > 100000' [Link] Sessions transferring > 100KB (data exfil hunt)
grep 'session closed' [Link] | awk Top session close reasons
'{print $NF}' | sort | uniq -c | sort
-rn
Table 6-1: Common Log Analysis One-Liners
6.2 SIEM Integration
Centralising firewall logs in a SIEM enables correlation, alerting, and long-term retention. Key considerations for a
reliable integration:
• Use syslog over TLS (RFC 5425) to prevent log tampering in transit.
• Standardise log format using CEF or LEEF for vendor-neutral ingestion.
• Include interface names and zone information in log exports for accurate topology mapping.
• Ensure NTP is synchronised to a reliable source – timestamp skew invalidates forensic timelines.
• Set log rate limits on the firewall to prevent SIEM flooding; implement local buffering for bursts.
• Archive raw logs to immutable storage (WORM) for compliance (PCI-DSS, ISO 27001).
6.3 Alert Tuning
Poorly tuned alerts lead to alert fatigue, which is a primary contributor to incident response failures. Apply the
following framework to all firewall-derived alerts:
Alert Category Recommended Threshold Tuning Guidance
Port scan detection >20 unique ports / 60 sec from single src
Whitelist authorised scanners (Nessus, QualysGuard)
Brute-force (SSH/RDP) >10 failed auths / 60 sec to single dst Exclude service accounts with long, fixed intervals
Outbound deny spike >500% increase over 7-day baseline Correlate with change window – suppress during maint.
New outbound country Any first-seen geolocation for a host Review against business-travel and cloud-provider lists
Session table > 90% Absolute threshold Auto-trigger capacity runbook; page on-call engineer
CONFIDENTIAL – INTERNAL USE ONLY Page 9
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
7. Platform-Specific Commands
7.1 Cisco ASA / FTD
Command / Syntax Description
packet-tracer input inside tcp [Link] Simulate packet traversal with full decision trace
1234 [Link] 443 detail
show conn all Display all current connections / sessions
show asp drop Show accelerated security path (ASP) drop reasons
show threat-detection rate Display IPS/DoS threat detection counters
capture CAP interface inside match tcp Capture packets on interface for specific host
host [Link] any
show logging | include [Link] Filter syslogs for specific IP
show failover HA cluster state and sync status
debug crypto isakmp 7 Verbose IKE Phase 1 debug (CAUTION: high output)
Table 7-1: Cisco ASA/FTD Diagnostic Commands
7.2 Palo Alto Networks (PAN-OS)
Command / Syntax Description
test security-policy-match source Policy lookup for 5-tuple
[Link] destination [Link] protocol 6
port 443
show session all filter source [Link] Show sessions from a specific source
debug dataplane packet-diag set filter Enable inline packet capture / debug
match source [Link]
show counter global filter aspect flow Show per-second flow counters (drops etc.)
delta yes
show routing route Display routing table
show high-availability state HA synchronisation status
request system software check Check for available PAN-OS updates
show system resources CPU, memory, load average
Table 7-2: Palo Alto PAN-OS Diagnostic Commands
7.3 Fortinet FortiGate
Command / Syntax Description
diagnose sniffer packet any 'host Capture packets for host (verbose level 4)
[Link]' 4
CONFIDENTIAL – INTERNAL USE ONLY Page 10
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
Command / Syntax Description
diagnose firewall iprope lookup Policy route lookup for 5-tuple
[Link] [Link] 6 1024 443
get system session list List all current sessions
diagnose sys top Real-time process CPU/memory usage
diagnose debug flow filter addr Enable flow debug for specific address
[Link]
diagnose debug flow show console enable Print flow debug to console
diagnose vpn ike log-filter dst-addr4 Filter IKE debug for VPN peer
diagnose hardware deviceinfo nic Interface statistics and error counters
Table 7-3: FortiGate Diagnostic Commands
CONFIDENTIAL – INTERNAL USE ONLY Page 11
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
7.4 Check Point
Command / Syntax Description
fw monitor -e 'accept src=[Link];' -o Capture packets at Check Point kernel level
/tmp/[Link]
fw tab -t connections -s Session table stats (total, peak, active)
cpstat fw -f policy Policy installation status
fw ctl zdebug drop | head -200 Real-time drop log (kernel debug – use briefly)
fw ctl pstat Kernel memory and connection stats
cpinfo -y all Comprehensive system diagnostic bundle
show routed route-table Routing table on Gaia OS
clish -c 'show cluster state' ClusterXL state and member status
Table 7-4: Check Point Diagnostic Commands
7.5 iptables / nftables (Linux)
Command / Syntax Description
iptables -nvL --line-numbers List all rules with hit counters and line numbers
iptables -nvL -t nat List NAT table rules
iptables -I INPUT 1 -s [Link] -j LOG Temporarily log all traffic from a host
--log-prefix 'FW-DEBUG: '
conntrack -L | grep '[Link]' Show connection tracking table for a host
nft list ruleset List full nftables rule set
nft monitor Live event stream of nftables decisions
ss -tunap Active sockets with process name and PID
tcpdump -i eth0 -nn 'host [Link] and Packet capture on Linux host
port 443'
Table 7-5: iptables/nftables Diagnostic Commands
CONFIDENTIAL – INTERNAL USE ONLY Page 12
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
8. Security Incident Response
8.1 Triage & Containment
When a security incident is identified at the firewall layer, rapid and structured triage minimises attacker dwell time
and limits blast radius. Follow the sequence below:
1. IDENTIFY: Confirm the incident. Do not rely solely on a single alert. Correlate firewall logs with endpoint, DNS,
and proxy logs.
2. SCOPE: Determine affected hosts, networks, and services. Identify internal-to-external, lateral, and
internal-to-internal traffic anomalies.
3. CONTAIN: Block the offending source or destination using a temporary emergency rule at the TOP of the rule
base.
4. PRESERVE: Export logs, session tables, and packet captures BEFORE making further changes. Evidence
integrity is paramount.
5. ERADICATE: Once scope is confirmed, block all C2 IPs/FQDNs, reset compromised credentials, and patch the
exploited vulnerability.
6. RECOVER: Gradually restore services while monitoring for re-compromise. Do not remove containment rules
prematurely.
7. DOCUMENT: Record every change made during the incident with timestamps, rationale, and approver.
■ Critical: Do Not Reboot Without Evidence Preservation
A firewall reboot clears session tables, volatile debug buffers, and in-memory packet captures. Always
export and archive volatile state BEFORE any power cycle or service restart during an incident.
8.2 Forensic Evidence Preservation
Forensic Evidence Checklist Status
Export complete firewall configuration (with timestamp in filename) ■
Capture packet capture (PCAP) of suspicious flows ■
Export session/connection table (text + raw if available) ■
Export syslog / log files for ±2 hours around incident start ■
Record ARP table and MAC-address table ■
Document all rules modified during containment (before/after) ■
Screenshot dashboards (CPU, session count, alert counts) ■
Hash all exported files (SHA-256) and store securely ■
Notify legal/compliance if PII or regulated data may be involved ■
CONFIDENTIAL – INTERNAL USE ONLY Page 13
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
9. Change Management & Hardening
9.1 Pre / Post Change Checklist
All firewall changes, regardless of urgency, must follow a structured change process. Emergency changes require
post-hoc review within 24 hours.
Pre-Change Tasks
Change request approved (CAB or emergency approval documented) ■
Rollback procedure defined and tested in lab (if possible) ■
Backup of current configuration taken and verified ■
Maintenance window agreed with business stakeholders ■
Test criteria defined: what proves the change worked? ■
Communication sent to affected teams ■
Post-Change Validation
Run packet-tracer / policy-match for all affected flows ■
Confirm session table stable (no spikes in drops) ■
Verify no unexpected changes to routing table ■
Check hit counts on new rules within 15 minutes ■
Monitor SIEM for new alert categories for 1 hour ■
Confirm rollback procedure no longer needed; close change ticket ■
9.2 CIS Benchmark Quick-Wins
The following hardening items provide the highest security-to-effort ratio and should be applied to all production
firewalls:
Hardening Item Rationale Priority
Disable unused management protocols
Telnet, HTTP management should be disabled; use SSH/HTTPS only
High
Restrict management access by source
OnlyIPauthorised jump-hosts / OOB IPs should reach mgmt plane High
Enable NTP with authentication Unsigned NTP allows log-timestamp manipulation High
Set explicit implicit-deny log rule Ensure denied traffic is logged; default deny is silent on many platforms
High
Enable login banners Required for legal prosecution in many jurisdictions Medium
Configure SNMPv3 with AuthPriv SNMPv1/v2c community strings are cleartext High
Disable ICMP unreachable / redirect Reduces
on external
reconnaissance
interface exposure Medium
Set maximum login attempts and lockout
Brute-force protection for management access High
Centralise and encrypt log export Syslog over TLS to immutable SIEM High
CONFIDENTIAL – INTERNAL USE ONLY Page 14
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
Hardening Item Rationale Priority
Enable hardware tamper protection /Prevent
secure boot
BIOS/firmware-level attacks Medium
CONFIDENTIAL – INTERNAL USE ONLY Page 15
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
10. Quick-Reference Appendix
Appendix A – Common Port Reference
Port(s) Protocol Service Security Note
20/21 TCP FTP (data/control) Legacy; prefer SFTP
22 TCP SSH / SFTP / SCP Enforce key-auth; disable root login
25 TCP SMTP Restrict outbound except mail relays
53 TCP/UDP DNS Monitor for DNS tunnelling / exfil
80 TCP HTTP Force redirect to HTTPS
110/143 TCP POP3 / IMAP Use encrypted variants (995/993)
123 UDP NTP Allow only to/from authorised NTP servers
443 TCP HTTPS / TLS Enable SSL inspection for egress
445 TCP SMB Block inbound at perimeter; monitor lateral
514 UDP / TCP Syslog Use 6514 (TLS); block 514 at perimeter
636 TCP LDAPS Preferred over plain LDAP (389)
1194 UDP/TCP OpenVPN Block from untrusted zones
3389 TCP RDP Never expose to internet; use VPN + MFA
4500 UDP IPsec NAT-T Required for NAT traversal in VPNs
8080/8443 TCP HTTP/S Alternate Often used by malware; monitor carefully
Appendix B – ICMP Type/Code Reference
Type Code Name Security Note
0 0 Echo Reply Response to ping
3 0 Dest Unreachable – Net Routing failure
3 1 Dest Unreachable – Host ARP failure / host down
3 3 Dest Unreachable – Port UDP port closed
3 4 Fragmentation Needed PMTUD – critical; never block
3 13 Comm Admin Prohibited Firewall block reply
5 0-3 Redirect Gateway redirect (often disable)
8 0 Echo Request Ping request
11 0 TTL Exceeded in Transit Traceroute response
11 1 Frag Reassembly Timeout Fragment loss / reassembly issue
CONFIDENTIAL – INTERNAL USE ONLY Page 16
FIREWALL TROUBLESHOOTING GUIDE For Security Engineers
■ Never Block ICMP Type 3 Code 4
'Fragmentation Needed' (Type 3, Code 4) is essential for Path MTU Discovery (PMTUD). Blocking it
causes Black-Hole routing where large packets are silently discarded, resulting in intermittent failures for
bulk transfers and TLS handshakes.
Appendix C – Escalation Matrix Template
Populate this template for your organisation. Review quarterly.
Severity Trigger Condition Response SLA Escalation Owner Notify
SEV-1
Perimeter firewall down / total outage 15 min Network Lead CTO, CISO, NOC
(Critical)
SEV-2
Significant traffic blocked, business impact
30 min Senior Net Eng. NOC, App Owners
(Major)
SEV-3
Intermittent drops, performance degraded
2 hrs Network Engineer NOC
(Moderate)
SEV-4
Single host/app affected, workaround exists
8 hrs Network Engineer Ticket system
(Minor)
SEV-5
Informational anomaly, no current
Next
impact
business day Any engineer Ticket system
(Info)
This guide is a living document. Submit corrections and additions to the Security Engineering team. All procedures should
be validated against your specific platform firmware version and organisational change management policy before
implementation.
CONFIDENTIAL – INTERNAL USE ONLY Page 17