SNAT Automap After a Planned Failover

Root cause

SNAT automap does not use a fixed address. On each new connection it chooses a self IP on the egress VLAN, on the device that is active for that traffic. Before failover, device A was active, so connections to the servers were translated to 10.1.1.10 and the firewall permitted them.

After failover, device B is active and owns the floating client-facing address, but the server VLAN self IP 10.1.1.11 is a non-floating address that belongs to device B. Automap uses 10.1.1.11 for new connections. The server's firewall has no rule for 10.1.1.11, so the SYN is dropped and the client times out. The capture proves the BIG-IP is forwarding the SYN; the problem is the source address, not the virtual server or pool health.

This is a design failure: a translation address that changes with the active device is invisible to a downstream firewall that allows only one address.

Option 1: Make the server-side self IP floating

Create the server VLAN self IP in traffic-group-1 so it moves with the active device. Use one address, for example 10.1.1.10, active only on the traffic-group-1 active device. Automap then always translates to that address. Remove or re-address the non-floating 10.1.1.11 to avoid an address conflict. This is the cleanest fix because the firewall rule remains narrow and the address is stable.

Trade-off: the server VLAN now depends on the same traffic group as the virtual server. Verify that the switch and servers accept gratuitous ARP for the moved address, and that the floating self IP is not also used for management or another purpose.

Option 2: Use an explicit SNAT pool

Create a SNAT pool containing a floating translation address in traffic-group-1, then change the virtual server from automap to that SNAT pool. This decouples the translation address from the egress interface self IP and makes the intent explicit.

Trade-off: it adds an object to manage, and the SNAT address must be routed back to the BIG-IP and permitted by the firewall. A third option, widening the firewall to allow both self IPs, works technically but weakens the control and leaves future failovers dependent on firewall maintenance.

Original client visibility

No. With SNAT, the server sees the translation address, not the client. Changing the SNAT pool does not restore the client IP; it only changes which BIG-IP address appears.

Practical options

• Insert an application-aware header. If the virtual server has an HTTP profile, enable Insert X-Forwarded-For and have the application log it. This is the least disruptive option, but it trusts the header and only works at HTTP level.
• Use a PROXY protocol profile if the application supports it. The server then receives the original connection information in the PROXY header. Both the BIG-IP and the application must be configured for it.
• Remove SNAT only if routing is designed so that server return traffic passes back through the BIG-IP. This preserves the client source address but usually requires the server default gateway to point at a BIG-IP self IP or floating address, and it reintroduces routing symmetry requirements.

Do not simply disable SNAT without verifying the return path. The current firewall rule and server default gateway show that return traffic is not designed to transit the BIG-IP, so removing SNAT would break the connection.