[<Tim.Poth@xxxxxxxxxxx>]

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@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxxxx>
To: wireshark-users@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Chris Arnold
Sent: Monday, February 11, 2013 4:47 PM
To: wireshark-users@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe