I've got a socks proxy configured on LTM in a big-ip cluster.
Would you expect the onward comms to come out of the floating or none floating ip?
It's currently coming out of the non-floating interface and i was expecting the comms to come out of the floating interface.
Have i missed something or is this how it works?
Ta - Fletch
I was under the impression that any connection originating from the BIG-IP would use the self-IP by default-ish. Management type traffic, like LDAP queries, DNS queries, etc use TMM self IP. So do health check monitors against a pool member. However, generally you can source NAT the F5 BIG-IP connection through a VIP using a pool or even an iRule. Are you able to select a SNAT pool on the VIP assigned to the socks proxy config? (I presume you have internal clients targetting the VIP for their proxy needs.) My preference is to use the VIP as the same IP in a SNAT pool, so its easy to marry client side and server side of a connection (yes, up to 64k active sessions or so, so one needs to be cautious here with this methodology).
@PSFletchTheTek As @whisperer stated typically if you do not have SNAT configured it will leave on the non-floating self-IP rather than the floating self-IP in the HA cluster. Now you can most likely change what IP you want to source your traffic from by using a SNAT pool list rather than SNAT automap but you don't have to. I would recommend using a SNAT pool list because if you ever are in a situation where you have high connections your LTM will start to behave in an unexpected manner because of port exhaustion from using automap. I would recommend using the IP of the proxy in the SNAT pool list so that you know traffic coming from that IP is SOCKS proxy related. In addition you should avoid using the non-floating and floating self-IPs for virtual server configuration since those IPs are typically utilized for routing traffic or managing the device itself. You should be able to see a SNAT option and then a suboption appear of automap or a specific SNAT pool list when you turn SNAT on.
i've got it set to automap, but i'll try enforcing a snat pool and see if it works, but i thought automap would do the same.
The one thing to note, is socks does not work like the load balancing that the f5 normally does, it has no pool in the config, the socks protocol tells the f5 where to communicate to.
I'll try snat pool and report back. thanks
Sounds good! Keep in mind that with auto map, the F5 will use a self IP address associated with the egress VLAN. So definitely why you are seeing the F5 self IP address on the server side of the connection. Even if there are no traditional pool members, since the F5 proxies to target locations, those connections would be considered the server side.
@PSFletchTheTek At face value both automap and a SNAT pool list work the same overall but source from different IPs. Automap definitely uses the closest non-floating self-IP closest to the destination which is the behavior that you are seeing. When you make the switch from automap to SNAT pool list ensure that you are allowing that SNAT pool list IP outbound to reach the particular destinations you are attempting to reach. As @whisperer noted, even though you aren't load balancing traffic the way traditional virtual servers are configured it still functions the same way as far as passing traffic that has arrived at the F5 much like a forwarding virtual server functions when you have an F5 in path and routing traffic from external to internal on the F5.