Useful Wireshark filter for analysis of SSL Traffic.
ssl.handshake.type == 1
ssl.handshake.type == 2
ssl.handshake.type == 4
ssl.handshake.type == 11
ssl.handshake.type == 13
ssl.handshake.type == 14
Note: “ServerHellpDone” means full-handshake TLS session.
I found the below from Wiki. All these SSL handshake message types ( I had included some of them in the above) can be used as wireshark filter as well.
EncryptedExtensions (TLS 1.3 only)
More and more deployment require more secure mechnism e.g.Perfect Forward Secrecy. To provide PFS, cipher suite need to leverage Elliptic-curve Diffie–Hellman (ECDH) or Ephemeral Diffie-Hellman during the key exchange. In those cases, we can’t use private key to de-encrypt the traffic.
Here I show most common used in my daily life here for your reference. I normally perform a packet based on vSwitch port ID or DV filter (NSX DFW)
To do that, I firstly need to find the vSwitch port ID and DV filter ID on ESXi host so that I can refer them in your packet capture. I normally use “summarize-dvfilter” CLI to find the requested information.
I list all available filter options here for your reference:
The Ethernet source MAC address. –dstmac
The Ethernet destination MAC address. –mac
The Ethernet MAC address(src or dst). –ethtype
The Ethernet type. HEX format. –vlan
The Ethernet VLAN ID. –srcip
The source IP address. –dstip
The destination IP address. –ip
The IP address(src or dst). –proto 0x
The IP protocol. –srcport
The TCP source port. –dstport
The TCP destination port. –tcpport
The TCP port(src or dst). –vxlan
The vxlan id of flow.
Vyatta 5600 provides Tshark as the packet capture tool. To capture your interested traffic and remove unnessary nosiy traffic, you need to use the capture filter when you perform the packet capture. Here I show you a few real world example for tshark capture filter, which hope can save you a bit of time.
In NSX 6.1.4, I tried to perform packet capture to analysis the end to end connectivity restoration during Edge HA failover. But I only can capture packet for a single vNic at one time. Somebody may say this can be worked around by performing another packet capture on another vNIC in ESXi hosts by use of “pktcap-uw”. However,”pktcap-uw” can only capture uni-directional traffic in ESXi hosts. This behavior will bring extra challenge for packet analysis.
Luckily in the new version of NSX 6.2.4, it looks like that we can capture on different vNIC at the same time by run multiple times of “debug packet capture interface vNIC” like the below:
Symptom: customer complains about slow response to SSH server running on one Centos box
Method: perform packet capture on the SSH server.
Finding: DNS query fails during establishing SSH session
When folllow the TCP session for SSH login packet caoture, see the below:
During packet 17 and 24, there is about 10 seconds gap.
Go back to the whole packet capture, find the below between packet 17 and 24. We can see multiple DNS query but no response
After checking the Linux/Centos doc, we found that SSH server by default will check the DNS for the source IP of ssh client before the SSH session can be established. The DNS query failure introuduces the 10seconds delay before the SSH server responses to the client
Symptom: virtual desktop end users complain the performance issue: the end users can access their AD home directory quickly at the first time. After a little while, they have to wait for over 30 seconds before they can reach their home directory.
Method: perform packet capture on one of end users and successfully capture the packet when the user is experiencing the issue.
Finding in the packet analysis:
Root Cause: By default, the timeout setting of session entry in firewall session table for most of stateful firewalls are 30 mins. If there is not any packet passing through the firewall for that session, the session will be timed out and removed from the session table by the firewall.
In our case, a new TCP session entries will be established in the firewall session table when the virtual desktop users try to access the home directory at the first time. Then the end users often doesn’t use the home directory any more. After half hour, the idle session entry will be removed from the firewall. But from end user application point of view, the session is still alive and they try to use this alive session to access their home directory again. (Remember the user desktop won’t perform so called a three-way handshake to establish a new TCP session as the application layer still think the TCP session is still alive). When the application traffic hits the firewall. the firewall dropped the packet as the application traffic is not TCP SYN packet. (Unfortunately, the Juniper SRX firewall drops the packets silently!!! No logging or alert). So the end user desktop has to follow up the standard TCP re-transimission mechanism to re-transmit the packet. It takes 12 seconds in our case before the end user device gives up and try to initiate a new TCP session.
We have 2 ways to fix the issue:
1. Infrastructure point of view:
Change the default session timeout setting on the firewall to a bit of bigger than the application layer session timeout;
2. Application point of view:
Make the application to periodically (e.g. 20mins) send TCP keep-alive packet before the session entry is removed from the firewall session table;
Both of the above fixes will bring a bit of overhead on the firewall, especially from session table size point of view.
The NetScaler has two separate mechanisms available to capture the network traffic through the appliance: nstrace.sh and nstcpdump.sh. NStrace records network packets trace in the native NetScaler trace format, which provides specific NIC device information including device number and whether the packet was transmitted or received. However, the current stable version of wireshark can’t read the packet capture.
After I did a bit of research, I found the development version of Wireshark can open nstrace packet capture properly. Below shows the wireshark developement version which i use to open the standard nstrace packet capture.
In addition, nstrace CLI do provide the option to perform a standard tcpdump packet capture. The captured packets can be read by wireshark stable release.
When you analyse the packet capture in wireshark, you sometimes see the similar/nearly same packets more than 1 time. It is maybe due to duplicate packet or TCP retransimission. If it is TCP retransmission, you have to pay more attention on it.
The difference between duplicate packet and TCP restransmission is IP ID. For duplicate packets, IP ID of two packets is same besides the TCP sequence number is same. (Why you can see the duplicate packets in the capture is not in the scope of this discussion. If you have interest, please google it. 🙂
Duplicate Packet example (same IP ID and same TCP sequence number)
TCP Original packet
TCP retransmission packet
Same TCP sequence number (2171548184）but different IP ID （frame 553 ID is 48058 and frame 578 ID is 48083) for orgianl packet and retransmission packet.