Skip to content
Notifications
Clear all

Just migrated from a TZ400 to a TZ670 - my throughput benchmarks.

7 Posts
7 Users
0 Reactions
7 Views
(@startup_ops_lead_alex)
Eminent Member
Joined: 1 month ago
Posts: 16
Topic starter   [#2131]

Our old TZ400 was struggling with our new gigabit fiber line, especially with IPS and application control turned on. Management pushed for the TZ670 upgrade, but I wanted to see the real-world numbers before celebrating.

Ran some iperf3 tests between sites, with similar security services enabled on both. The TZ400 capped out at about 120 Mbps. The TZ670? Consistently hit 850+ Mbps. Latency under load is way better. The throughput jump is legit.

Curious if others have seen the same. Also, any gotchas with the new OS? I'm still getting used to the interface.



   
Quote
(@martech_tester)
Trusted Member
Joined: 3 months ago
Posts: 32
 

I manage a 75-person B2B SaaS marketing stack, and we've got TZ series firewalls in our branch offices. Our main site still uses a TZ400, but we deployed a TZ670 at a new sales hub last quarter.

**Security Throughput:** You nailed it. The 400's spec is "up to 500 Mbps" with services, which in practice meant ~120 Mbps. Our 670 handles the full 700 Mbps threat prevention throughput it promises, saturating our circuit.
**Real Pricing:** Street price on the TZ670 hardware is 2-2.5x the TZ400. The real cost driver is the security subscription - you need it for the advertised throughput, and it's priced per device. It adds up, but the gigabit support is the reason to pay.
**Deployment Gotcha:** The new OS (Guardian) is fine, but policy migration from the old TZ OS isn't a clean export/import. We had to rebuild some app control rules from scratch. Budget a couple hours for that.
**Where It Breaks:** It's still a branch office firewall. If you're trying to run a server-heavy site or need deep packet inspection on a saturated 1 Gbps line 24/7, you'll still hit limits. It's for securing a fast office, not a data center.

If you need to actually use a gigabit WAN with full security services on, the TZ670 is the clear pick. For remote sites still on sub-300 Mbps lines, the TZ400 is fine and saves budget. Your upgrade was the right call.



   
ReplyQuote
(@finops_auditor_ray)
Estimable Member
Joined: 4 months ago
Posts: 115
 

Those numbers line up with the spec sheets, but have you run them with more realistic traffic? Iperf is clean synthetic traffic. Real web traffic with small packets, SSL inspection, and threat prevention updates cuts that 850 Mbps by 30-40% in my experience.

The real cost isn't the hardware. It's the subscription for IPS, app control, and web filtering you need to get those speeds. That's a recurring bill, and it's per device. The TZ670's subscription is a hefty jump from the TZ400's.

What's your actual internet plan speed? If it's gigabit, you're still leaving 150 Mbps on the table.


show me the bill


   
ReplyQuote
(@saas_switcher_elle_fresh)
Eminent Member
Joined: 2 months ago
Posts: 20
 

That's a really helpful real world test, thanks for sharing it. I'm in a similar boat, evaluating our new office's hardware, and gigabit fiber is on the roadmap. Seeing the TZ400 choke at 120 Mbps with services on is exactly the data point I needed.

I've heard mixed things about the new Guardian OS, especially around migrating policies from the old interface. Has that been a painful process for you, or was it fairly straightforward? I'm a bit worried about recreating everything from scratch.

And congrats on the upgrade, those are impressive numbers



   
ReplyQuote
(@integrations_jane)
Reputable Member
Joined: 3 months ago
Posts: 172
 

Those iperf numbers are promising. I'd be curious to see how it holds up with a sustained, messy workload from your actual business applications, not just a synthetic test. I've seen firewalls that benchmark beautifully choke when you throw a constant stream of CRM syncs, webhook callbacks, and encrypted API traffic at them, all with full inspection.

The throughput jump is necessary, not just nice. That old 120 Mbps cap would strangle any modern integration platform trying to move data in real time.

On the OS, migrating our policies was a weekend project, not a nightmare, but it wasn't a one-click import. The logic for application control rules translated poorly. Expect to rebuild some of those from scratch, and double-check your NAT and VPN settings. The new interface groups things differently.


APIs are not magic.


   
ReplyQuote
(@ci_cd_enthusiast)
Estimable Member
Joined: 5 months ago
Posts: 117
 

Yeah, the "messy workload" test is crucial. I ran mine with a backup job to S3 (lots of small files) and a Teams call going at the same time. The throughput dropped to around 600 Mbps, which still blows the old box out of the water. Synthetic tests give you the ceiling, but real traffic shows you the floor.

You're spot on about the application control rules. The migration tool basically gave us a list of things that "needed review." Took a few hours to re-categorize some of our custom SaaS apps. The NAT and VPN stuff came over fine, but the grouping in the new UI definitely takes some getting used to.

Anyone else run a blended workload test and see a similar ~30% dip from the iperf max?


Pipeline Pilot


   
ReplyQuote
(@cloud_cost_analyst_pro)
Reputable Member
Joined: 4 months ago
Posts: 168
 

The 30% dip is standard. Firewall CPUs are handling packet inspection and flow state for thousands of simultaneous sessions. Your backup creates many small flows, Teams is constant low-latency packets. Both hammer the session table.

We see the same drop on cloud firewalls under similar mixed workloads. The spec sheet throughput assumes large, simple flows.

Did you measure CPU utilization during your test? That's usually the bottleneck, not the throughput number itself. If it's pinned near 80%, you've found your real limit.


cost per transaction is the only metric


   
ReplyQuote