SNAT will not be perform

Hello, Just for sanity's sake did you confirm the client (if using DNS) is receiving the IP address of the virtual server and not of one or multiple of the Pool members IP's themselves? If DNS is set up correctly I would suggest setting a firewall rule on the client so it cannot reach the pool members directly that way you will not get false positives and know immediately once it is working during T/S without having to run wirehsark or tcpdump on the pool members themselves to check originating IP.

You could also do a tcpdump on the client side to see if it is communicating with the VIP, or to James' point, directly to the server. If you are capturing the client side and server side and indeed confirm that source is unaltered, I've never seen SNAT just not work, so I would step through the config again. Is the SNAT enabled on the right VS in the right partition and route domain? Do you see the connection counter increment on the VS you expect and see the connection in the conn table? I also like troubleshooting with iRule. Setup a rule to log the connection to see where the breakdown is.

Yes I can confirm traffic is hitting the correct VIP and also iRule with selective snat automap will be triggered correctly. This is what I see with tcpdump (10.10.10.10 is just a dummy to hide the real source-IP):

tcpdump -ni 0.0:nnnp host 10.10.10.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0:nnnp, link-type EN10MB (Ethernet), capture size 96 bytes
17:46:55.901915 IP 10.10.10.10.27641 > 10.173.166.11.https: S 1976048938:1976048938(0) win 65535 
17:46:55.901979 IP 10.173.166.11.https > 10.10.10.10.27641: S 3089042794:3089042794(0) ack 1976048939 win 4380 
17:46:55.919357 IP 10.10.10.10.27641 > 10.173.166.11.https: . ack 1 win 12047 
17:46:55.959480 IP 10.10.10.10.27641 > 10.173.166.11.https: P 1:229(228) ack 1 win 12047 
17:46:55.959611 IP 10.173.166.11.https > 10.10.10.10.27641: P 1:111(110) ack 229 win 1095 
17:46:56.056289 IP 10.10.10.10.27641 > 10.173.166.11.https: . ack 111 win 12047 
17:46:56.056297 IP 10.173.166.11.https > 10.10.10.10.27641: P 111:212(101) ack 229 win 1152 
17:46:56.112440 IP 10.10.10.10.27641 > 10.173.166.11.https: P 229:336(107) ack 212 win 12047 
17:46:56.112472 IP 10.173.166.11.https > 10.10.10.10.27641: . ack 336 win 1178 
17:46:56.112588 IP 10.173.166.11.https > 10.10.10.10.27641: . ack 336 win 1178 
17:46:56.137599 IP 10.10.10.10.27641 > 10.173.166.11.https: P 336:725(389) ack 212 win 12047 
17:46:56.137634 IP 10.173.166.11.https > 10.10.10.10.27641: . ack 725 win 1276 
17:46:56.139502 IP 10.10.10.10.33855 > 10.174.102.12.us-cli: S 3119386950:3119386950(0) win 4380 
17:46:57.139571 IP 10.10.10.10.33855 > 10.174.102.12.us-cli: S 3119386950:3119386950(0) win 4380 
17:46:58.139227 IP 10.10.10.10.33855 > 10.174.102.12.us-cli: S 3119386950:3119386950(0) win 4380 
17:46:59.139457 IP 10.10.10.10.33855 > 10.174.102.12.us-cli: S 3119386950:3119386950(0) win 4380 

As you can see the last four packets are unsuccessful SYN-requests, because the source-IP is still the same and response is not getting back to the LB. Any idea how I can further analyze this? I mean SERVER_CONNECTED event in an iRule will not be trigger, because the TCP-handshake is not successful.

Ciao Stefan 🙂