This has been a perplexing issue for many users.  How do you introduce an intermediary (LTM going forward) between client and server when in the same network segment?  It’s easy when the LTM sits at gateways, but within a segment, it doesn’t work that well without some help.  Why?  Well, with tcp-based connection-oriented protocols, a handshake (consisting of a client syn packet, a server syn-ack packet, and a server ack packet) sets up the connection.  When you introduce the LTM, a problem arises:

Client –> syn –> BIG-IP

BIG-IP –> syn-ack –> Client

Client –> ack –> BIG-IP

BIG-IP –> syn –> Server

Server –> syn-ack –> Client

Client –> reset –> Server

Do you see the problem?  It’s actually in the step prior to the reset.  Because the server and client are on the same segment, the server sees the client’s source IP, and because it is local, sends an arp (if not already cached) and then forwards directly to the client, bypassing the BIG-IP.  The client then resets this connection because it has no established service with the server.  So how do you address this issue?  Enter address translation.  By translating the client’s source address before sending traffic to the server, the BIG-IP ensures that the server relays the responses back through it before forwarding on to the client.  The downside here, however, is that now the server cannot see the client source address, which impacts reporting and potentially some functionality.  With HTTP, this is easily addressed with the X-Forwarded-For header, but it’s problematic for other protocols.

Check out this thread, it’s a great discussion on some of the issues and solutions for same segment load balancing.  BTW, some of the other names for this deployment are VIP Bounceback, BIG-IP on a Stick, and One-Armed Configuration.