Why We Built Flowtriq:
FastNetMon, Wanguard, and the Next Generation of DDoS Detection

Back to Blog

The Problem We Kept Running Into

Before building Flowtriq, I spent years doing offensive security — red team operations, penetration testing, and attack research including work that ultimately led to the Mirai botnet killswitch. The thing about spending years thinking like an attacker is that you develop strong opinions about detection.

The two tools most operators relied on — FastNetMon and Wanguard — are both built on the same foundation: ingest NetFlow or sFlow from your routers, watch for threshold violations, trigger a BGP blackhole when something spikes. Both are real products with real deployments. But when I started talking to the operators using them, the same complaints kept coming up: they were missing attacks, finding out after the damage was done, and their only response option was taking the target offline entirely.

This isn't a failure of engineering on the part of FastNetMon or Andrisoft. It's a structural consequence of building detection on top of sampled flow data. That structure has genuine advantages — it scales to 100 Gbps backbone links without breaking a sweat. But it also has hard limits that matter enormously if you are trying to protect individual servers rather than aggregate network traffic. That gap is what Flowtriq is built to fill.

This post is an honest comparison of all three tools: what each one does, where each one excels, and which problems each one cannot solve. If you are evaluating DDoS detection tools for the first time or reconsidering your current setup, this is the comparison we wish existed when we were building Flowtriq.

The Flow-Based Approach: FastNetMon and Wanguard

FastNetMon and Wanguard are architecturally similar at the core. Both sit outside your servers, receive flow telemetry exported by your network equipment (routers, switches, or NetFlow probes), analyze that telemetry for volumetric anomalies, and trigger BGP-based responses. Understanding both tools means understanding the flow-based approach and its tradeoffs.

FastNetMon

FastNetMon is an open-source DDoS detection system that has been widely deployed by hosting providers and ISPs since its release in 2014. It supports NetFlow v5/v9, sFlow, IPFIX, and direct packet capture via AF_PACKET mirroring. It ships in two editions:

• FastNetMon Community — Free, open source (Apache 2.0). Basic threshold detection, BGP blackhole via ExaBGP, syslog and script notification. No web dashboard, no email alerts natively, no attack classification. Configuration is command-line only. A genuine starting point for organizations with flow infrastructure and budget at zero.
• FastNetMon Advanced — Commercial (quote-based pricing, estimated $500-2,000+/month for small deployments). Adds a web UI, REST API, email and Slack notifications, per-host bandwidth graphs, Flowspec support, and more granular threshold configuration. A meaningful upgrade over Community for teams that need operational visibility.

FastNetMon's BGP integration is its strongest feature. When a threshold violation is detected, it can announce a blackhole route through ExaBGP, GoBGP, or BIRD to your upstream router in seconds. For service providers who need to drop volumetric attacks before they saturate transit links, this is exactly what is needed.

Wanguard (by Andrisoft)

Wanguard is a commercial DDoS protection platform developed by Andrisoft, a Romanian software company, and has been deployed in production ISP and hosting environments since approximately 2008. It is a more mature, full-featured product than FastNetMon Community and is priced accordingly. It is deployed as an on-premises software stack, typically on dedicated hardware.

Wanguard consists of two core components:

• Wanguard Sensor — The detection engine. Ingests NetFlow v5/v9/IPFIX, sFlow, or raw packet captures via PF_RING or DPDK. Applies configurable anomaly detection policies (threshold-based and behavioral) to detect volumetric attacks. Produces structured alerts with protocol breakdown and top talker data.
• Wanguard Filter — The mitigation engine. When the Sensor detects an attack, Filter can trigger BGP RTBH or FlowSpec announcements, inject iptables/nftables rules, or redirect traffic to a scrubbing interface. More mitigation options than FastNetMon out of the box.

Wanguard has a significantly more polished web dashboard than FastNetMon Community, with historical traffic graphs, per-IP flow analytics, attack archives, and report generation. For ISPs and hosting providers that need to show customers detailed attack reports, Wanguard's reporting is a practical advantage. Andrisoft also offers responsive commercial support, which matters for production deployments at scale.

Pricing for Wanguard is license-based with annual renewals. The Sensor + Filter bundle for a single detection point typically starts around $1,500–3,000+/year for small deployments, scaling up with bandwidth capacity and the number of sensors. Dedicated hardware is a prerequisite — not the software license itself, but the deployment model. You need a server with enough CPU and memory to handle your flow volume, and the hardware cost is real.

The Shared Structural Limit: Sampling

Here is the thing both FastNetMon and Wanguard share that no amount of feature development can change: they are both built on sampled flow data, and sampled flow data has a floor.

NetFlow and sFlow do not capture every packet. They sample at configurable ratios — commonly 1:512, 1:1000, or 1:4096 on high-throughput interfaces. At a 1:1000 sampling ratio, FastNetMon and Wanguard see one representative packet for every thousand that actually traverse the interface. For aggregate backbone monitoring at 10 Gbps+, this is not a problem: the statistical sample is large enough for accurate anomaly detection on volumetric attacks.

For individual server protection, the math changes. A 40,000 PPS attack on a single server generates 40 sampled flow records per second at 1:1000 sampling. Over a 15-second attack, that is 600 flow records total — statistically marginal. Over a 5-second attack, detection may not happen at all before the attack ends. And because flow data is exported in batches (most routers export every 10-60 seconds), there is also a mandatory buffering delay between when packets traverse the interface and when the detection system sees them.

To be clear: sampling is a deliberate, correct engineering decision for backbone-scale monitoring. It is the only way to make flow export practical at 100 Gbps without overloading router CPUs. The issue is not that FastNetMon or Wanguard made a bad choice. The issue is that the same approach that works beautifully at the backbone level has hard limits when applied to per-server protection — and those limits matter for the operators we built Flowtriq for.

In practice, operators running FastNetMon or Wanguard in front of game servers, hosting infrastructure, or any service where attacks under 60 seconds are common will experience a meaningful gap: attacks that the tool detects too late to prevent meaningful damage, or attacks that end before detection fires at all. The tool is not broken — it is operating as designed. The design just has a scope condition that many operators do not realize until they see it fail.

How Flowtriq Approaches This Differently

Flowtriq starts from a different premise. Instead of sitting at the network edge and analyzing sampled flow exports from routers, Flowtriq installs directly on each server as a lightweight agent and monitors traffic at the host interface — unsampled, per-second, on every packet.

The agent reads raw packet headers off the network interface using Linux kernel mechanisms (AF_PACKET with BPF filtering for efficiency), builds per-second traffic counters across multiple dimensions (PPS, BPS, source IP diversity, protocol breakdown, port distribution, TCP flag ratios), and compares each second's profile against a rolling dynamic baseline. When an anomaly exceeds the detection threshold, an alert fires immediately.

This architecture eliminates the sampling problem by design. There is no sampling. There is no flow export delay. There is no statistical inference about what traffic looked like — the agent saw the actual traffic, counted every packet, and has exact source data. Detection fires at one second. For a 10-second attack, Flowtriq detects it at second 1; FastNetMon or Wanguard are likely still buffering flow records when it ends.

The tradeoff is inverse to the flow-based tools: Flowtriq sees everything happening on each individual server at high fidelity, but it does not provide the aggregate backbone-wide visibility that FastNetMon and Wanguard offer to ISPs monitoring aggregate router traffic. For organizations that need both, running Flowtriq on servers alongside FastNetMon or Wanguard at the network layer is a common production configuration.

Feature Comparison at a Glance

Attack Classification: Why Knowing the Type Matters

Neither FastNetMon (Community or Advanced) nor Wanguard classifies attacks by type in the way that determines mitigation strategy. Both products can tell you that traffic to a destination IP spiked to 800,000 PPS. They can break down the spike by protocol (UDP, TCP, ICMP) from flow data. But neither tells you whether that UDP spike is an NTP amplification attack, a DNS amplification attack, a generic UDP flood, or legitimate traffic from a misconfigured service — and the mitigation strategy for each is completely different.

NTP amplification comes from a small set of open NTP reflectors with a characteristic 468-byte response size and source port 123. The right mitigation is rate-limiting inbound UDP from port 123 with a packet-size filter. DNS amplification has a different size profile and comes from port 53. A generic UDP flood has high source diversity and no specific port pattern. If you apply the wrong mitigation rule, you either block legitimate traffic or allow attack traffic through.

Wanguard provides better protocol-level breakdown than FastNetMon, which is an operational advantage. Its reporting can show you that the traffic is UDP dominated, show top source IPs from sampled data, and provide some context for manual investigation. But it does not automate the classification-to-mitigation mapping, and it does not provide the confidence scoring that lets you programmatically decide when to act.

Flowtriq classifies every detected incident across nine families — UDP flood, SYN flood, NTP amplification, DNS amplification, ICMP flood, HTTP flood, TCP ACK flood, SSDP amplification, and multi-vector — with a confidence score for each. That classification drives automated mitigation: different firewall rule sets fire for different attack families. A DNS amplification attack automatically triggers rate-limiting on inbound UDP port 53, not a blackhole of the entire server. The server stays up. Legitimate traffic continues. The attack traffic is filtered.

Mitigation: The Blackhole Problem

FastNetMon's core mitigation is BGP RTBH: when an attack is detected, announce a blackhole community to your upstream router, which drops all traffic destined for the attacked IP at the upstream edge. This stops the attack. It also stops your service. For the duration of the blackhole, the server is unreachable. For game servers, commerce platforms, or any service where availability matters, this is a last resort — not a first response.

FastNetMon Advanced adds Flowspec support for operators with Flowspec-capable upstream providers, enabling more granular filtering (by protocol, source prefix, or port range) rather than a full blackhole. This is a meaningful improvement for operators who have it, but Flowspec adoption is uneven across transit providers. Many smaller hosting networks and ISPs still do not support it, which means blackhole remains the only BGP-based option.

Wanguard's Filter component has a broader mitigation toolkit than FastNetMon: BGP RTBH, Flowspec, local iptables/nftables rule injection, and traffic redirection to scrubbing interfaces. For on-premises deployments at ISP scale, this is a capable mitigation stack. It is still constrained by the fundamental issue that detection fires 10-60+ seconds after the attack starts, which means any targeted mitigation is applied after significant impact has already occurred.

Flowtriq's approach is different. Because detection fires at second 1 and the system knows what type of attack it is, it can apply targeted mitigation automatically before most users notice anything is wrong. The firewall rule system supports 22 action types that can be combined and conditioned on attack family, confidence score, severity, source geography, or any other incident attribute. Rate-limit inbound UDP from port 53 during a DNS amplification attack. Block SYN packets from source IPs with no prior session history during a SYN flood. Apply a source-rate limit during a generic UDP flood while preserving established TCP connections. The server stays online. Legitimate traffic is preserved.

The Same Attack, Three Different Outcomes

To make the differences concrete: a 35-second NTP amplification attack at 420,000 PPS targeting a game server running on a dedicated server without managed flow-exporting switching infrastructure. The attack uses approximately 2,100 open NTP reflectors, average amplified response size 470 bytes, source port 123 UDP.

PCAP Forensics: What You Actually Have After an Attack

Neither FastNetMon nor Wanguard captures PCAP. After an attack, what you have from both tools is flow-level data: aggregate metrics from sampled telemetry, approximate source IP lists, protocol distribution. This is useful for understanding roughly what happened. It is not useful for upstream abuse reports, forensic attribution, or understanding novel attack patterns that do not fit existing signatures.

If you need packet-level evidence — and increasingly, upstream transit providers and data centers require it before acting on mitigation requests — you need to run a separate packet capture tool alongside FastNetMon or Wanguard, start it at the right time, and hope the attack lasts long enough to capture meaningful data. In practice, this means most attacks go unforensicated.

Flowtriq maintains a rolling PCAP buffer on every monitored server. When an attack is detected, the buffer is flushed to disk with a configurable pre-attack window (default: 30 seconds before the anomaly triggers). Every incident automatically has packet-level evidence attached to it. PCAP files are downloadable from the incident page. You have exact packet data, not sampled estimates.

This matters operationally in three ways: upstream mitigation requests succeed more often when you can provide PCAP evidence; post-incident analysis is more accurate when you have actual packets rather than statistical summaries; and novel attack patterns that do not match existing signatures can be identified and characterized from the PCAP rather than guessed at from flow data.

True Cost of Ownership

FastNetMon Community is free. The real cost is operational: threshold tuning, alert management via scripts, manual investigation without a dashboard, and the engineering time to maintain and respond to a system that gives you incomplete incident data.

FastNetMon Advanced pricing is not published. Based on community reports and public references, small deployments typically run $500–2,000+/month. Larger deployments scale higher. There is a separate infrastructure cost if you do not already have flow-exporting network equipment: managed switches with NetFlow export support range from a few hundred to several thousand dollars, and you need a BGP session with your upstream for the blackhole functionality. For organizations that do not already have this infrastructure, the total deployment cost is meaningfully higher than the license fee alone.

Wanguard pricing is annual license-based. The Sensor + Filter bundle starts at approximately $1,500–3,000+/year for small deployments (single sensor, limited bandwidth capacity), and scales up with bandwidth capacity tiers. Dedicated hardware adds hardware procurement and ongoing operating cost. Andrisoft's model is on-premises: you own and operate the infrastructure. For large ISPs with existing hardware and operations teams, this is often the right economic model. For smaller operators without existing infrastructure, the upfront cost and operational burden can be substantial.

Flowtriq is $9.99 per node per month, or $7.99 per node per month on annual billing. All features on every plan: full classification, PCAP, all alert channels, firewall rules, cloud dashboard. No infrastructure prerequisites beyond a Linux server. A 10-node deployment is $99.90/month. A 100-node deployment is $999/month. Seven-day free trial, no credit card required.

When to Choose Each

Choose FastNetMon Community when you are an ISP or hosting provider with existing flow-exporting router infrastructure and BGP capability, your budget is zero, you have experienced network engineers comfortable with command-line configuration, and your primary need is detecting large volumetric attacks at the network edge and triggering automated blackhole. Understand the tradeoffs before deploying for server-level protection.

Choose FastNetMon Advanced when you need the Community feature set plus a web dashboard, email and Slack alerting, and REST API access, and your infrastructure already exports flow data. The upgrade over Community is real. The structural sampling limitations and lack of classification and PCAP remain.

Choose Wanguard when you are an ISP or hosting provider with existing on-premises infrastructure, dedicated hardware budget, and operations staff to maintain it. Wanguard's reporting, multi-sensor architecture, and FlowSpec + iptables mitigation toolkit are well-suited for large-scale carrier and hosting environments where the on-premises model is appropriate. Andrisoft's commercial support is a genuine advantage for production deployments at that scale.

Choose Flowtriq when you need per-server protection at one-second detection granularity, automatic attack classification with confidence scoring, PCAP forensics for every incident, targeted mitigation that keeps services online during attacks, and a self-serve deployment model that does not require flow infrastructure or dedicated hardware. This is the right tool for game server operators, hosting providers protecting individual customer servers, VPS fleets, cloud instances, and any environment where the flow-based model has blind spots you cannot afford.

Running Flowtriq Alongside FastNetMon or Wanguard

These tools are not mutually exclusive. The most complete detection setup for service providers combines network-level visibility with server-level depth.

FastNetMon or Wanguard monitor aggregate traffic across your backbone routers and BGP infrastructure, providing the wide-area visibility that flow telemetry excels at. They catch the 1 Tbps attacks that would saturate transit links and need to be dropped at the upstream edge before they reach your network. Flowtriq runs on individual servers and catches the attacks that flow sampling misses — 5-second pulses, sub-threshold events, attacks against specific ports, and anything that needs classification and PCAP evidence to respond to correctly.

In this layered model, FastNetMon or Wanguard handle the coarse-grained network-wide protection, and Flowtriq handles fine-grained per-server detection and forensics. Each tool does what it does best. BGP integration between Flowtriq and your existing ExaBGP/GoBGP infrastructure means both systems can feed the same RTBH and FlowSpec pipeline when escalation is needed.

Frequently Asked Questions

Back to Blog

Related Articles