mtu issues in wireshark

Small packets are working like ping

TCP 3 way handshake is setting up

However when we move into setting TLS / https connection its failing. This can be the MTU is too big for the MTU on the path. The TCP window will scale up as the connection goes on.

Things to try:

tracert -d x.x.x.x

See what network devices you pass through and check the MTU on those. (if you can)

On the client:

ping –l 1490 -f 8.8.8.8

Reduce 1490 by 20 until you find a working value where the pings respond.

Remember the value when the ping command is working isn't the MTU but ICMP payload. This confuses a lot of people. MTU 1500 == ICMP payload 1472 (20 Bytes for IP and 8 Bytes for ICMP, I think). You can also check the MTU's on the path

PathMTU discovery is not reliable, will investigate MSS clamping, which can be enabled on your firewall / VPN endpoints.

CMD to check the MTU in windows

netsh int ipv4 show subinterface

CMD to set MTU in windows

netsh interface ipv4 set subinterface “Local Area Connection” mtu=1458 store=persistent

ASA should set MTU 1380 by default to account for IPsec tunnels

Palo needs to be configured

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113393-asa-troubleshoot-throughput-00.html#anc14

Wireshark

First we need to get a specific idea of the problem. Before we capture any data.

Define the problem

One app, multiple apps, everything ?
Slow or totally not working ? Any errors ?
When did the issue start ? Patches installed / updates ?
Intermittent or constant happens at peak times ?
Affects one or multiple people ?

Who, what, where, when and hopefully get to the why and resolution.

Capture close to the source of the data
If you can capture at both ends (make sure times are in sync NTP)

Problem with capturing from wireshark on the computer is that we are not seeing the data on the wire. winpcap sits in between the kernel and the NIC driver. So wireshark gets it before the NIC card. Ideally we want to see the data as it is on the wire. We can use a SPAN port for that.


Analyze - > expert info

Broadcasts storms are usually something broken, like a malfunctioning NIC and keeps firing out lots of traffic. Can be caused by no STP running and a loop has been created. Bad configuration like PIM running instead of PIM sparse mode.

Extract specific packets from a larger capture

Can mark packets with ctrl + M

Easier to use a display filter to get all packets we want (ip.addr == 192.168.1.100)

Then to file -> export specified packets

We can select the captured / displayed / marked from the radio buttons

Excessive requests and responses.

filter for arp (destination broadcast ff:ff:ff:ff:ff:ff:ff)
find the offending MAC addresses
map it to location on the network
shutdown the port or unplug the device

DNS
place the capture on the host trying to resolve DNS
Follow UDP steam

capture for tcp/udp port 53
Measure response time
expand DNS
find transaction ID
right click apply as filter selected

expand DNS
Response in: 14 (just double click it)
We will see Time: 0.04
Right click apply as a column (right click edit DNS TIME)

Capture filters
host 192.168.1.100 and host 192.168.2.200

Display filters

Find the syn packets
tcp.flags.syn == 1

Find dns packets
dns

Find dns packets with a string
dns contains "servername"

Find DNS lookups for a specific URL
dns.qry.name == "www.malware-url.com".

Find DNS queries that didn't return an answer

(!(dns.flags.rcode==0))&&(dns.flags.response==1)  

Find by string
Edit > Find Packet. Under "Find By:" select "string" and enter your search string
frame contains "string"
http contains "GET"

(http) and (frame contains "CONNECT")

(http contains CONNECT) or  (http contains GET)

Filter by IP

ip.addr==192.168.0.10

(ip.addr==192.168.0.10) or (ip.addr==192.168.0.50)

Filter by MAC

eth.addr ==xx

Show arp

arp

arp.duplicate-address-detected 

Search the payload for text

frame contains "string"

TCP len column is useful to see if the packet had data.

We need to send acks and get acks for packets we sent

TCP we don't ACK every packet we might ack every other packet.

Checking if a re-transmission is the same packet or not

IP header -> IP ID

Some retransmissions can be normal, lots usually indicate a problem like we sent request but never hear anything back so retransmit. Can indicate packet duplication (network loop) check the ip header -> ID

0.375 = 375 ms

TCP re transmission with double the number and eventually time out

1 3 6

expert info is wireshark trying to help

right click copy as a filter

coloring rules (add it)

You can add rules to your wireshark config to look out for things

Headers 

Ethernet (L2)14 bytes

IP4 (L3) 20 bytes

In the hex view each line has 16 bytes

You can count a bye in the hex b4 a8 (that's 2 bytes)

Standard MTU is usually 1500

Jumbo frame is 9000 (usually used for VMware/SAN)

tracing latency with wireshark

Run you capture, run your test

Open the capture, click on a packet.

right click on TCP in the bottom pane
-> protocol preferences -> calculate conversation timestamps

timestamps appears under TCP
right click -> Apply as column

sort highest number on top. Value is in seconds 1.0 is one second
0.02 is 2 ms.

FIN ACKs can be ignored as they are just closing connections

setting up packet captures on the cisco ASA

cap capin interface inside match ip host 192.168.1.50 host 200.100.100.100 circular-buffer

This will capture data in both directions
circular buffer means it will overwrite when buffer is full
Otherwise it will fill up and stop capturing
You can use clear cap capin to clear out the data

Will capture all the drops of any type
capture asp-drop type asp-drop all
sh cap asp-drop

You can also look in sh asp drop to see if they are increasing

The capture file can be saved and copied off the ASA:

https://100.100.100.200/capture/my-cap-name/pcap

To save the capture file
copy /pcap capture: disk0:

Copy the file off with CLI or ASDM file transfer.

There is also a way to connect ASDM directly to wireshark.