Building a Radware Alteon virtual server with SNAT and persistence

A Radware Alteon virtual server provides one stable service address while distributing requests across a real-server pool. Here, source NAT controls the return path, while persistence maintains client affinity. Both features must agree with the network design rather than operate as unrelated switches.

SNAT rewrites the source address seen by a backend. Persistence records which backend should receive a client’s next eligible connection. SNAT supports stateful routing; persistence supports application continuity. Each control addresses a different risk, although production services commonly need both.

For an Australian example, place Alteon between a Sydney office and servers serving a Melbourne branch. Use 10.20.30.40 as the virtual address, 10.20.50.10–10.20.50.12 for backends, and 10.20.30.50 as the SNAT address. Backends use Alteon as their gateway, and Alteon routes traffic back to client networks.

Australian operating conditions shape testing and support. AWS workloads commonly use ap-southeast-2 in Sydney and ap-southeast-1 in Melbourne, while a Brisbane branch adds a distinct path. ANZ business hours, Australian English, day-first dates and daylight-saving transitions belong in runbooks. Regulated organisations can map controls to ACSC Essential Eight guidance.

Plan the traffic path

Prefer a two-arm design with explicit client-facing and server-facing paths. Define the virtual address, client subnets, backend subnets, SNAT address or pool, and gateways before creating services. Keep Alteon’s stateful interface on the return path; use one-arm routing only after proving every return and hairpin flow.

Decide where the virtual IP is advertised and which devices own routes for the SNAT subnet. Check upstream firewall rules, backend routes and asymmetric routing. For hybrid estates, document the AWS VPC, transit gateway, on-premises WAN and branch firewall paths as one stateful flow rather than separate diagrams.

Build the virtual server and pool

Create the IP virtual server with 10.20.30.40, TCP 443 and the required protocol settings, then attach a real-server pool. Give each pool member its address, service port and gateway. The gateway must direct replies through Alteon, and every backend needs a return route to each permitted client network.

Configure active checks against each member’s own address and port, never the virtual address, which could create a feedback loop. Set conservative thresholds to prevent flapping and define behaviour when no members are healthy. Response-based checks suit critical applications; port checks suit stable TCP services.

Configure source NAT

Enable SNAT for the real-server service and choose a dedicated address or pool. A single address is simple, but concurrent sessions can exhaust source ports; a pool separates clients that otherwise share a destination tuple. Record the range outside overlapping LAN or VPC subnets and advertise it through Alteon.

The backend default route must point to Alteon, and Alteon must have a route back to each client network. Verify proxy ARP or route advertisements for the virtual address where required. Do not let replies bypass Alteon because missed flow state commonly produces resets. During failover, confirm that the surviving unit can recreate the SNAT binding and required session state.

Select and apply persistence

For browser applications, Alteon cookie persistence normally gives reliable per-client affinity when cookies are accepted. Source-IP persistence suits clients without application cookies, although users behind shared NAT can be grouped together. SIP persistence fits supported SIP workloads and must match the identifiers used by the application.

Apply persistence at the virtual-server level and confirm its scope, cookie attributes and fallback behaviour for the installed release. It should guide new connections without bypassing health checks or forcing traffic to a failed member. Clear or reroute affinity after a health transition. APIs with external tokens may need none, while applications storing session state on a server usually require reliable affinity.

Validate the traffic flow

Test the virtual address from a Sydney LAN and a Melbourne branch. Inspect backend logs to confirm that the SNAT address is visible. Repeat requests with a cookie jar and then without it; an eligible client should return to the same member while unrelated clients remain balanced.

Use Alteon session, virtual-server and real-server statistics to confirm selection, persistence hits and health. Capture traffic on both interfaces during testing. The expected path is client to virtual IP, Alteon to backend with the SNAT source, then backend through Alteon to the original client.

Troubleshoot state and routing faults

A virtual address that never answers usually indicates an ARP or route fault, missing firewall rule or empty healthy pool. Intermittent resets often point to asymmetric routing, stale persistence or an SNAT address missing from the active unit. Cookie affinity can fail when clients reject cookies, names conflict or redirects bypass the expected path.

Check source-port capacity, state-table limits, backend connection limits, MTU and TCP idle timeouts before extending session timers. Keep appliances in Sydney and Melbourne synchronised to trusted time sources, and record AEDT correctly in evidence; incorrect timestamps can make failover and health events appear unrelated.

Compare persistence choices

Choose based on client behaviour and session state, not pool size. Cookie persistence provides the clearest client identity, source-IP persistence adds no client-visible state, and SIP persistence supports signalling semantics. Weighted balancing without affinity remains suitable for stateless workloads.

Method	Suitable workload	Client-visible state	Main operational risk
Alteon cookie persistence	Browser applications with server-side sessions	Cookie required	Cookies may be rejected, stripped or rewritten
Source-IP hash persistence	API clients and clients without cookies	None	Shared NAT addresses can group many users
SIP persistence	Supported SIP and VoIP services	SIP signalling required	Identifier handling differs between clients
Weighted balancing without persistence	Stateless or externally managed sessions	None	Connections may move when membership changes

For browser-facing Australian enterprise services, Alteon cookie persistence with health-aware fallback provides the usual fit, while source-IP persistence depends on reliable client identity. A production-ready design has already demonstrated persistence and SNAT behaviour during failover from every Australian branch path.