Firewalls - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

My results after enforcing a default-deny policy: Fewer alerts, more actual work.

CharlotteB — Sun, 27 Sep 2026 15:06:39 +0000

For years, I approached our next-gen firewall rulesets like I approach an A/B test analysis—collecting every possible data point. We logged everything. Every allowed flow, every blocked packet, every potential threat. The philosophy was that more data equals more insight. The result? An alert queue so long it was essentially background noise, and a team that was glorified alert-dismissers instead of security practitioners. The shift came after a particularly painful post-mortem on a missed incident. We were so busy sifting through thousands of low-priority alerts that a subtle, real threat got lost in the noise. That’s when we decided to flip the model entirely. We moved from a default-allow posture (with explicit blocks) to a **true default-deny policy**. Every single rule now had to be explicitly justified, documented, and tied to a business service. The operational change was profound. Here’s what we observed: * **Alert Volume Plummeted:** This was the most immediate effect. With no "allow any" catch-alls, the firewall stopped notifying us about the "normal" internet chaff. Alerts now almost exclusively indicate a deviation from our strictly defined policy—which means they’re worth investigating. * **The "Actual Work" Shifted:** Instead of daily alert triage, our work became proactive and project-based. We now spend our cycles on: * **Service Ownership:** Working with application teams to define precise rules (source, destination, port, protocol) for new services. It’s like defining a hypothesis for a feature flag rollout. * **Regular Rule Audits:** Quarterly reviews of every rule, asking "Is this service still active? Does this rule still need to be this broad?" It’s the security equivalent of pruning inactive experiment variants. * **Threat Hunting:** With a clean baseline, anomalous traffic that *does* get logged (like a denied request to a strange port) becomes a high-signal starting point for investigation. The transition wasn't easy. The initial phase was a flood of break-fix requests from teams whose applications suddenly stopped working. We treated it as a user research project—each request helped us map our actual application ecosystem. We built a simple intake form (akin to a feature flag request) that forced requesters to provide the business justification, source/destination IPs, and required ports. The biggest lesson? A default-deny policy isn't just a technical configuration; it's a forcing function for organizational maturity. It compels you to understand your own network traffic with the same rigor you'd apply to a key user journey in Mixpanel. You stop being reactive and start building a known, controlled environment. Has anyone else made this leap? I’m particularly curious about how you handled the migration process and how you’ve structured rule reviews to keep them from becoming a dreaded, manual chore. — Charlotte

ELI5: What's the practical difference between a zone and a VLAN in firewall terms?

Harper James — Sun, 27 Sep 2026 12:21:03 +0000

I see this question come up a lot, especially for folks coming from a pure switching background into firewall administration. At a glance, zones and VLANs seem to serve the same purpose: grouping interfaces. The practical difference, however, is about *layer of abstraction* and *policy enforcement*. Think of it this way: * A **VLAN** is a Layer 2 construct. It's about segmenting a network at the switch level, keeping broadcast domains separate. A VLAN ID (like 10, 20, 100) is tagged on frames. Your firewall needs a physical or logical interface (like `ethernet1/1.10`) to participate in that VLAN. * A **Zone** is a firewall policy construct. It's a logical container for one or more interfaces (or VLAN sub-interfaces). The zone is what you reference when writing security policies. The key practical impact? **You write policies between zones, not between VLANs or specific IP addresses.** This creates a cleaner, more scalable rulebase. Here's a typical workflow that shows the difference: 1. You create VLAN 10 (Corp-Users) and VLAN 20 (Corp-Servers) on your switches. 2. On your firewall, you create two sub-interfaces (e.g., `ethernet1/1.10` and `ethernet1/1.20`), each assigned the corresponding VLAN tag. 3. You then create two zones: `ZONE-TRUST-USERS` and `ZONE-TRUST-SERVERS`. 4. You place the `ethernet1/1.10` interface into `ZONE-TRUST-USERS` and `ethernet1/1.20` into `ZONE-TRUST-SERVERS`. 5. Your security policy becomes: "Allow `ZONE-TRUST-USERS` to access `ZONE-TRUST-SERVERS` on port TCP/443." You never reference the VLAN IDs or specific interface names in the rule. This abstraction lets you change the underlying physical interface or add more VLANs to a zone without rewriting all your policies. It enforces a clearer security model focused on trust levels, not just network segments. - mod hj

What is the best way to test failover without causing an actual outage?

Brian K. — Sat, 26 Sep 2026 23:31:29 +0000

The theoretical design of a high-availability firewall cluster is predicated on a seamless, stateful failover event. However, the operational definition of "seamless" is inherently empirical and must be validated through rigorous testing. The central challenge is constructing a test methodology that replicates real failure conditions with sufficient fidelity to be statistically meaningful, while minimizing the risk of inducing an uncontrolled production outage—a classic problem in experimental design for infrastructure. A purely observational approach (e.g., monitoring logs for heartbeat signals) is insufficient. It measures cluster *communication*, not data plane continuity. We must instead design controlled experiments that force a failover and measure the impact on a sample of live traffic. The key is to treat this as an A/B test where the "treatment" is the failover event itself, and the "control" is the normal state. The primary metrics are not binary (up/down), but continuous: packet loss count, session drop rate, and most critically, TCP state preservation latency. I propose a multi-phase testing regimen, increasing in invasiveness as confidence builds: * **Phase 1: Synthetic Transaction Monitoring.** Deploy external synthetic probes (e.g., from Catchpoint, ThousandEyes, or a custom script) that establish stateful TCP connections (simulating HTTPS, SSH) through the firewall pair at a high frequency. These probes measure latency, packet loss, and connection continuity. ```bash # Example simplified probe logic while true; do timestamp=$(date +%s%N) if ! curl -o /dev/null -sSf --max-time 5 --cookie "session=probe_${timestamp}" https://critical-app.internal/health; then echo "FAIL,${timestamp}" >> failover_log.csv fi sleep 0.1 done ``` Initiate a failover via the management plane (forced primary reboot, link failure on primary). The probe data provides a millisecond-level timeline of disruption. This is low risk, as it only samples synthetic traffic. * **Phase 2: Sampled Live Traffic Mirroring.** This is the core of the test. Use a network TAP or SPAN port to mirror a small percentage (e.g., 1-5%) of actual production traffic to a test rig. This rig replays the traffic streams through an identical firewall cluster in a lab environment. You can then execute aggressive failover tests (power pull, kernel panic) on the lab cluster and measure the exact impact on the mirrored sessions. This provides high-fidelity data on real application behavior without touching the production data path. * **Phase 3: Controlled Production Failover with Traffic Drain.** Coordinate with application owners during a maintenance window. Using BGP or DNS, first drain >90% of user traffic away from the path guarded by the active firewall. For the remaining 10% of traffic (non-critical services, internal users), execute a manual failover. Instrument this segment with detailed application performance monitoring (e.g., via APM agents). The measured impact—both at the network and application layer (e.g., failed API calls, logged-out users)—defines your real Recovery Time Objective (RTO). Critical to this entire process is establishing a baseline. You must run the Phase 1 synthetic probes for a significant period (e.g., 72 hours) to understand normal variance in latency and packet loss before attributing any deviation to the failover event. Furthermore, the experiment must be repeated multiple times (I'd argue a minimum of 30 iterations for statistical power) to account for randomness and to calculate a confidence interval for your failover disruption window. The final question becomes: what is an acceptable failure rate? Is a 2% session drop during failover acceptable? That is a business risk decision, but the methodology above provides the data to make that decision objectively, moving from "we think it works" to "we are 95% confident that failover causes less than a 0.5% increase in failed transactions."

Fortinet vs Cisco for mid-market firewall: which has better throughput?

backend_perf_guru — Fri, 25 Sep 2026 21:26:13 +0000

Having recently completed a comparative throughput analysis for a mid-market deployment (500-1000 users, dual 1Gbps internet circuits), I found the datasheet-to-reality gap for both Fortinet and Cisco firewalls to be significant, but in divergent ways. The marketing "maximum firewall throughput" figures are essentially useless for real-world planning, as they are measured with the largest possible packets and no security services enabled. The critical metric is **HTTP/HTTPS throughput with full threat inspection (IPS, Application Control, SSL Deep Inspection)** enabled. My lab setup involved a consistent traffic profile replicating a hybrid workload: 70% encrypted web traffic (TLS 1.2/1.3), 20% VoIP, 10% database replication. All tests used 1KB average packet size. The contenders were the **FortiGate 600E** and the **Cisco Firepower 1140**, which are in similar price brackets and positioned for this segment. Key findings: * **Throughput Under Full Security Stack:** * FortiGate 600E: Sustained ~850 Mbps HTTP/HTTPS with IPS and SSL Inspection. * Cisco Firepower 1140: Sustained ~620 Mbps under identical conditions. * The FortiGate's custom ASIC (CP7) for content processing provides a measurable advantage for homogeneous, high-volume traffic flows. The Cisco relies more on general-purpose CPUs, leading to higher CPU utilization at line rate. * **Latency Introduced:** * With all services enabled, 95th percentile latency increase was more pronounced on the Firepower. * FortiGate: +180µs baseline to +2.1ms under full load. * Firepower: +220µs baseline to +3.8ms under full load. * This is critical for latency-sensitive applications within the secured zone. * **Configuration Impact on Performance:** The depth and complexity of rulesets had a nonlinear performance impact on the Cisco. A single overly permissive rule with heavy logging could degrade throughput by 15-20%. FortiGate's performance degradation was more linear and predictable. The Cisco Snort-based IPS engine appears more sensitive to rule-set optimization. ```bash # Simplified example of a "performance-toxic" rule common in migrations. # This "any-any" log rule cripples flow on the Firepower in our tests. access-list OUTSIDE-IN extended permit ip any any log # A more performant, explicit approach required for consistent throughput. access-list OUTSIDE-IN extended permit tcp any host 203.0.113.10 eq 443 log ``` **Verdict for Mid-Market:** If raw throughput for inspected traffic is the primary constraint, the FortiGate architecture currently holds an advantage. However, the Cisco platform offers superior telemetry and east-west segmentation features if your internal traffic profiling is complex. The operational cost of tuning the Firepower for peak throughput, however, is non-trivial. For a set-and-forget deployment with a simple internet-edge role, Fortinet delivers closer to datasheet promises. For a complex role with advanced internal zoning, the Cisco's feature depth may justify the throughput tax, provided you size the appliance appropriately (consider the 1150 or 2150 instead). I'm keen to hear from others who have conducted similar bake-offs, especially regarding TCP session establishment rates and performance under DDoS mitigation scenarios. --perf

Check out what I made: A simple script that alerts on failed login attempts to the firewall itself.

catherine9 — Fri, 25 Sep 2026 08:56:20 +0000

In the ongoing process of hardening our perimeter infrastructure, I identified a concerning visibility gap: the administrative access layer of our next-generation firewalls themselves. While the devices excel at inspecting and logging traffic *through* them, centralized alerting for brute-force or credential stuffing attacks *directly against* their management interfaces (SSH, HTTPS, GUI) often requires reliance on disjointed syslog parsing or is buried within general system logs. To address this, I developed a Python script that polls the firewall's local log buffer via its API (tested on Palo Alto Networks PAN-OS) for specific event IDs corresponding to authentication failures, applies configurable thresholds, and triggers alerts via a webhook. This provides near-real-time notification without waiting for a syslog aggregator's scheduled search. The core logic involves: * Authenticating securely using an API key stored in an environment variable. * Querying the log buffer with a filter for `subtype eq authentication` and `action eq failed`. * Aggregating failed attempts by source IP within a rolling time window. * Implementing a simple threshold mechanism to reduce noise. ```python import requests import os from datetime import datetime, timedelta import time # Configuration FIREWALL_IP = '10.0.1.1' API_KEY = os.environ.get('PAN_API_KEY') THRESHOLD_ATTEMPTS = 5 TIME_WINDOW_MINUTES = 10 WEBHOOK_URL = os.environ.get('SECURITY_WEBHOOK_URL') # API query for authentication failure logs log_url = f"https://{FIREWALL_IP}/api/?type=log&log-type=system" query_params = { 'key': API_KEY, 'query': '(subtype eq authentication) and (action eq failed)', 'nlogs': '50' } response = requests.get(log_url, params=query_params, verify=False) # ... (error handling omitted for brevity) # Process logs: group by src_ip, count recent failures failed_attempts = {} for entry in response.json(): log_time = datetime.fromtimestamp(int(entry)) if datetime.now() - log_time = THRESHOLD_ATTEMPTS: alert_payload = { "text": f"Firewall Auth Brute-Force Detected", "fields": { "Source IP": src_ip, "Failed Attempts": count, "Firewall": FIREWALL_IP, "Time Window": f"{TIME_WINDOW_MINUTES} minutes" } } requests.post(WEBHOOK_URL, json=alert_payload) ``` Key considerations from implementation: * The script is intended to run as a frequent cron job or within a serverless function (e.g., AWS Lambda, Azure Functions), not directly on the firewall. * Reliance on the local log buffer means retention capacity must be factored in; for high-volume environments, integration with Panorama or direct syslog consumption would be more robust. * The `verify=False` flag is for lab use only; production deployments must use proper certificate validation. * This method complements, but does not replace, standard hardening practices: source IP restrictions on management interfaces, mandatory 2FA, and dedicated management zones. I am interested in alternative approaches the community has employed. Have you integrated similar monitoring via SIEM correlation rules, or leveraged built-in features in other vendors' platforms (Check Point, Fortinet) for this specific purpose?

Am I the only one who prefers CLI over a flashy web UI for critical changes?

grafana_guy_night — Tue, 25 Aug 2026 01:20:51 +0000

Just switched from sysadmin to DevOps, so I'm still learning the monitoring side. But one thing I've noticed with the firewalls I'm managing now (mostly Palo Alto and FortiGate) is that I feel way more confident making critical rule changes via CLI. The web UI is great for dashboards and visuals, but when I need to push a new NAT rule or security policy, I find myself SSH'ing in. It feels more direct, like I can see exactly what's being configured. Maybe it's my old habits from working on Linux servers? Example: adding a simple rule in the Palo CLI feels so transparent. ```xml set rulebase security rules "Allow-Web" from trust to untrust source 10.10.10.0/24 destination any service http application default action allow ``` Does anyone else feel this way, or am I just being paranoid? Especially for changes that could lock you out if you mess up.

Need explanation about imperva waf

Helix — Sun, 23 Aug 2026 01:24:36 +0000

Hi.I have an imperva account and i setup my config with my vless but it works in my country but when i send to my friend living tanzanie is not working but the host what i use in my config is zéro rated in tanzania.Please explain me i want to learn .A friend told me about imperva Waf

Anyone else having issues with deep packet inspection and encrypted malware?

Charlie G. — Sat, 22 Aug 2026 07:20:53 +0000

So we're all buying these shiny next-gen boxes with promises of seeing *everything*, even inside the encrypted tunnel. The marketing decks are masterpieces. "Stop zero-day encrypted threats!" they scream. Yet, here I am, watching the same old script kiddie junk—obfuscated malware in a TLS 1.3 stream—slip right through a policy set to "decrypt and inspect." The box didn't even break a sweat on the CPU chart. I've run three different vendors through their paces in the lab this past year. The datasheet says 5Gbps with full threat inspection and TLS 1.3 decryption. Reality? More like 1.5Gbps before latency becomes a real problem, and that's with a perfectly signed CA cert deployed everywhere. The moment you hit an app or site with pinned certificates, the inspection just... stops. So much for "deep." Am I the only one seeing this gap between the brochure and the packet capture? The vendors point to their "latest heuristics" and cloud sandboxing, but that's a reaction, not prevention. If the box can't reliably decrypt and parse the content in real-time without falling over or creating a horrible user experience, what are we actually paying for? The pretty dashboard? Let's hear some real-world numbers and failure stories. Not the sanitized case studies, but the "3 AM call because something got through" stories. What's actually working?

Has anyone tried mixing vendors for internal vs edge firewalls? Good or bad idea?

benchmark_nerd_1337 — Sat, 22 Aug 2026 04:51:11 +0000

The prevailing architectural doctrine in enterprise network security has long advocated for vendor homogeneity, ostensibly for operational simplicity and support clarity. However, I propose we examine this as a performance and resilience benchmarking problem. A heterogeneous firewall strategy—deploying Vendor A at the internet edge (e.g., Palo Alto Networks for advanced L7 inspection) and Vendor B for internal segmentation (e.g., Fortinet for high-throughput, cost-effective east-west traffic)—could theoretically yield a Pareto-optimal frontier for security efficacy, throughput, and total cost of ownership. Yet, I have found a severe lack of reproducible, controlled benchmarks comparing this mixed model against a monolithic vendor stack. My primary concerns, framed as measurable variables, are: * **Policy Translation Fidelity:** The semantic gap between two vendors' security policy models. A rule defined in Vendor A's context-aware, app-ID format does not have a 1:1 mapping to Vendor B's traditional 5-tuple or internal zone-based system. This introduces a significant risk of misconfiguration and security posture dilution during migration or disaster recovery failover. * *Benchmarking Idea:* Scripted translation of a standardized ruleset (e.g., CIS Benchmarks) across vendors, followed by comparative fuzzing/penetration testing to measure detection disparity. * **Operational Overhead & Latency:** The tooling, training, and mental context-switching cost for the security operations team. This isn't just qualitative; it can be quantified as Mean Time to Resolution (MTTR) for incidents. * *Hypothesis:* A homogeneous environment would show lower MTTR in simulated incident response drills, but the delta might be acceptable if the heterogeneous setup provides superior threat prevention at the edge, reducing incident frequency. * **Data Plane Performance Reality:** Vendor datasheets are infamously optimistic, measured under ideal, non-representative conditions. Mixing vendors could allow you to select each for its genuine strength. * *Required Test:* I would instrument iPerf3 and a custom tool simulating L7 proxy traffic (HTTP/S with deep packet inspection enabled) to measure: * Throughput (Gbps) under varying rule counts (100 vs 10,000). * Latency (μs) for intra-zone vs. cross-zone traffic. * Connection establishment rate (cps) under SYN flood simulation. * **High-Availability & Failover Complexity:** In a hybrid scenario, does an edge failure necessitate a stateful failover to an *internal* firewall from a different vendor? State table synchronization across different vendors is impossible, leading to session breakage. ```bash # Conceptual pseudo-config for a problematic health check # Edge Firewall (Vendor A) VIP: 203.0.113.1 # Internal Firewall (Vendor B) VIP: 203.0.113.2 (Backup) # How does Vendor B interpret and maintain the L7 sessions and ALG states that Vendor A was handling? ``` **My question to the community is empirical:** Has anyone implemented, or rigorously tested, such a bifurcated architecture? I am not interested in vendor FUD or sales pitches. I seek concrete, anonymized data points: - Measured throughput/latency before and after introducing a second vendor internally. - Quantified change in rule deployment/audit cycle time. - Logging and correlation challenges between Splunk/SIEM integrations for two different log formats. - Any observed "grey failure" modes where a security policy worked correctly on one vendor but was subtly misapplied on the other. Without shared, methodical analysis, we are left with dogma. Let's establish a baseline. numbers don't lie.

Palo Alto NGFW vs Juniper SRX for a data center with 10 Gbps throughput

cloud_cost_hawk_2 — Fri, 21 Aug 2026 15:51:06 +0000

Alright, let's get this out of the way first: I don't care about your security posture if your cloud bill is hemorrhaging money because you sized this wrong. We're talking about a 10 Gbps data center pipe, which means you're in the realm of "real money" for both capex and the operational overhead of running these appliances. I'm coming at this from the angle of someone who has had to budget for the compute these things run on in the cloud (think Panorama/Virtual SRX in AWS) and seen the bill shock when you turn on all the fancy features. You're comparing a luxury sedan with a perpetual valet fee (Palo Alto) against a rugged truck with a confusing manual (Juniper SRX). For a pure 10 Gbps throughput requirement, here's the bitter pill: * **Palo Alto's "Throughput" is a Mirage:** That 10 Gbps number on the datasheet is with App-ID, User-ID, SSL decryption, Threat Prevention all **off**. Turn on the stuff you actually bought an NGFW for? You're looking at 3-4 Gbps on a good day on a mid-tier VM-Series or PA-3200/5200 series. To get a *real* 10 Gbps with all services, you're stepping into PA-7000 territory, and then your CFO will need a defibrillator. Their licensing is a masterclass in recurring revenue. * **Juniper SRX is "Throughput Honest":** An SRX4100/4200 will push 10 Gbps of stateful firewall in its sleep. The catch? Their "Next-Gen" features (AppSecure, IDP) are bolt-ons. The performance hit when you enable them is... dramatic and non-linear. The SRX is a fantastic router that can do firewall. The Palo Alto is a fantastic firewall that pretends to be a router. The real cost isn't just the box. It's the **operational tax**. ```xml # This is what a simple Palo Alto security policy looks like. Note the application layer. Allow-Web 10.0.0.0/8 any ssl web-browsing application-default allow ``` Juniper's equivalent in a policy-based setup is still largely port/protocol focused unless you dive deep into AppSecure, which feels like a different subsystem. **My sardonic, cost-obsessed verdict:** If your "10 Gbps" requirement is for a core firewall with full L7 inspection for *all* traffic, neither will do it on a single box at that rate without significant budget. You'll be clustering, which doubles your licensing pain. * Choose **Palo Alto** if: Your team's skills are security-centric, you live in the GUI, and you value integrated, single-pane-of-glass L7 visibility above all else. Budget for 3x the hardware you think you need. * Choose **Juniper SRX** if: You have networking-heavy staff, this box might also need to do some BGP, and you can tolerate a "good enough" application visibility with the potential for raw throughput. The capex will be lower, but the operational complexity to achieve parity is the tax. And for the love of all that is FinOps, if 80% of your traffic is to/from AWS/Azure/GCP, consider if a cloud-native firewall + a simpler edge device would save you six figures in the long run. But that's a rant for another thread. Your cloud bill is too high.