Re: Need Help Reading Capture

[<Tim.Poth () bentley com>]

Hi Chris, 
Its abit of PITA with just the text but I do see a reset coming from 8.25.230.32 to 192.168.123.3 that MIGHT be what's 
showing up in the sonicwall  logs. 

Frames 36 and 37 show the session being shutdown (fin,ack) 


No.     Time        Source                Destination           Protocol Info
     36 4.050429    192.168.123.3         8.25.230.32           TCP      https > 49284 [FIN, ACK] Seq=1051 Ack=1455 
Win=18944 Len=0

No.     Time        Source                Destination           Protocol Info
     37 4.081456    8.25.230.32           192.168.123.3         TCP      49284 > https [FIN, ACK] Seq=1455 Ack=1014 
Win=65536 Len=0



Frame 38 shows 192.168.123.3  sending an ACK back to 8.25.230.32 which is normally expected ( see frames 51 ~ 54 which 
shut down a session without a reset)



No.     Time        Source                Destination           Protocol Info
     38 4.081467    192.168.123.3         8.25.230.32           TCP      https > 49284 [ACK] Seq=1052 Ack=1456 
Win=18944 Len=0

        [This is an ACK to the segment in frame: 37]
        [The RTT to ACK the segment was: 0.000011000 seconds]



But in this case we get a RST back rather than an ACK so something 'funny' has happened to this session.


No.     Time        Source                Destination           Protocol Info
     41 4.087378    8.25.230.32           192.168.123.3         TCP      49284 > https [RST, ACK] Seq=1456 Ack=1051 
Win=0 Len=0


Same pattern happens frames 90 ~ 93 but we have other sessions that end in a finack, finack, ack, ack (EG 51 ~ 54). The 
difference I can see is in frame 35 and 89 where we get a ' Encrypted Alert'. Encrypted Alerts are not 'bad' per say, 
they could be that the session is done and is being shut down. It could however indicate that something 'bad' happened 
to the session / client / server application and the session is ending early. 



No.     Time        Source                Destination           Protocol Info
     35 4.050392    192.168.123.3         8.25.230.32           TLSv1    Encrypted Alert



You could have a look at the logs on 192.168.123.3 since it's the device that sent the alert and see if you can figure 
out why, there might also be some info in the frame that I cant see from the text that wireshark could show or you 
might need to pull a copy of the cert from the server and decrypt the sessions and see what it looks like. 
http://wiki.wireshark.org/SSL

Hope that helps
tim






-----Original Message-----
From: wireshark-users-bounces () wireshark org [mailto:wireshark-users-bounces () wireshark org] On Behalf Of Chris 
Arnold
Sent: Tuesday, February 12, 2013 3:26 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Need Help Reading Capture

Hi Tom,
Thanks for the reply. Here is the complete capture from the host ip. This is coming from the internet 8.25.xx.xx to the 
sonicwall which forwards to 192.168.123.3 (this is an apache proxypass) then sends to 192.168.123.4. This was run on 
192.168.123.3 (apache proxypass):

~snipped packets to make this e-mail shorter~


----- Original Message -----
From: "Tim Poth" <Tim.Poth () bentley com>
To: wireshark-users () wireshark org
Sent: Tuesday, February 12, 2013 3:11:01 PM
Subject: Re: [Wireshark-users] Need Help Reading Capture

Hi Chris,
I assume publicip is the sonicwall? I don't see a reset going to the sonicwall in what you have here, but then there 
are other unseen things so maybe the snip is too small?
The device that generated the reset is listed in the source column so the reset in frame 66 is sent by .4 to .3 BUT it 
seems like the reset is in response to a FIN ACK from .3 (frame 64). I have no way of knowing if the activity in frames 
64 / 66 are related to frame 60 ~ 63. (I guess no but...) IF it is related than I would think there is something amiss 
with the SSL handshake, you could try to turn off SSL and see if the problem goes away or check out the logs on .3. As 
I don't see a reset going to publicip it could be the reset is not happening on your network but rather on the 
internet. Again this could go back to a SSL handshake issue and it could be the client resetting the connection. It 
could be frame 66 isnt the reset your looking for.
Hope that helps
tim

-----Original Message-----
From: wireshark-users-bounces () wireshark org [mailto:wireshark-users-bounces () wireshark org] On Behalf Of Chris 
Arnold
Sent: Monday, February 11, 2013 4:47 PM
To: wireshark-users () wireshark org
Subject: [Wireshark-users] Need Help Reading Capture

Hello all! New to the list and wireshark. I am having problems with a client connection from the internet (my sonicwall 
tells me:
02/11/2013 14:11:29.576 Debug Network TCP connection abort received; TCP connection dropped 8.25.230.32, 49333, WAN 
192.168.123.3, 443, LAN TCP Flag(s): ACK RST). So i ran wireshark and captured https traffic. I need help in 
determining which device (pc or sonicwall) is generating ACK RST. Can someone help me do that? Here is the start of the 
trouble connection and line 66 is the RST:

57      12.403536       pu.bl.ic.ip     192.168.123.3   TCP     49386 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1332 WS=8 
SACK_PERM=1 
58      12.403560       192.168.123.3   pu.bl.ic.ip     TCP     https > 49386 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 
MSS=1460 SACK_PERM=1 WS=6
59      12.448002       pu.bl.ic.ip     192.168.123.3   TCP     49386 > https [ACK] Seq=1 Ack=1 Win=66560 Len=0
60      12.448387       pu.bl.ic.ip     192.168.123.3   TLSv1   Client Hello
61      12.448409       192.168.123.3   pu.bl.ic.ip     TCP     https > 49386 [ACK] Seq=1 Ack=149 Win=15680 Len=0
62      12.448795       192.168.123.3   pu.bl.ic.ip     TLSv1   Server Hello, Change Cipher Spec, Encrypted Handshake 
Message
63      12.496943       pu.bl.ic.ip     192.168.123.3   TLSv1   Change Cipher Spec, Encrypted Handshake Message, 
Application Data
64      12.497212       192.168.123.3   192.168.123.4   TCP     47533 > https [FIN, ACK] Seq=1 Ack=1 Win=364 Len=0 
TSV=73368246 TSER=1862090175
65      12.497255       192.168.123.3   192.168.123.4   TCP     47715 > https [SYN] Seq=0 Win=14600 Len=0 MSS=1460 
SACK_PERM=1 TSV=73368246 TSER=0 WS=6
66      12.497404       192.168.123.4   192.168.123.3   TCP     HTTPS > 47533 [RST] SEQ=1 WIN=0 LEN=0
67      12.497430       192.168.123.4   192.168.123.3   TCP     https > 47715 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 
MSS=1460 SACK_PERM=1 TSV=1863224474 TSER=73368246 WS=6

Basically whats happening here is a connection from the internet to the sonicwall. Sonicwall passes to 192.168.123.3 
and 192.168.123.3 proxies to 192.168.123.4.

My question is how do i find out what device is generating the ACK RST (line 66)?
I would be happy to send the complete log for further inspection.


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe