Re: Https problem

[Chris Hodgson <CHodgson () advaoptical com>]

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 () wireshark org [mailto:wireshark-users-bounces () wireshark org] 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 () gmail com<mailto:MartinVisser99 () gmail com>

On Thu, Jun 24, 2010 at 11:23 PM, Chris Hodgson <chrishodgson416 () googlemail com<mailto:chrishodgson416 () googlemail 
com>> 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 () wireshark org<mailto: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<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