Firewall Penetration Testing: What It Covers

When a company asks us to “test the firewall,” it is asking two questions. From outside: what can an attacker on the internet reach, and can they get through? From inside: if an attacker lands on one laptop, what can the network rules stop them from reaching? A firewall penetration test answers both by attacking through the firewall the way an adversary would, then comparing what is actually reachable with what should be. It is part of our network testing, at a fixed price with a free retest: external from $4,200, internal from $6,000.

What “testing the firewall” means

A firewall is a set of rules and the device that enforces them. Testing it means testing what those rules let through, not reading them.

• The external view covers everything the firewall exposes to the internet: services, management interfaces, VPN gateways and the edge appliance itself.
• The internal view covers segmentation: whether the rules between user, server, management and cardholder zones hold when someone tries to cross them.
• The outbound view covers egress: what an attacker inside the network can send out.

Most firewall findings are not flaws in the firewall product. They are rules that allow more than anyone intended, left behind by a vendor, a troubleshooting session or a migration.

The external view: exposure and the edge

From the internet, we find every host and service your firewall exposes, then test each one.

• Exposed services. Port and service discovery across every address range in scope. Anything answering that should not be is a finding, and anything answering that should be gets tested for weaknesses.
• Management interfaces. Web consoles, SSH and SNMP on the firewall or other devices reachable from the internet. These should almost never face the public internet.
• VPN and remote access. The VPN gateway, its configuration, and whether MFA covers every remote access path. Edge appliances are a favorite target because they sit outside everything else and carry a lot of trust.
• Known vulnerabilities on the appliance. Firewall and VPN firmware with public exploits is tested safely to confirm whether it is exploitable.
• Rule consistency. Whether the same rules apply from different source addresses, over IPv6 as well as IPv4, and to traffic that arrives from ports that are often trusted, such as DNS.

Our external network penetration testing service is scoped around this view, and it starts at $4,200 for a small internet-facing footprint.

The internal view: segmentation between zones

Segmentation is the promise that one compromised machine cannot reach everything. We test it from inside, starting in the zones an attacker is most likely to land in.

• User to server. From a standard workstation network, which servers, databases and file shares answer?
• User to management. Can a user network reach switch, hypervisor, backup or firewall management interfaces? This is one of the most common paths to taking over an environment.
• Guest and IoT networks. Does the guest Wi-Fi really lead only to the internet? Do cameras, printers and building systems sit on the same network as finance? An on-site wireless penetration test checks the Wi-Fi side from inside the office.
• Sensitive enclaves. Cardholder data, CUI or other regulated zones, tested from every adjacent network for any path in: direct routes, shared services, jump hosts and management interfaces.

We report which zone can reach which, and on which ports, against the policy you told us you have. Internal network penetration testing starts at $6,000 and covers segmentation along with Active Directory and lateral movement.

Attacker-side rule review, not a console audit

There are two ways to review firewall rules.

A console-side configuration audit logs into the firewall management console and reads the rule base line by line, looking for redundant, shadowed and overly broad rules. It is a documentation exercise and a useful one, and it is not what we do.

An attacker-side rule review tests what the rules actually allow, from the places an attacker would stand. We ask you for the intended policy: which zones should reach which, and on which ports. Then we test it. Every difference between the policy and reality is a finding, with the evidence to reproduce it.

The attacker-side review catches what a console audit can miss: a NAT rule that exposes a host nobody expected, a route that bypasses the firewall entirely, an IPv6 path that was never filtered, or a rule that looks narrow but applies to a group of objects someone later expanded. It also produces evidence that segmentation works, which is what an assessor or auditor wants to see.

If you need a rule-by-rule configuration audit as well, have it done by whoever administers the firewall. Our test tells you whether the result holds up against someone trying to get through.

PCI DSS segmentation testing

If you use segmentation to keep systems out of PCI DSS scope, you have to prove it works. Under Requirement 11.4.5, segmentation controls must be penetration tested at least every twelve months and after any change to them. Service providers must test every six months under 11.4.6. The tester starts in the out-of-scope networks and tries to reach the cardholder data environment by every path. Success means no path exists. Our network segmentation testing page explains how the test runs inside an internal engagement or as a standalone six-monthly re-validation.

A failed segmentation test does not only mean a finding. It means the systems you thought were out of scope are in scope, with every PCI requirement that comes with that. Our guide to PCI DSS penetration testing requirements covers all of Requirement 11.4, and our PCI DSS page covers how we run the engagement.

Egress: what can leave the network

Most firewall rule sets are strict inbound and loose outbound. That matters because modern attacks depend on outbound connections. Ransomware operators need to reach their own servers. Stolen data needs a way out.

From inside, we test which ports and protocols can leave: arbitrary HTTPS, DNS to outside resolvers, SMB, SSH and other channels. If a compromised workstation can connect to any host on the internet on any port, that is a finding. Egress filtering will not stop a skilled attacker on its own, but it slows them down and gives your monitoring a chance to notice.

What a firewall test finds

Common findings when we test through a firewall:

• Management interfaces for the firewall, VPN or other devices reachable from the internet or from user networks.
• VPN gateways running firmware with a known exploit, or accepting weak configurations.
• “Temporary” allow-any rules added for a vendor or a troubleshooting session and never removed.
• Flat networks where segmentation exists on the diagram but not on the wire.
• IPv6 enabled on internal hosts with no matching filtering.
• Guest or IoT networks that can reach internal servers.
• Unrestricted outbound traffic from servers that never need to start a connection to the internet.

What it costs

Firewall testing is priced as part of a network test, at a fixed price agreed in writing before work starts.

Engagement	Covers	Starting price
External network penetration test	Internet exposure, edge appliances, VPN and remote access	$4,200
Internal network penetration test	Segmentation, egress, Active Directory and lateral movement	$6,000

Most companies that say “test the firewall” need both, which is what our network penetration testing engagement combines. Every penetration test includes executive and technical reports, an attestation letter and a free retest of what you fix. Pricing by scope size is on the external network pricing page. For the wider picture of network testing, see our guide to network penetration testing and the step-by-step network penetration testing checklist.

Frequently asked questions

What is firewall penetration testing? Testing what your firewall rules actually allow by attacking through them: from the internet, between internal zones, and outbound. It shows whether the firewall enforces the policy you think it does.

Do you need access to the firewall console? No. We test from the attacker’s side. A copy of the intended policy, or a zone diagram, makes the test sharper because every gap between the policy and reality becomes a clear finding.

Is this the same as a firewall audit? No. A firewall audit reviews the configuration from the management console. A penetration test proves what an attacker can reach. They answer different questions, and we do the second. Our network security audit checklist shows where each fits in a wider network assessment.

How often should firewall segmentation be tested? PCI DSS asks merchants to test segmentation at least every twelve months and service providers every six months, and both after changes to segmentation. Outside PCI, test at least annually and after firewall migrations, new sites or major rule changes.

Can the test disrupt the firewall? We test safely and do not use denial-of-service techniques. Timing and any sensitive systems are agreed in the rules of engagement before testing starts.

Fixed price, fixed scope, free retest. Scope your test and get a written price within one business day.