Corero vs Flowtriq: what your
DDoS protection is missing

Back to Blog

Corero Does Inline Mitigation Well

Before getting into gaps, it is worth saying clearly: Corero SmartWall is a well-built product for its use case. Always-on, sub-second inline filtering with surgical packet dropping at wire speed. For service providers and hosting companies that need to scrub attack traffic before it reaches customer infrastructure, SmartWall delivers.

Its strengths are real and well-established:

• Always-on inspection. SmartWall sits inline and inspects every packet continuously. There is no "detect then divert" delay. Mitigation happens in the traffic path, automatically, from the first malicious packet.
• Surgical filtering. SmartWall drops attack packets while letting legitimate traffic from the same source ranges pass through. This precision matters for hosting providers where blackholing a target IP would affect other customers sharing that infrastructure.
• Service provider architecture. Multi-tenant policies, per-customer reporting, throughput tiers from 10 Gbps to 100+ Gbps per appliance. SmartWall is purpose-built for operators who sell DDoS protection as a service.
• Juniper MX compatibility. SmartWall integrates well with Juniper MX series routers, which are common in service provider edge deployments. The combination of SmartWall inline with MX routing is a proven architecture in production SP networks.

We have written a full side-by-side comparison of Flowtriq and Corero SmartWall. This post takes a different angle: the specific visibility gaps that exist when SmartWall is your only DDoS layer, and how adding per-server detection closes them.

What Corero Cannot See

SmartWall sees traffic at the network edge. That is its vantage point, and it is a good one for volumetric mitigation. But it means SmartWall has no visibility into what happens on individual servers behind it.

Specifically:

• No per-server baselines. SmartWall builds traffic profiles at the network interface and managed-object level. It does not know that your game server normally sees 12,000 PPS on a Tuesday but 45,000 PPS during a weekend tournament. It does not know that your API server's baseline is 3,000 PPS and a jump to 15,000 is anomalous. Without per-server context, SmartWall applies network-level thresholds to server-level problems.
• No server-side PCAP. SmartWall can capture packets at the appliance. But that capture reflects what SmartWall saw, including the traffic it dropped. It does not show what actually reached your server's application. For incident response, the question your team needs to answer is: "what hit the application?" Not: "what did the edge appliance see?"
• No per-node attack classification. When SmartWall reports a SYN flood against a customer prefix, it is reporting a network-level event. It cannot tell you which of the 50 servers behind that prefix was the actual target, how each server was affected individually, or whether the attack pattern differed across nodes.

Traffic that passes through SmartWall reaches servers undetected in several scenarios: sub-threshold attacks that look like normal aggregate traffic, application-layer attacks that use valid-looking HTTP requests, attacks within encrypted tunnels that SmartWall cannot inspect, and multi-vector attacks where one component falls below the filtering threshold while another is caught.

The Per-Server Blind Spot

This is the most common scenario we hear from operators adding Flowtriq behind SmartWall.

You have 200 servers behind SmartWall. A 50,000 PPS spike hits one of those servers. At the network aggregate level, that is a rounding error. SmartWall sees millions of packets per second across the entire deployment. An additional 50,000 PPS distributed across one managed object does not trigger any anomaly threshold.

But on that specific server, 50,000 PPS might be five times its normal traffic. The server's application starts dropping connections, response times climb, and your customer opens a support ticket. Your NOC checks SmartWall and sees nothing abnormal. Because at the network level, there was nothing abnormal.

Flowtriq on that server detects the spike within 1-2 seconds. It knows the server's baseline is 10,000 PPS. It classifies the attack (UDP flood, SYN flood, DNS amplification, whatever it is), captures a 60-second PCAP of the traffic, and fires an alert to your Slack channel with the full breakdown. Your NOC has the data they need before the customer finishes writing the ticket.

This is not a failure of SmartWall. It is a limitation of edge-only visibility. The further you are from the target, the harder it is to distinguish an attack on one server from normal aggregate traffic patterns.

Juniper MX Compatibility

Many operators running Corero SmartWall also run Juniper MX series routers at their network edge. If you are in this category, adding Flowtriq does not require changes to your routing infrastructure.

Flowtriq's BGP adapters (ExaBGP and GoBGP) peer directly with Juniper MX routers using standard BGP. When Flowtriq detects an attack on a specific server, it can trigger:

• RTBH routes announced to your MX router via BGP, using your existing blackhole community. The MX drops traffic to the targeted prefix at the routing level.
• FlowSpec rules announced via BGP to Juniper MX routers that support BGP FlowSpec (MX240, MX480, MX960, MX10003, and others with Junos 15.1+). FlowSpec provides granular filtering by protocol, port, packet length, and other fields without blackholing the entire prefix.

The integration works with the same MX routers that SmartWall uses. Your migration path if you choose to add Flowtriq: keep Corero for inline edge filtering, add Flowtriq agents on your servers for per-node detection depth, and optionally configure Flowtriq's BGP adapter as an additional mitigation trigger that peers with your existing MX infrastructure.

# Example: Flowtriq BGP adapter peering with Juniper MX
adapter: exabgp
neighbor: 10.0.0.1          # Juniper MX loopback/peering IP
local-as: 65001
remote-as: 65000
next-hop: 192.0.2.1          # Blackhole next-hop (discard route on MX)
community: 65000:666         # Your RTBH community

For FlowSpec-capable MX deployments, see the FlowSpec Rule Builder for generating Junos-compatible FlowSpec rules.

PCAP: The Evidence Gap

Both Corero and Flowtriq can capture packets. The difference is where the capture happens, and that difference matters more than it might seem.

Corero's capture happens at the SmartWall appliance. This shows you what SmartWall saw: the full inbound traffic including attack packets that were subsequently dropped. It is useful for understanding the attack composition at the network edge and for verifying that SmartWall's filtering rules are working correctly.

Flowtriq's capture happens on the target server. This shows you what actually reached the application after all upstream filtering (SmartWall, upstream scrubbing, transit provider filtering) has been applied. This is the ground-truth record of what your customer's server experienced.

For incident response and customer reporting, the server-side perspective answers the questions that matter most:

• Did any attack traffic get through our upstream mitigation?
• What exactly hit the application, and for how long?
• Was the impact caused by the attack volume, or by specific packet characteristics that the application could not handle?
• Can we provide the customer with a forensic-quality capture of the incident?

Having both captures, edge and server, gives you the full picture. SmartWall's capture shows the threat. Flowtriq's capture shows the impact. Together, they tell the complete story of every incident.

Alerting and Integration

Corero's alerting flows through SecureWatch, its management and analytics platform. From there, alerts reach your team via SNMP traps, syslog, and email. Integrating with Slack, Discord, PagerDuty, OpsGenie, or Telegram requires custom middleware or API scripting.

Flowtriq provides native integrations with the tools modern NOC teams actually use:

• Slack and Discord: Rich formatted messages with attack type, PPS, source analysis, and a direct link to the PCAP.
• PagerDuty and OpsGenie: Native integration keys for on-call escalation. Incidents auto-resolve when the attack subsides.
• Telegram and Microsoft Teams: Bot integrations for teams on these platforms.
• Webhooks: Structured JSON payloads to any HTTP endpoint for custom automation.
• Email and SMS: Direct configuration in the dashboard, no SMTP server setup.

The practical difference: when an attack is detected, your on-call engineer gets a Slack message or PagerDuty page within 2 seconds. With SmartWall alone, that same alert has to traverse SecureWatch, get converted to syslog or SNMP, pass through your monitoring stack's ingestion pipeline, and eventually trigger a notification. Each hop adds latency and another point of failure in the alerting chain.

The Layered Architecture

The strongest DDoS posture for service providers and hosting companies is not either/or. It is both.

Layer 1: Corero SmartWall at the network edge. Always-on inline filtering. Volumetric attacks, protocol-level attacks, and amplification floods are mitigated at wire speed before they reach your server infrastructure. SmartWall continues to do what it does best.

Layer 2: Flowtriq on each server. Per-node detection with adaptive baselines, attack classification, PCAP forensics, and instant alerting. Catches sub-threshold attacks that pass through SmartWall, provides server-side evidence for incident response, and gives your NOC granular visibility into what each server is actually experiencing.

Two layers, no gaps. Both work with your existing Juniper MX infrastructure. SmartWall peers with your MX routers for inline filtering. Flowtriq's BGP adapter peers with the same routers for server-triggered RTBH or FlowSpec when it detects attacks that SmartWall missed.

For hosting providers specifically, this architecture lets you offer your customers a verifiable, layered DDoS protection service: edge mitigation that stops the floods, plus per-server monitoring that proves it and catches what gets through.

Pricing

Corero SmartWall is enterprise hardware with enterprise pricing. Appliances are sold in throughput tiers with capital expenditure for the hardware, annual software licensing, and ongoing support contracts. Entry-level deployments (10 Gbps tier) typically start in the mid-five figures for hardware alone, with annual support and licensing adding significant recurring cost. Professional services for deployment and integration add further.

Flowtriq costs $9.99/node/month, or $7.99/node/month on annual billing. No hardware. No capital expenditure. No minimum commitment beyond a single node.

Adding Flowtriq to an existing Corero deployment is incremental cost for significant additional visibility:

• 50 servers: $499.50/month ($4,794/year on annual billing)
• 200 servers: $1,998/month ($19,176/year on annual billing)
• 500 servers: $4,995/month ($47,940/year on annual billing)

For a hosting company that has already invested in SmartWall hardware, adding per-server visibility at $9.99/node is a modest line item that fills a real operational gap. You can pass the cost through to customers as a premium monitoring feature, or absorb it as operational tooling that reduces support tickets and improves incident response quality.

Back to Blog

Related Articles