The Same Ten Problems, Every Time
We have tested firewalls from every major vendor across hundreds of engagements. The platforms change. The management interfaces change. The marketing language changes. The misconfigurations do not.
What follows is vendor-agnostic. These ten findings appear whether you are running Palo Alto, Fortinet FortiGate, Check Point, Cisco ASA, SonicWall or Sophos. They are not platform bugs. They are human configuration decisions that compound over time into serious security gaps.
1. Default or Weak Administrative Credentials
It sounds impossible in 2026. It is not. We regularly find firewall management interfaces accessible with default vendor credentials, factory passwords or simple variations like "admin123" and "firewall2024." Sometimes the default account has been renamed but the password remains unchanged. Sometimes a secondary administrative account was created for a vendor during deployment and never removed.
An attacker with administrative access to your firewall owns your network perimeter. Every rule, every route, every VPN tunnel is theirs to modify.
2. Any-Any Rules
Rules where the source is "any," the destination is "any" and the service is "any." These rules exist because someone needed to troubleshoot connectivity and created a rule that allows everything. The troubleshooting finished. The rule stayed.
In some environments we find any-any rules that have been active for years, passing traffic that bypasses every other restrictive rule in the policy. They are typically buried deep in the rule set where they are easy to overlook during manual review.
3. No Egress Filtering
Most firewall configurations focus on what comes in. What goes out receives far less attention. We routinely find environments where outbound traffic from internal networks to the internet is unrestricted on all ports.
This means an attacker who gains internal access can establish command-and-control channels on any port, exfiltrate data through any protocol and reach any external destination without restriction. Even behavioral detection tools struggle when outbound traffic is completely unrestricted because there is no baseline of what "normal" outbound traffic should look like.
4. Logging Disabled or Incomplete
Firewall logging is frequently disabled on high-volume rules to reduce log storage requirements. The problem is that high-volume rules are often the most important ones to monitor. When logging is disabled, you lose visibility into what traffic is traversing your most active pathways.
We also find environments where logging is enabled but log forwarding to the SIEM is broken. The firewall generates logs locally but nobody reviews them because the integration with the central monitoring platform failed months ago and was never repaired.
5. Outdated Firmware
Firewall firmware updates are disruptive. They require maintenance windows, testing and sometimes configuration migration. Many organizations defer updates for months or years. We regularly find firewalls running firmware versions two or three major releases behind, with known vulnerabilities that have published exploits.
A firewall running vulnerable firmware is not just a misconfigured control. It is an attack target. Threat actors actively scan for and exploit known firewall vulnerabilities because compromising the firewall gives them direct access to the network.
6. Overly Permissive VPN Configurations
Site-to-site VPN tunnels and remote access VPN configurations frequently grant more access than necessary. A VPN tunnel between two offices that allows full network access between sites eliminates the segmentation between those locations. A remote access VPN that places users directly on the internal network with no additional access controls treats VPN authentication as the sole security boundary.
VPN configurations should follow the same least-privilege principles as firewall rules. In practice, they rarely do.
7. No IPS Active
Many next-generation firewalls include intrusion prevention system (IPS) capabilities. We frequently find these capabilities licensed but not enabled, enabled but running in detection-only mode or enabled with default signature sets that have never been tuned for the environment.
An IPS that is not blocking is a monitoring tool at best. And if the alerts it generates are not being reviewed, it is expensive decoration.
8. Management Interface Exposed to the Internet
The firewall management interface should be accessible only from a dedicated management network or specific administrative workstations. We find management interfaces accessible from the internet, from the general user network or from guest wireless networks.
Exposing the management interface to the internet turns every firewall vulnerability into a remotely exploitable entry point. This is how some of the most significant firewall compromises in recent years have occurred.
9. No TLS/SSL Certificate Inspection
Modern firewalls can decrypt TLS traffic for inspection, but this capability requires certificate deployment, policy configuration and exception handling that many organizations never complete. Without certificate inspection, the firewall cannot examine the contents of encrypted traffic, which now accounts for over 90% of web traffic.
This means your firewall is making allow/deny decisions based on IP addresses and SNI headers rather than actual content. Malware delivered over HTTPS, command-and-control over encrypted channels and data exfiltration through HTTPS all bypass content-based rules.
10. Stale NAT Rules
Network address translation rules map external addresses to internal servers. When servers are decommissioned, the NAT rules frequently remain. A stale NAT rule that still forwards traffic to an IP address is harmless if that IP is unassigned. But if a new server or device is assigned that IP address, the stale NAT rule suddenly creates an unintended exposure.
We have found cases where decommissioned server IPs were reassigned to development workstations that then became directly accessible from the internet through forgotten NAT rules.
The Pattern Behind the Findings
None of these misconfigurations are sophisticated. None require advanced knowledge to fix. They persist because firewalls are configured once and maintained incrementally without periodic holistic review. Each individual change is reasonable. The accumulated effect is a security posture that diverges significantly from what the team believes it to be.
The only reliable way to find these issues is to test from the outside. To probe, push and verify. That is what a penetration test does that a configuration review cannot.
At Sherlock Forensics, we test firewalls as part of every network penetration test. We do not accept the configuration as authoritative. We verify it empirically. If you want to know how your firewall actually performs, not how it is supposed to perform, we should talk.