This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

ACK but no SYN

0

I placed a packet capture on a particular interface of an ASA firewall with a view to establishing what a device connected to that interface was trying to do and hence what ACL I needed on the interface. Below is an extract from the packet capture, filtered on both source and destination address (anonymised). From what I know about this particular application I believe the device on 10.0.0.1 is trying to initiate a connection to 172.16.0.1 but I am not seeing any SYN packets, only ACK.

Can anyone explain why I might not be seeing any SYN packets?

10  0.000351    10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [ACK] Seq=1 Ack=1 Win=65535 Len=0
11  0.000366    10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [ACK] Seq=1 Ack=2721 Win=65535 Len=0
14  0.000611    10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [ACK] Seq=1 Ack=5317 Win=65535 Len=0
27  0.003830    10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [ACK] Seq=1 Ack=8037 Win=65535 Len=0
113 0.013519    10.0.0.1    172.16.0.1  SSH 110 Client: Encrypted packet (len=52)
120 0.229191    10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [ACK] Seq=53 Ack=46581 Win=64823 Len=0
227 4.635380    10.0.0.1    172.16.0.1  SSH 174 Client: Encrypted packet (len=116)
234 4.862343    10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [ACK] Seq=169 Ack=46665 Win=64739 Len=0
931 35.263399   10.0.0.1    172.16.0.1  SSH 262 Client: Encrypted packet (len=204)
932 35.263826   10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [FIN, ACK] Seq=373 Ack=46665 Win=64739 Len=0
2229    94.854500   10.0.0.1    172.16.0.1  TCP 58  64456 → 22 [ACK] Seq=374 Ack=46666 Win=64739 Len=0

Thanks, Phil.

asked 18 May '16, 06:17

phil6564's gravatar image

phil6564
6●1●1●2
accept rate: 0%

edited 18 May '16, 06:18

Jasper's gravatar image

Jasper ♦♦
23.8k●5●51●284

One Answer:

1

Don't let the fact that seq and ack numbers start from 1 mislead you. Unless you explicitly tell it not to do so, tshark (and Wireshark as well) shows relative values, and takes the values in the very first packet of each tcp session it can see as references, hence the relative values shown for them are 1. However, the first packet seen in the capture may not be the first packet in the session. So unless you are really, really, really sure that the session you've shown here has started later than the capture itself, the simplest explanation is that the session had already been established when you started to capture.

answered 18 May '16, 07:04

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%

edited 18 May '16, 07:06

Thanks for your response Sindy.

So, from the output above, without seeing any SYN packets, is it possible to say for certain that connections are being initiated from 10.0.0.1?

(18 May '16, 07:24) phil6564

Well, nothing is really certain, but as tcp/22 is a "well-known" port at which the ssh service is listening on servers, while tcp/64456 is a typical client-side ephemeral port (which the client's TCP stack chooses when initiating sessions), and as the contents of those packets seems to make sense to the SSH dissector which tshark has chosen to dissect them based on the use of the tcp/22 port, we can assume that the session has really been initiated by 10.0.0.1 quite safely.

What would bother me as a network administrator would be why I can see only packets in one direction. If it is due to your use of capture filter or display filter which hides the other direction from being seen, or due to mirroring of only one direction of a switch port, allright; otherwise (i.e. if no packets are filtered out intentionally), I'd assume that the other direction bypasses the interface at which you capture, which could affect the ability of the ASA to handle the traffic properly.

(18 May '16, 07:40) sindy