Switching from Wanguard to Flowtriq
in 15 minutes

Back to Blog

Why Operators Switch

Andrisoft Wanguard has been around for years and has real production deployments across ISPs and hosting companies. It handles traffic accounting, anomaly detection, and BGP-based mitigation in a single platform. But operators who start evaluating alternatives tend to run into the same set of friction points:

• Support responsiveness. Wanguard's support model relies on a small team. When you hit an issue during an active attack or a tricky sensor configuration, response times can stretch beyond what your SLA tolerates. Several operators we have spoken with cited support turnaround as their primary reason for looking elsewhere.
• BGP integration requires scripting. Wanguard can trigger BGP blackhole announcements, but the integration path typically involves custom scripts and manual configuration of your BGP daemon. There is no built-in adapter that peers directly with your router. If your team is comfortable writing and maintaining those scripts, this works fine. If not, it becomes a maintenance burden.
• Flow analysis performance at scale. On large networks with high flow volumes, Wanguard's Console can become slow to render reports and historical data. Operators running 50+ sensors have reported the web interface lagging under load, particularly when pulling traffic accounting reports across long time ranges.
• Sensor configuration complexity. Each Wanguard sensor requires careful tuning: thresholds, interfaces, filter profiles, anomaly detection parameters. The configuration surface is large, and getting it right for each node takes time. Misconfigured thresholds lead to either missed attacks or alert fatigue, and there is limited guidance built into the interface for getting those numbers right.

None of these are dealbreakers for every team. Wanguard works well in environments where you have a strong network engineering team that can maintain the scripting and sensor configuration. But if you want less operational overhead and faster time-to-detection, this guide covers the migration path.

Before You Start

Gather these before you begin:

• A Flowtriq account. Sign up at flowtriq.com/signup for a free 14-day trial. No credit card required.
• SSH access to your servers. You will install the Flowtriq agent on each node you want to monitor. Root or sudo access is required for the setup wizard.
• Your BGP router details (if applicable). If you are using Wanguard's BGP blackhole or FlowSpec mitigation, you will need your router IP, ASN, blackhole next-hop, and community strings to configure Flowtriq's BGP adapter.

It is also worth understanding what maps directly and what does not. Flowtriq replaces Wanguard's anomaly detection, alerting, and BGP mitigation triggering. It does not replace Wanguard's traffic accounting and bandwidth reporting features. If you rely on Wanguard's traffic accounting for billing or capacity planning, you will need to keep that capability elsewhere (ntopng, Akvorado, or your router's built-in NetFlow reporting are common alternatives).

Step 1: Install the Agent

Start with 2-3 test nodes rather than your entire fleet. This lets you validate the workflow before rolling out broadly.

# Install the Flowtriq agent
curl -sSL https://flowtriq.com/install.sh | sudo bash

The setup wizard prompts for your API key and Node UUID (both available in the Flowtriq dashboard under Settings → API Keys and Nodes → Add Node). Once setup completes, install and start the systemd service:

# Install the systemd service and start monitoring
sudo ftagent --install-service
sudo systemctl enable --now ftagent

# Confirm it is running
sudo systemctl status ftagent

The agent begins monitoring immediately. Unlike Wanguard's sensor model, there is no threshold configuration required at install time. Flowtriq builds per-server baselines automatically over the first 24-48 hours and adjusts detection sensitivity based on each node's actual traffic patterns.

Once you are satisfied with the install process on your test nodes, repeat on the rest of your fleet. For large deployments, see the mass deployment guide for Ansible and cloud-init patterns.

Step 2: Configure Alert Channels

In the Flowtriq dashboard, go to Alerts and connect the channels your team uses. This replaces Wanguard's notification system (email, SNMP traps, custom scripts) with native integrations:

• Slack / Discord: Paste your webhook URL. Attack alerts arrive as rich formatted messages with attack type, PPS, source analysis, and a direct link to the PCAP capture.
• PagerDuty / OpsGenie: Connect via integration key for on-call escalation. Incidents resolve automatically when the attack subsides.
• Email: Add recipient addresses directly in the dashboard. No shell scripting, no SMTP server configuration.
• Webhooks: POST JSON payloads to any endpoint. Useful if you have custom automation that currently parses Wanguard's notification scripts.
• Telegram / Microsoft Teams: Native bot integrations for teams that use these platforms.

If you had custom notification scripts in Wanguard that trigger specific automation (restarting services, adjusting firewall rules, sending customer notifications), Flowtriq's webhook output provides structured JSON with all the attack metadata your scripts need. The payload format is documented in the webhook reference.

Step 3: Set Up BGP Mitigation

Skip this step if you were running Wanguard in detection-only mode without BGP integration.

If you used Wanguard's BGP blackhole or FlowSpec capability, you will configure a Flowtriq mitigation adapter to replace it. Flowtriq supports three BGP adapter options: ExaBGP, GoBGP, and BIRD 2. Choose whichever your team is most comfortable operating.

Example adapter configuration (ExaBGP):

# Flowtriq BGP adapter configuration
# Settings → Mitigation → BGP Adapter

adapter: exabgp
neighbor: 10.0.0.1          # Your router's BGP peer IP
local-as: 65001              # Your ASN
remote-as: 65000             # Router's ASN
next-hop: 192.0.2.1          # Blackhole next-hop
community: 65000:666         # Blackhole community

After saving the adapter configuration, use the Test Adapter button in the dashboard to verify the BGP session comes up and a test announcement is sent and received by your router. This is the same validation you would do with Wanguard's BGP integration, but the test is built into the interface rather than requiring manual verification on the router CLI.

For FlowSpec rules instead of prefix-based blackholing, see the BGP FlowSpec Rule Builder and the full BGP mitigation documentation for router-specific examples (Juniper, Cisco, Arista, MikroTik).

Step 4: Run Both in Parallel

Keep Wanguard running for 3-7 days alongside Flowtriq. This parallel period serves two purposes: it lets Flowtriq's baselines mature on each node, and it gives you a direct comparison of what each system detects.

During the parallel period, watch for:

• Detection overlap. Both systems should catch the same large attacks. If Wanguard detects something that Flowtriq misses (or vice versa), investigate. The most common explanation is threshold differences: Wanguard uses manually configured thresholds per sensor, while Flowtriq uses adaptive baselines that tighten as the system learns each node's traffic patterns.
• Short-duration attacks. Flowtriq may detect attacks that Wanguard misses, particularly short bursts under 30 seconds. This happens because Flowtriq evaluates traffic per-second on each node, while Wanguard's flow-based detection operates on aggregation intervals that can span several seconds. A 10-second spike that is significant for one server may not register in Wanguard's aggregate flow window.
• Sub-threshold attacks. A 40,000 PPS spike to one server may look unremarkable in Wanguard's network-level view but exceed that specific server's normal baseline by an order of magnitude. Flowtriq catches these because it knows what "normal" looks like for each individual node.
• Alert delivery. Confirm your Slack, Discord, PagerDuty, or email channels are receiving Flowtriq alerts with the right formatting and the right level of detail.

If you do not experience any real attacks during the parallel period, you can use the Flowtriq Attack Simulator to trigger a controlled detection event and verify your alert routing end-to-end.

Step 5: Cut Over

Once you are confident that Flowtriq is detecting correctly and your alerts and BGP integration are validated, start the cutover. Do this incrementally, not all at once:

1. Disable Wanguard sensors one node at a time. Start with your least critical infrastructure. Verify Flowtriq continues detecting on those nodes without Wanguard's parallel coverage.
2. Remove Wanguard's BGP peer from your router. If you configured Flowtriq's BGP adapter in Step 3 and verified it during the parallel period, swap the active peer. Remove Wanguard's BGP session from your router configuration and confirm Flowtriq's adapter is now the sole source of RTBH/FlowSpec announcements.
3. Verify end-to-end. Trigger a test detection (simulator or controlled traffic) and confirm the full chain works: agent detects, dashboard updates, alert fires, BGP announcement reaches your router.
4. Decommission Wanguard. Stop the Wanguard Console and Sensor services. If Wanguard was running on dedicated hardware, that infrastructure is now free to repurpose.

# Stop Wanguard services (adjust for your installation)
systemctl stop wanguard-console
systemctl stop wanguard-sensor
systemctl disable wanguard-console
systemctl disable wanguard-sensor

What You Gain, What You Lose

Switching platforms always involves tradeoffs. Here is an honest accounting of what changes.

What you gain with Flowtriq

• Per-server baselines. Each node has its own adaptive traffic baseline. No manual threshold tuning per sensor.
• 1-2 second detection. Per-second evaluation on each node, compared to Wanguard's flow aggregation intervals.
• PCAP capture. Every incident includes a server-side PCAP showing exactly what traffic reached the application. Wanguard does not capture packets at the node level.
• Auto-mitigation escalation. Flowtriq can escalate from local firewall rules to BGP blackhole to FlowSpec automatically based on attack severity, without manual intervention or custom scripting.
• Modern dashboard and alerting. Native Slack, Discord, PagerDuty, OpsGenie, Telegram, Teams, webhooks. No SNMP trap configuration or custom notification scripts.
• No dedicated monitoring hardware. The agent runs on the servers you are already operating. No separate Console or Sensor appliances to maintain.

What you lose

• Traffic accounting and bandwidth reporting. Wanguard's traffic accounting module provides per-interface, per-customer bandwidth graphs and historical usage data. Flowtriq does not do traffic accounting. If you use this for billing, capacity planning, or customer reporting, you will need a separate tool (ntopng, Akvorado, LibreNMS, or your router's native NetFlow/sFlow reporting).
• Wanguard's NetFlow/sFlow collector. Wanguard can act as a centralized flow collector, aggregating flows from routers and switches across your network. Flowtriq's architecture is agent-based (one agent per server), not collector-based. If you need a dedicated flow collector for network-wide traffic analysis, that remains a separate concern.
• Sensor-level granularity for network devices. Wanguard can monitor router and switch interfaces via SNMP. Flowtriq monitors servers, not network devices. If you need anomaly detection on your router uplinks specifically, you will need to keep that capability through your NMS or a separate tool.

For most teams, the traffic accounting gap is the only one that matters in practice. And if you are already running a separate NMS for bandwidth monitoring (most operators are), then Wanguard's accounting module was likely redundant anyway.

Back to Blog

Related Articles