Building a Radware DefensePro Cluster for Active-Active HA

Operators running services across Australian infrastructure face real exposure to volumetric and low-and-slow denial-of-service campaigns, particularly during peak windows between Sydney and Perth. A pair of Radware DefensePro appliances in active-active mode provides inline mitigation for SYN floods, HTTP GET floods, and behavioural anomalies while keeping both units productive instead of leaving one as passive standby. This walkthrough covers the practical steps to provision, synchronise, and verify a two-member cluster suited to on-premises and hybrid deployments.

Before touching the management interface, map the traffic flow, decide on a routing mode, and confirm licensing for both signatures and the behavioural DoS module. Australian operators often place appliances in separate data halls within the same Sydney or Melbourne facility, or split them across campuses in different cities, and the cluster configuration needs to reflect that. Coordination with upstream carriers such as Telstra, Optus, or Vocus is frequently required to align BGP advertisements with the cluster topology.

Planning the Deployment and Licensing

Treat the two appliances as peers from day one, not as a primary and spare. Each DefensePro requires its own license file, its own behavioural DoS signature feed, and unique addresses on the management and synchronization VLANs. Order the active-active SKU explicitly; the standard cold-standalone variant will not accept traffic symmetrically across the pair.

Run the synchronization link on a private path that does not carry customer traffic. Many Brisbane and Canberra colocations use a crossover cable on a dedicated /30 subnet purely for state exchange. The BDP engine needs reliable communication over this path to maintain its adaptive baseline, so a jittery link will degrade detection accuracy well before any real attack occurs.

Network Topology and Routing Decisions

Inline mode is the simplest option and offers the lowest latency, which matters for services hosted in AWS ap-southeast-2 or ap-southeast-4 regions. One-arm scrubbing is simpler to retrofit but needs policy-based redirection on the upstream router or switch. Pick the mode that matches the existing routing fabric rather than rebuilding the network around the cluster.

For active-active, both units must announce the same protected prefixes. BGP anycast with matching AS path and MED values is widely used. Static equal-cost routes with health checks work in simpler networks, and a floating IP can be added for easier failover semantics. Document the protected subnets, synchronization subnet, management subnet, and which interfaces belong to which VLAN. Engineers across AEST and AWST have found a single shared diagram in their internal wiki saves at least one late-night escalation during an incident.

Cluster Synchronization and Initial Configuration

Configure the cluster from the primary node first. Under High Availability, set the mode to Active-Active, define the peer IP over the sync link, and enable stateful synchronization for sessions, signatures, and the BDP baseline. Restarting the synchronization service after the initial setup is normal; logs will show heartbeat messages every few seconds once the pair converges.

A working BDP baseline needs seven to fourteen days of clean traffic before it accurately distinguishes legitimate bursts from attack behaviour, so deploy ahead of planned marketing campaigns or seasonal spikes. For organisations subject to APRA CPS 234, document the cluster as a critical security control and register both appliances in the asset register. Operators of critical infrastructure assets under the Security of Critical Infrastructure Act should retain evidence of layered mitigation for audit purposes.

Health Monitoring and Failover Behaviour

Monitor both units through SNMP, syslog, and the built-in DefensePro dashboard. A healthy active-active pair shows roughly equal traffic distribution, matching CPU utilisation, and identical signature versions across both nodes. If one unit starts dropping packets, check the synchronization link first, then the BGP session to the provider, then the BDP baseline drift after a recent policy change.

Active-active does not guarantee instant failover in every scenario. A unit that crashes hard will see its peer take over within seconds, but a unit that passes degraded traffic may continue announcing the prefix until it is withdrawn. Configure aggressive BGP timers or BFD for sub-second failure detection, particularly when traffic is scrubbed and forwarded to origins across long-haul links such as Sydney to Perth, where every extra second of black-holing is costly.

Testing, Maintenance, and Operational Drills

Run quarterly failover drills that simulate the loss of one appliance, the loss of the synchronization link, and a live attack against one member only. Record how long the surviving unit takes to absorb the load and verify that no customer sessions are dropped unexpectedly. Many Australian operations teams schedule these drills in the Saturday morning maintenance window to minimise impact on end users.

Keep firmware versions aligned across the pair, and review release notes before applying upgrades during business hours. Roll upgrades work in this topology, but validate changes on a lab rig first if one is available. Home lab engineers can replicate the cluster on supported hypervisors using virtual DefensePro instances, which is handy for replaying local attack patterns observed in Australian threat feeds.

Practical Recommendations for a Stable Cluster

• Provision the synchronization link on dedicated hardware, not on a shared customer VLAN.
• License both appliances identically, including BDP and subscription feeds, before pairing them.
• Allow at least two weeks of clean traffic for the BDP baseline before high-traffic events.
• Enable BFD or aggressive BGP timers for sub-second failover on anycast prefixes.
• Run quarterly drills and document recovery times against internal RTO targets.