This is our old Q&A Site. Please post any new questions and answers at

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 is trying to initiate a connection to 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  TCP 58  64456 → 22 [ACK] Seq=1 Ack=1 Win=65535 Len=0
11  0.000366  TCP 58  64456 → 22 [ACK] Seq=1 Ack=2721 Win=65535 Len=0
14  0.000611  TCP 58  64456 → 22 [ACK] Seq=1 Ack=5317 Win=65535 Len=0
27  0.003830  TCP 58  64456 → 22 [ACK] Seq=1 Ack=8037 Win=65535 Len=0
113 0.013519  SSH 110 Client: Encrypted packet (len=52)
120 0.229191  TCP 58  64456 → 22 [ACK] Seq=53 Ack=46581 Win=64823 Len=0
227 4.635380  SSH 174 Client: Encrypted packet (len=116)
234 4.862343  TCP 58  64456 → 22 [ACK] Seq=169 Ack=46665 Win=64739 Len=0
931 35.263399  SSH 262 Client: Encrypted packet (len=204)
932 35.263826  TCP 58  64456 → 22 [FIN, ACK] Seq=373 Ack=46665 Win=64739 Len=0
2229    94.854500  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

accept rate: 0%

edited 18 May '16, 06:18

Jasper's gravatar image

Jasper ♦♦

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.

permanent link

answered 18 May '16, 07:04

sindy's gravatar image

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

(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 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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 18 May '16, 06:17

question was seen: 4,793 times

last updated: 18 May '16, 07:40

p​o​w​e​r​e​d by O​S​Q​A