Forum Discussion
Do the servers use the F5 as their default gateway (or have proper return routing to the F5 configured) ? If not, you'll need to apply a SNAT configuration to the VIP so return traffic is properly routed back to the backend server. SNAT with automap would be the most basic configuration that will likely get this to work, this setting is on the VIP configuration screen.
A basic overview of how this could be failing: you're looking at an asymmetric traffic path where your server 10.185.172.212 is sending traffic to the VIP 10.185.172.80. The F5 proxies that traffic but maintains the source IP of 10.185.172.212. When responses are sent back to the originator, the backend server will use the default gateway to return traffic back to the source IP (which is likely NOT the F5 in this case). SNAT will cause the F5 to use a self-IP as the originating IP address, which will cause return traffic from the backend server to be sent back to the F5 and on back to the original client.
Hope this makes sense, it was written quickly. I can break this down further if you'd like.
One downside to SNAT is that you can lose the original IP address in the backend server logs (if it's a webserver), but this can be remedied by using x-forwarded-for headers (which is an option in an HTTP profile on the F5).
pool members are up and running. since the members are setup with port 5590 it has standard TCP monitors on them. i can telnet to VIP without any issues. it is just accessing the VIP from 10.185.172.212/213 is the problem.
i have opened F5 support case and we took a few captures, however we were not able to determine root cause for this behavior. we also enabled SNAT but that did not resolve anything.