One-Arm VIP with Asymmetric Return Traffic
An LTM runs 15.1 in a one-arm deployment. Virtual server vip_web 10.20.9.100:443 uses pool web_pool with members 10.20.8.21:443 and 10.20.8.22:443. The BIG-IP self IP is 10.20.9.10. Remote clients on 10.40.0.0/16 fail after the TLS ClientHello, and browsers report connection resets. A capture on a failing client shows the SYN-ACK arriving from 10.20.8.21, not from 10.20.9.100. The pool members' default gateway is 10.20.8.1, a router that has a route back to 10.40.0.0/16 but does not steer that traffic through the BIG-IP. No SNAT is configured on the virtual server. Application owners refuse to change pool-member gateways. Security requires that pool members see the real client IP for audit logging. A curl test from the BIG-IP to 10.20.8.21:443 succeeds, and both pool members are healthy.
1. Explain why client connections fail and why the BIG-IP's own curl test succeeds. Which virtual-server setting is missing?
Read the worked answer
Reasoning
The client sends a SYN to 10.20.9.100:443. The LTM accepts it and DNATs the destination to 10.20.8.21:443, but with no SNAT the source address is still the client's 10.40.x.x address. The pool member replies to 10.40.x.x through its default gateway 10.20.8.1. That router delivers the SYN-ACK directly to the client, bypassing the BIG-IP. The client's TCP stack has a connection keyed to 10.20.9.100:443, not 10.20.8.21:443, so it resets or ignores the packet. The BIG-IP curl test succeeds because the BIG-IP is the source, so the return path terminates on the BIG-IP and there is no client-side 4-tuple mismatch.
Missing setting
source-address-translation is not enabled on the virtual server. A SNAT pool or automap would make pool members return traffic to the BIG-IP, which can then translate it back to the client. This is a routing/path problem, not a pool or monitor problem.
2. The application team proposes `source-address-translation: automap`. Does that satisfy the security requirement? Give a design that resolves the conflict.
Read the worked answer
Reasoning
automap fixes the return path because pool members reply to the BIG-IP self IP. However, it also rewrites the client source address, so pool members no longer see the real client IP. The audit requirement is therefore not met at the IP layer. The available choices are:
- Use SNAT plus application-layer client identity. If SSL is terminated on the LTM and the app is HTTP, insert
X-Forwarded-Foror a proprietary client-IP header. If the app supports PROXY protocol, use that instead. Neither works for arbitrary TCP unless the app supports it. - Change the pool members' default gateway to the BIG-IP and remove SNAT, preserving the original source IP. The application owners have refused this.
- Use policy routing on 10.20.8.1 to send return traffic through the BIG-IP, which is still a network change and may create asymmetric paths.
A defensible design is automap or a sized SNAT pool for the return path, plus X-Forwarded-For only if the app can consume it. If the app cannot accept a header, the two requirements conflict and the gateway or routing must change.
3. What verification steps would confirm the fix and catch SNAT port exhaustion?
Read the worked answer
Reasoning
Verify both directions rather than only the virtual-server status:
- Client capture: SYN-ACK must come from 10.20.9.100:443, not the pool member.
- Pool-member capture: source must be the SNAT address, and the app log must show the forwarded client IP if a header was added.
tmsh show ltm virtual vip_webandtmsh show ltm pool web_poolfor connection counts and failures.tmsh show sys connectionand SNAT pool statistics to watch port usage. Withautomap, the BIG-IP may rely on a single self IP, so high connection volume can exhaust ports; a SNAT pool with multiple addresses is the usual remedy.- Repeat the test from several 10.40.0.0/16 clients and confirm the application receives the expected identity field.