Configuring Radware LinkProof for Active-Active WAN Load Balancing

Active-active WAN load balancing uses two or more Internet circuits at the same time instead of reserving one connection as a standby. Radware LinkProof makes that model practical by classifying traffic, monitoring link health, applying persistence where needed, and selecting the appropriate gateway for each flow.

The goal is not simply to divide packets evenly between providers. A reliable design accounts for bandwidth, latency, source addresses, session behavior, NAT, asymmetric routing, and the way each application responds when a circuit becomes unavailable.

LinkProof is especially useful at the edge of hybrid environments. Internet-facing services, SaaS traffic, remote access, cloud connectivity, and backup transfers can follow different policies while administrators retain centralized visibility into link utilization and failover decisions.

Define The WAN Design

Begin by documenting every uplink, including provider bandwidth, handoff type, public address space, gateway information, and any contractual traffic limits. A 1 Gbps fiber circuit and a 200 Mbps broadband circuit should not receive equal traffic merely because both are operational.

Decide whether the primary objective is utilization, resilience, application performance, or a combination of these. Weighted distribution is generally preferable when circuits have different capacities. A performance-based policy can favor the link with lower delay or packet loss for latency-sensitive applications, while bulk transfers can use available capacity on either provider.

The LinkProof device should have a clear logical and physical path to each WAN gateway. Confirm VLAN tagging, interface speed and duplex, default gateway reachability, management access, and upstream routing before adding load-balancing rules. A clean baseline makes later troubleshooting considerably easier.

Build The Traffic Steering Policy

LinkProof policies typically classify traffic by source network, destination, service, protocol, application category, or URL-related criteria where supported by the deployment. Start with broad rules, then add exceptions for systems that require predictable egress addresses.

For example, general user browsing can use weighted distribution across both providers, while payment systems, partner portals, and allow-listed APIs can be pinned to a specific public IP. Site-to-site VPNs often require a stable source address and should be excluded from unrestricted balancing unless both peers support multi-link operation.

Inbound and outbound traffic require separate consideration. Outbound flows can be steered directly by the LinkProof policy engine, but inbound services depend on DNS, public advertisements, NAT, and return-path symmetry. Publishing the same service through multiple providers may require DNS health checks, low TTL values, certificate consistency, and careful session persistence.

Configure Health Monitoring

A WAN link can remain electrically up while the provider path beyond the gateway is unusable. Monitoring only the local interface or next-hop router therefore creates false availability. Configure probes that test meaningful destinations through each provider, such as provider resolvers, trusted public addresses, or application endpoints.

Use multiple probe targets when possible. A single failed destination should not remove a healthy circuit from service, while repeated failures across independent destinations should trigger a state change. Set practical probe intervals, failure thresholds, recovery thresholds, and hold-down timers so short-lived packet loss does not cause route flapping.

Health checks should reflect application requirements. ICMP may be blocked or deprioritized, whereas TCP or HTTP checks can verify that a service is reachable at the transport or application layer. Record which probe uses which source interface and gateway; an incorrectly sourced test can report success through the wrong link.

Apply Persistence And NAT Carefully

Persistence is essential for applications that associate a session with a source address. Without it, successive connections from one client may leave through different providers and appear to originate from different public IPs. Common persistence choices include source address, destination address, service, or a combination of these attributes.

Source NAT should be designed alongside traffic selection. Each provider generally supplies a distinct public address or translated range, and return traffic must arrive through the same provider path selected for the session. Verify that firewall rules, web application allow lists, remote administration controls, and logging systems recognize both address ranges.

Requirement	Suitable Approach	Main Risk
General web browsing	Weighted active-active distribution	Uneven experience if link quality differs
Partner or payment portal	Source persistence or fixed egress policy	Loss of access when the selected circuit fails
Large backups	Capacity-based policy with rate controls	One circuit can become saturated
Site-to-site VPN	Pinned provider path or coordinated dual tunnels	Tunnel instability from changing source IPs
Public web service	Multi-provider DNS and synchronized NAT	DNS caching and session persistence issues

For stateful firewalls positioned behind LinkProof, confirm that the firewall cluster sees a consistent flow path. If multiple firewalls are involved, synchronize connection state or ensure that the same traffic reaches the same inspection node. A WAN policy that is correct in isolation can still fail when downstream stateful devices receive asymmetric traffic.

Implement The Configuration Workflow

Create the WAN interfaces and assign each one to the correct provider or link group. Add gateway definitions, routing information, and probe objects before enabling production policies. Use descriptive names that identify the carrier, circuit role, and location rather than relying on interface numbers alone.

Next, define link groups and distribution methods. A weighted rule might allocate 80 percent of eligible traffic to a high-capacity circuit and 20 percent to a smaller link. Other rules can use least-loaded, response-time, or priority behavior, depending on the LinkProof software release and licensed features.

Add policy exceptions from most specific to least specific. VPNs, monitoring systems, backup hosts, and fixed-egress applications should be evaluated before the general Internet rule. Attach persistence and NAT behavior explicitly instead of assuming the global defaults are appropriate. Firmware terminology varies, so validate each setting against the installed Radware release documentation.

Before committing changes, inspect the resulting policy order and simulate representative source and destination combinations. Confirm that a user subnet, a server subnet, a VPN peer, and a public service each receive the intended link selection.

Test Failover And Recovery

Testing should include both administrative shutdown and real path failure. Disable an interface, disconnect an upstream handoff where safe, and block probe destinations in a controlled maintenance window. Observe whether new sessions move to the remaining provider and whether existing sessions behave according to the selected persistence policy.

A failover test is incomplete if it checks only connectivity. Review NAT addresses, firewall logs, DNS responses, application authentication, VPN state, and monitoring alerts. Some applications reconnect automatically, while others require users to restart sessions because the source address changed.

Cloud and virtualization workflows can add another dependency. If workloads are being moved between on-premises infrastructure and AWS, review how public egress, security groups, route tables, and application allow lists interact with the WAN policy; an AWS MGN walkthrough provides useful background for understanding the migration side of that hybrid path.

Monitor Performance And Maintain The Policy

Track per-link bandwidth, packet loss, latency, probe state, connection counts, NAT utilization, and policy hits. A balanced traffic graph does not necessarily indicate a healthy design; a slower link may be carrying fewer bytes but causing more retransmissions and user complaints.

Export logs and metrics to the organization’s monitoring platform, and alert on meaningful conditions such as repeated link transitions, sustained saturation, failed probes, exhausted translation capacity, or a sudden increase in sessions using a fallback rule. Preserve configuration backups before firmware upgrades and record changes to weights, persistence, and health thresholds.

Use this operational checklist when reviewing the deployment:

• Verify provider bandwidth, gateway reachability, and public NAT ranges.
• Confirm that health probes test beyond the local next hop.
• Review policy order, persistence, and fixed-egress exceptions.
• Test interface failure, upstream failure, recovery, and session behavior.
• Compare LinkProof statistics with firewall, DNS, and application logs.

Active-active WAN balancing delivers the best results when it is treated as a policy and observability project rather than a simple routing change. Build the LinkProof configuration in stages, test each traffic class, and document the expected behavior for every circuit failure scenario. Use those results to refine weights, persistence, and monitoring before expanding the design to additional sites or cloud workloads.