Regards, Martin
MartinVisser99@xxxxxxxxx
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:42Subject: Re: [Wireshark-users] Https problem
To: Community support list for Wireshark
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
___________________________________________________________________________
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
- References:
- [Wireshark-users] Https problem
- From: Chris Hodgson
- Re: [Wireshark-users] Https problem
- From: Martin Visser
- Re: [Wireshark-users] Https problem
- From: Chris Hodgson
- [Wireshark-users] Https problem
- Prev by Date: Re: [Wireshark-users] Raw socket performance
- Next by Date: [Wireshark-users] : Idea for corrupted packet decoding
- Previous by thread: Re: [Wireshark-users] Https problem
- Next by thread: [Wireshark-users] Https problem
- Index(es):