Source Destination
192.168.0.1 192.168.0.2 (client to VIP)
192.168.0.1 192.168.0.3 (LTM to VIP with LTM spoofing the client IP address)
192.168.0.3 192.168.0.1 (server to client)
The issue here is that the server responds back directly to the client--not LTM--because the client is on the same subnet as the server. The server responds back to the client using the server IP. However, the client opened a TCP connection with the VIP address, not the server IP. So the client will drop the packets.
A similar asynchronous routing issue occurs if the pool member's default gateway is not pointing to LTM and the server doesn't have a static route back to LTM for the client. The server responds back directly to the client from the "wrong" IP address.
The best solution for a client and server on the same subnet is to use SNAT so that LTM translates the source IP on the request to the server to its own IP address. This ensures the server response goes to LTM and the response to the client comes from the VIP address. I think you could also use nPath in this scenario, so that the server responds directly to the client from the VIP address. You can search AskF5.com for details on this configuration. However, it means you need to add the VIP address to the server's loopback adapter and you won't see the response through LTM so most persistence methods won't work.
Aaron