Wireshark-users: Re: [Wireshark-users] Https problem
From: Chris Hodgson <CHodgson@xxxxxxxxxxxxxxx>
Date: Mon, 28 Jun 2010 11:03:21 +0100

Thanks, I am hoping to capture traffic on the firewall level where is suspect the problem is.

 

To confirm the log on page does not appear, as in stays completely blank and the timer continues indicating it is loading- but never does.

 

I’m also seeing problems with other protocols; SNMP is intermittent to the NMS and ssh sessions to the device often drop. I notice the exact packet when it dropped and wireshark revealed ‘TCP previous segment lost’

 

I’m not sure how to identify a too large MTU, would this be configured on the interface on the firewall or connecting switch?

 

Regards,

Chris

 

From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Martin Visser
Sent: 27 June 2010 08:42
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Https problem

 

You might need to be a little clearer in your problem description. Are you saying the "login page does appear" or did you really mean does *not* appear?

 

If you are getting RST packets when your browser is trying to connect a new TCP session (this might be happening when your browser is being redirected by the first HTTP/HTTPS session) then it is likely this second site is being blocked by  firewall or some other similar device enforcing policy, possibly based on your IP address.

 

Lost segments are also an issue - they can occur because of congestion or even something like packets being sent with a too large MTU, and being dropped along the path back to you.


Regards, Martin

MartinVisser99@xxxxxxxxx

On Thu, Jun 24, 2010 at 11:23 PM, Chris Hodgson <chrishodgson416@xxxxxxxxxxxxxx> wrote:

Hi

 

I'm trying to troubleshoot an issue on an external network with regards to accessing the https Web GUI for network devices, basically the login page does appear after accepting the certificate error. I performed a capture and have seen several 'Lost segments' and reset packets when analysing the TCP errors. Any ideas what this means or where the problem could be?


___________________________________________________________________________
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