Machine calling VIP, VIP, pool members all on same network?

 
 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

thanks always for the reply.

 

 

If I do a netstat on both client(who is initiating the connection) and server(pool member) machines, should I see evidence of this?

 

 

I only see connection to LTM on both the client and pool member.

The direct connection between pool member and client has probably already been reset, so it would be tough to catch it in a netstat. The client is going to immediately reset the packet that comes directly back from the server because it didn't open a session with the server, it opened it with the LTM virtual. A Wireshark capture should show this though.

 

 

Denny

I did tcpdump on both machines, and see no mention of the other machine on either client or server. Only client to LTM and server to LTM, etc.

 

 

How is it that the pool member which "know" who the client is to send the traffic back directly? Would it be receiving the mac address via the request through the LTM?

 

 

thanks

If you aren't using SNAT, the LTM preserves the client's source IP by default when it sends the packet to the pool member. So the pool member will respond using its' own routing table to the client. If the client is on the same subnet, it's Layer 2 connected and will arp for the client and send the response directly to him, bypassing the LTM. The client will reset that packet, because he never opened up a session with the pool member directly.

 

 

Denny

OK Sorry about all of the confusion

 

 

I am under Local Traffic -> Snats -> We have one down that has :

 

 

Translation automap

 

Origin All Addresses

 

VLAN Traffic All VLANs

 

 

If I am understanding correctly, this is going to SNAT all traffic even though I don't have SNAT configured on any of the Virtual Servers (Under Advanced)? Then this would explain my "problems" of not seeing the true source addr?

 

 

Thanks again.

Correct, a global SNAT will take effect whether or not SNAT is configured on the virtual server.

 

 

Denny