You might consider scanning the VIPs if you want to get a "hacker's eye perspective" but it doesn't give you a true picture of the risk posture of the pool members behind the VIP. Also, be careful that your load balancer does not have egregiously long session timeouts, use "TCP Intercept mode", and ensure it does not respond in any way to datagrams sent to VIPs not in use (silently drops datagrams). If the load balancer is improperly configured and you start scanning large numbers of VIPs not only can you see the "ghost host" problem, but you run the risk of excessive resource consumption on the load balancer.

Load balancers are by their very nature intended to hide what is behind them. That is part of what the technology does. We can perform some analysis on IP TTL, TCP ISN, and HTTP headers to attempt to identify what is behind the LB, but this is inherently limited by the technology. Also, the LB is likely to only allow 80, 443 or other web traffic for example, it will likely not allow connections to arbitrary network ports on the pool members, and even if it did it is load balancing them.

Instead, you should scan the pool members directly. There are several ways to do this depending on the architecture. If you have scanners that can reach the pool members directly over L3 that will work. Alternately, if they are in a VLAN segregated behind the LB you could present the scanner a trunk port and configure the scanner with a VLAN IP and tag and use L2 to move the scan traffic. Additionally as the previous post mentioned, deploying a scanner directly into that network will also work.

You might consider scanning the VIPs if you want to get a "hacker's eye perspective" but it doesn't give you a true picture of the risk posture of the pool members behind the VIP. Also, be careful that your load balancer does not have egregiously long session timeouts, use "TCP Intercept mode", and ensure it does not respond in any way to datagrams sent to VIPs not in use (silently drops datagrams). If the load balancer is improperly configured and you start scanning large numbers of VIPs not only can you see the "ghost host" problem, but you run the risk of excessive resource consumption on the load balancer.

Load balancers are by their very nature intended to hide what is behind them. That is part of what the technology does. We can perform some analysis on IP TTL, TCP ISN, and HTTP headers to attempt to identify what is behind the LB, but this is inherently limited by the technology. Also, the LB is likely to only allow 80, 443 or other web traffic for example, it will likely not allow connections to arbitrary network ports on the pool members, and even if it did it is load balancing them.

Instead, you should scan the pool members directly. There are several ways to do this depending on the architecture. If you have scanners that can reach the pool members directly over L3 that will work. Alternately, if they are in a VLAN segregated behind the LB you could present the scanner a trunk port and configure the scanner with a VLAN IP and tag and use L2 to move the scan traffic. Additionally as the previous post mentioned, deploying a scanner directly into that network will also work.