Forum Discussion
CirrusSNAT will not be perform
It seems I have a strange issue at the moment. I've a HTTPS VS with SNAT automap enabled, but when I sniffer the traffic I always see the real client-IP as source on the serverside connection. I also tried it with a SNAT pool or an iRule, but always the same behavior. There is also no OneConnect configured on the VS. The poolmember IPs are not directly connected, but there is a proper route available (TCP monitor is green).
Any idea what could cause this strange behavior?
Ciao Stefan :)
3 Replies
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.
Josh_AbaireNimbostratus
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.
- Stefan_Klotz
Cumulonimbus
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 4380As 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 🙂
