Hi, Kindly help based on 2 capture below, why the delay / error ? client = 192.168.19.175 ( NAT IP : 192.168.30.134 ) Server = 192.168.5.18 virtual IP ( node C IP : 192.168.5.113 ) Server under the NLB.... Below capture from client to Node C Below capture at Server Node C asked 11 Jan '16, 03:22  suarez showing 5 of 7 show 2 more comments |
One Answer:
It seems that your NAT box establishes the tcp session locally before receiving the SYN,ACK from the real server, so when the client starts sending real data packets, the NAT box is unable to forward them because the session at public side has not been established yet. As for the reason why the server ignores the incoming SYN packet: seeing the "tcp port numbers reused" expert info at the first occurrence of the SYN packet together with the time it took the server to respond the SYN packet, I would assume that the previous session to the server from the same source socket (of the NAT) has been closed from client initiative, and thus the server has been in TIME_WAIT state since then and has responded the SYN only after that state has timed out. Look at the last packets with same source and destination port which came before the first SYN to confirm this. answered 11 Jan '16, 04:01  sindy edited 11 Jan '16, 04:03 Maybe, maybe not... Without the trace files it is hard to say. Two small example: The SYN Packets have different length in both traces. And the SYN/ACK offers different MSS (11 Jan '16, 04:06) Christian_R @suarez, have you noticed that only 5 comments are shown to each Question or Answer and you have to press "show X more comments" to read the additional ones? (13 Jan '16, 00:44) sindy |
Could you publish the capture file (anonymized using TraceWrangler if necessary so that the tcp payload and the real IP addresses are not disclosed) somewhere and put a link to it here.
I would extend @Christian_R's requirement to both files, and not filtered to just a single tcp session each. @Christian_R's remark has drawn my attention to the fact that the source port is the same for packets sent from client to the NAT box and from the NAT box to the server, which does not necessarily mean that they come from the same session, while the timestamps are slightly shifted. So knowing nothing about the mutual offset of the timestamps on both machines, I'm afraid that we'll not be able to match the client-NAT and NAT-server sessions to each other by anything else but the payload contents. Or it is not a plain NAT but a MITM box and then even the payload won't help, so you'd have to get rid of all the other traffic while capturing.
One more sample...
Client Screenshot...port 9776
server Screenshot...port 9776
1) There is lost packets a. Client site send around 9 packets to server b. Server site only receive 6 packets 2) Packet information changed when reached server a. Client site send PSH, ACK packet to server b. Server Receive the packet as SYN.
You cannot get a better answer by providing more screenshots. You may get a better one if you post links to the capture files, as asked by @Christian_R.
Once again, the NAT often changes the port numbers, so you cannot be sure that the packets in the two captures come from sessions matching each other.
NB: relative times are worse than absolute ones when it comes to matching two captures to each other.
Hi Thanks Sindy and Cristian_R
I have upload files to cloudshark... Below is the link..I have remove Setting for Payload sanitization > Remove all unknown layers ( cut away bytes from packets ) using Trace Wrangler...
CLIENT https://www.cloudshark.org/captures/0605c5094ba9
SERVER node A https://www.cloudshark.org/captures/dc238978f7b7
SERVER node C https://www.cloudshark.org/captures/c3cc23dcfcb7
Thank you very much :)
Once more:
what makes you believe that your NAT device uses, at its public side, the same port which the client on private side is using? Some NATs do act like this unless specific circumstances force them not to do so, but more often the source port of the source-NATed packet differs from that of the same packet before the source-NAT was applied.
as you have removed everything above the tcp level, we cannot verify by payload contents whether the packets before and after pass through NAT belong to each other. The payload of the client Hello may not be enough and at least one response may be necessary.
even if you would have provided information about offset between the timestamps in the captures, the processing delay of the NAT device may be too high to allow to reliably correlate the captures without the payload contents.
So at the moment I can only repeat that I can see in the capture at Node A that in the previous TCP session using the same socket pair like the one affected with retransmissions, the client (or the NAT device) sends FIN first, which causes the server side to go into TIME_WAIT state after closing the session, which usually lasts for two minutes. The last ACK packet of the "previous" TCP session, in frame 23, comes at 11:16:28.368, so the server ignores any packets from the same source socket to the same destination socket until 11:18:28.36 because it treats them as wandering packets belonging to that last session. This is the case for all the SYN packets from frame 24 (the initial SYN packet) through frame 27 (which has come at 11:18.22.287), and the server has only "taken seriously" the retransmission of the SYN which has come at 11:18:46.266 (frame 28).
Whether this also explains why the TCP Hello from the client is retransmitted depends on whether the packets which the client is sending from port 9776 are also sent from port 9776 by the NAT device. If the NAT really maintains the source port unchanged, then my original answer is valid (the NAT device establishing the session with the client before the twin session gets established between the NAT device and the server); otherwise, these two phenomenons are unrelated because the two tcp sessions using source port 9776 are unrelated.
Hi,
does anyone have an idea related to this issue..? thanks