Necessary cookies
Deployment and purchasing guide
Defense Fabric vs Andrisoft Wanguard
Wanguard is a detection and filtering platform, not just a flow collector. Compare the complete Console, Sensor and Filter design with the Defense Fabric nodes and port pool needed for the same network.
Where each approach fits
Defense Fabric combines local packet filtering, policies and fleet port allocation with its customer portal. The server and clean-return design remain the operator’s responsibility.
Wanguard separates Sensors, Filters and the Console. That separation can suit networks that need several exporter inputs, distributed analysis or a mix of local filtering and router enforcement.
Technical and commercial comparison
Deployment and traffic path
| What to compare | Peeryx Defense Fabric | Andrisoft Wanguard |
|---|---|---|
| Product scope | Local detection, packet filtering and policy control on your servers. [1] |
Console, Sensor and Filter components for visibility, detection and mitigation. [4] |
| Appliance or software | Licensed Linux software; server and network supplied by the operator. [1] |
Linux software; vendor also offers preconfigured appliances. [4] |
| Hardware ownership | Compatible standard servers and qualified NICs; TPM 2.0 required. [1] |
Operator servers with compatible packet-capture and filtering hardware. [4] |
| On-premises installation | Distributed installer: Debian 12, x86-64, VPP 25.10-release. [1] |
Distributed Linux components on one or more servers. [4] |
| Inline filtering | Inline forwarding is supported; physical bypass must be designed separately. [1] |
Packet Filter can run inline; DPDK, Netfilter and NIC enforcement depend on configuration. [5] |
| Traffic diversion | BGP diversion to a validated filtering next hop with a separate clean return. [1] |
Side filtering diverts attacked destinations by BGP to a scrubbing server. [5] |
Detection and protection
| What to compare | Peeryx Defense Fabric | Andrisoft Wanguard |
|---|---|---|
| NetFlow / sFlow / IPFIX | sFlow, NetFlow and IPFIX collection; validate sampling and export delay. [1] |
Flow Sensor supports NetFlow, sFlow and IPFIX. [4] |
| Packet inspection | Local VPP-based packet filtering; sampled evidence is not a full attack capture. [1] |
Packet Sensor/Filter inspect packets; Flow Filter uses flow data with less packet detail. [5] |
| L3/L4 filtering | Protocol thresholds, TCP validation, source quotas and post-filter firewall policies. [1] |
Local stateless filtering and router FlowSpec; enforcement method is configurable. [5] |
| Application-layer scope | Protocol-specific modules require qualification; no blanket WAF or arbitrary L7 coverage claim. [1] |
Packet/payload patterns are supported; docs identify limits for low-volume application attacks. [5] |
| Generated attack signatures | Adaptive signatures can be observed or applied; validate collateral effects. [1] |
Filter derives attack patterns and generates rules; packet and flow modes differ. [5] |
| BGP FlowSpec | Dry-run and active export; compatible router/BGP family required; panel limit 50 rules. [1] |
Router FlowSpec and third-party enforcement are documented. [5] |
| BGP steering | Agent-managed sessions and diversion; verify FIB installation and withdrawal. [1] |
BGP Connector supports route actions and diversion. [5] |
| RTBH blackholing | Available as last-resort destination blackholing; legitimate traffic is also discarded. [1] |
Sensor can announce blackhole communities; destination connectivity is sacrificed. [5] |
| Gaming-specific protection | Optional Game module; qualify each protocol and architecture before ordering. [3] |
Qualify game protocols and legitimate client behaviour; no game-specific guarantee inferred. [5] |
Operations and resilience
| What to compare | Peeryx Defense Fabric | Andrisoft Wanguard |
|---|---|---|
| Reports and evidence | Panel history and available PCAP, ZIP and PDF evidence; sampling and retention apply. [1] |
Console reports, flow analysis and packet evidence; available detail depends on input. [4] |
| API and automation interface | Published authenticated OpenAPI; revisioned policy writes remain pending until node application. [2] |
REST API, CLI and response scripts. [4] |
| High availability | Network failover must be engineered; second server is not automatic state replication. [1] |
Filter clustering and side-filter route withdrawal are documented; test failure behaviour. [6] [5] |
| Multiple servers or sites | Shared port pool across up to 128 managed servers; qualified second-link ECMP. [1] |
Distributed Sensors/Filters and clusters; licence active components, not just physical servers. [4] |
| Automatic operation | Monitor, automatic and permanent policy modes; hold and exit thresholds control recovery. [1] |
Responses can activate filtering and remove rules when the anomaly ends. [4] |
Licensing, costs and validation
| What to compare | Peeryx Defense Fabric | Andrisoft Wanguard |
|---|---|---|
| Licensing unit | Base licence with one 10G port; extra port speeds/counts share a fleet pool. [3] |
Annual Sensor and Filter licences; DPDK Engine is an additional per-component licence. [7] [8] [9] |
| Evaluation terms | 14-day trial; adding servers does not restart it. Physical and activation limits still apply. [1] |
30-day evaluation requested from Andrisoft; activation review applies. [10] |
| Public price basis | €350.00 per month excluding tax; server, network and optional modules are separate. [3] |
Published annual USD prices: Sensor $595, Filter $995, DPDK Engine $1,410 each. Scope determines count. [7] [8] [9] |
| Support scope | Peeryx technical support; confirm deployment responsibilities and contractual response commitments. [3] |
Support/updates and optional support tiers; verify the required coverage and response target. [4] |
| Deployment constraints | TPM, compatible NICs, management HTTPS, tested routing; SYN proxy requires symmetry. [1] |
Flow exporter and packet-interface counts affect components; clean return and upstream capacity still matter. [7] [8] [5] |
| Performance evidence | No published reproducible benchmark for the reference servers; measure your workload. [1] |
Vendor throughput statements are configuration-specific; no common comparative test was run. [4] |
| Upstream saturation | Local filtering cannot clear an already saturated upstream link; transit is a separate service. [1] |
Local Filter cannot solve upstream saturation; RTBH or contracted upstream scrubbing can act earlier. [5] |
Prices use the published currency and billing period. Monitored bandwidth, licensed ports and filtering capacity are different quantities; these figures are not equivalent quotes. Hardware, taxes and optional services may add to the total.
What to verify before a decision
- Count Flow Sensors by exporter and determine the Packet/Flow Filter components. One physical server is not necessarily one licence.
- If using DPDK, include its additional per-component licence. A Filter licence does not include a Sensor licence.
- Flow-derived rules and packet-derived signatures do not expose the same detail. Test sampling delay, payload needs and normal application traffic.
Ask every supplier to demonstrate the same workload
- Record exact versions, hardware, packet sizes, rules and legitimate traffic. Compare the whole path, not port labels.
- Test new and established connections during mitigation. Measure packet loss and application latency as well as attack throughput.
- Test exporter loss, BGP loss, node failure, withdrawal and recovery separately. Record what happens to customer traffic.
- Price the full deployment: required instances, ports, modules, support, hardware, rack space, power and network services.
How this comparison is prepared
Prepared by Peeryx from the public vendor documentation linked below and the distributed Defense Fabric release. It describes product scope, not a jointly run performance test. Unconfirmed items are questions for the proposed configuration, not claims that a feature is absent.
Sources reviewed:
Sources and scope
Validate Defense Fabric against your network
Bring your server models, interface speeds, topology and normal traffic profile. Use the trial to establish the behaviour and capacity of the configuration you would actually deploy.