Altocumulus
AltocumulusWe've been testing it in a Lab Environment, and made such progress.
We keep in the lab the Virtual IP forwarding virtual server wildcard with 0.0.0.0 for source and destination, only specific the port as 80 (HTTP). Different port from the client just for lab pourpouses. And it worked well.
Then, we started the tests, first besides the Virtual IP forwarding virtual server wildcard, we've configured two more IP forwarding virtual server, each from one specific client source, specifying the IP 10.1.0.10/32 and 10.1.0.20/32 for example, using the mask /32 for each 2 new Virtual Servers, and keeping the destination as 0.0.0.0 or 0.0.0.0/0 (both worked). When we did that, the traffic from these sources matched the criteria for each one of these new IP forwarding virtual server and it worked, as we could see in the statistics from the vrtual servers and tcpdump capture.
So, it was time to perform the tests using the IP Address Lists (shared objects), and differing from the client configuration, we configured specifying the IPs with a /32 mask into the IP Address List we created. Deleting the two IP forwarding virtual server confiugured each with one source, we keeped the wildcard and configured a new one, with the Address List as source, and the destionation as 0.0.0.0 or 0.0.0.0/0 (both worked too), and port 80, keekping the wildcard IP forwarding virtual server and this new IP forwarding virtual server with de same destination 0.0.0.0 and port 80, differing only that the IP forwarding virtual server wilcard matching any source to any destionation at port 80, and the new IP forwarding virtual server matching any the both /32 prefixes configured in the Address List as source to any destination at port 80. Ir worked fine in our lab!
Now we're waiting the customer to make some adjustments in the production BIG IPs.