Forum Discussion
Josh_41258
Nimbostratus
NimbostratusRouting issue?
Here is my scenario:
(2) LTM6400's in an Active/Passive pair running 9.4.5 HF2.
Internal VLAN - 1.1.1.1/24
External VLAN - 2.2.2.2/24
All back end pool members reside on the "internal" VLAN and all VIP's reside on the "external" VLAN. Very basic setup. We typically use SNAT as most of our applications do not use the LTM as their default gateway.
We now have a need for the pool member to see the original client's IP address (can't use X-Forwarded-For). To do this, I changed the default gateway of the servers from 1.1.1.1 to the "internal" floating self-IP address of the pair (1.1.1.10). I then created a wildcard forwarding virtual server (0.0.0.0/0.0.0.0).
I am able to reach internal and internet hosts from the server.. everything looks good at this point. I also created a few administrative VIP's so I could reach the servers.
The problem:
When I try to access a VIP (whos pool members use the LTM as their default gateway) from another machine on the same "internal" (1.1.1.1/24) network, the connection fails. It appears that it makes it's way to the backend server, but never back through the load balancer to the client. Is this because the F5 is trying to route packets out of the same (internal) interface?
I can provide more details if possible.. any suggestions or advice would be much appreciated.
Thanks,
Josh
- dennypayne
Employee
Posted By jbaird on 07/16/2009 1:30 PM
When I try to access a VIP (whos pool members use the LTM as their default gateway) from another machine on the same "internal" (1.1.1.1/24) network, the connection fails. It appears that it makes it's way to the backend server, but never back through the load balancer to the client. Is this because the F5 is trying to route packets out of the same (internal) interface?
You're partially correct, the packet does make its way to the backend server and not back through the LTM, but the reason is because without SNAT you are preserving the original client's source IP. In this case, that source IP is on the same network as the backend server. So the backend server simply ARP's for the client IP and sends the packet directly back to the client, bypassing the LTM. The client drops it because he doesn't think he's got a connection with the backend server, his connection is with the VIP.
So you need to re-enable SNAT for internal connections. There's a couple of ways to do that. One is, you can change the existing VIP address to be enabled only on the external VLAN and then leave it alone. Create an identical VIP that is enabled only on the internal VLAN, and enable SNAT automap under Advanced. Another method would be to use an iRule that would apply the SNAT when it detected client connections from the internal network. Either way, you're still going to lose visibility to internal client IP's, but that usually isn't a problem, most people just want to track external IP's.
If you really really need to see client IP's from internal boxes as well, then the only way to solve this would be to move all potential client machines into another VLAN so that direct Layer 2 communication between them is not possible.
Denny 
Josh_41258Thanks for the quick and detailed response. This makes total sense. Unfortunately, I need to track internal IP's as well -- or the web filtering system (Websense) will not work properly. Looks like I need to move these machines to a separate VLAN.
Thanks,
Josh
