If you suspect the firewall then you really should be looking at firewall logs/counters at the same as you are doing your packet capture. If you see a request from one side of the firewall (say that login page connection, or an SNMP request) and not getting a response because of the firewall then it will be because of some rule or state issue. If you don't have logging turned on you should probably enable it. It *should* record the reason for drops if that is what is occuring.
While MTU can be hard configured, normally it is a problem only when you are changing media (from say Ethernet to Serial) or encapsulating in a VPN (say IPSec).
Regards, Martin
MartinVisser99@xxxxxxxxx
On Mon, Jun 28, 2010 at 8:03 PM, Chris Hodgson
<CHodgson@xxxxxxxxxxxxxxx> wrote:
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
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
___________________________________________________________________________
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
