How to troubleshoot MTU related issues using Wireshark.

Security Gateway Articles and How to's
Post Reply
Anton
Posts: 24
Joined: 16 Jun 2016, 18:50
Location: Clavister HQ - Örnsköldsvik

How to troubleshoot MTU related issues using Wireshark.

Post by Anton » 09 Feb 2018, 12:59

This How-to applies to:
  • Clavister Security Gateway 12.x. and Wireshark 2.4.3+
Table of contents:
  • • Objectives with this article.
    • Configure Wireshark to show the needed columns.
    • An explanation of Sequence numbers, MSS and MTU.
    • Example of Packet Captures that show potential MTU related issues.
    • How to configure the Clavister Firewall to get around the issue.
Objectives with this article:
This article will describe the basics of troubleshooting TCP MTU/MSS related issues it will also describe how to configure Wireshark to show the information we need in order to troubleshoot. We will discuss how you can determine that the Network issue is related to MTU/MSS. Based on the Sequence number, Next Sequence number and the Acknowledgement number in a packet capture.

The characteristics for a MTU/MSS related issue can many things but often it results in dropped connections and/or bad network performance.

All examples packet captures can be found here:
MTU.rar
(319.5 KiB) Downloaded 398 times
Configure Wireshark to show the information we need:
Wireshark does not show Sequence number, Next Sequence number and the Acknowledgement number per default as columns. First of all we need to add them, the simplest way to do that is start a packet capture and look for a TCP packet as show below:
Wireshark1.png
Wireshark1.png (68.08 KiB) Viewed 732 times
Note that Next sequence number has brackets [] around it, that is because this is a “made up” number by Wireshark that is based on the Packet length and the sequence numbers. We will discuss how that works later.

To apply the parameters as columns you just have to Right Click on the field and chose “Apply as column” do that for Sequence number, Next Sequence number and the Acknowledgement number:
Wireshark2.png
Wireshark2.png (98.68 KiB) Viewed 732 times
You should now have the following columns in Wireshark:
Wireshark3.png
Wireshark3.png (24.45 KiB) Viewed 732 times
I recommend that you have them in the same order as pictures shows since it will be easier to read, you can also rename the columns to something shorter for example SEQ, Next SEQ and ACK to make it even easier to read.

There is one thing more I usually change and that is to disable “Relative sequence numbers” in Wireshark for the TCP protocol. This is totally up to the user and how you prefer to read it, by disabling it you will see the real/absolute SEQ, Next SEQ and ACK numbers and that can be cumbersome to read. By having it enabled the relative SEQ and ACK numbers will be shown, meaning that all SEQ and ACK numbers always start at 0 for the first packet seen in each conversation. You can read more about the setting at this link:https://wiki.wireshark.org/TCP_Relative ... ce_Numbers

To make it easier to read we will have the setting enabled in this How To.

An explanation of Sequence numbers, MSS and MTU:

We will now try to explain how SEQ numbers MSS and MTU is directly related to each other and we will also look at an example from when it works. We will also look briefly on Selective Acknowledgement (SACK) which also can be good to know when troubleshooting TCP problems.

  • What is MTU?

MTU stands for Maximum transmission unit meaning the size on the largest network layer protocol data unit that can be communicated in a single network transaction. Depending on if you included the Ethernet frame or not the standard is 1500 bytes (Wireshark will show 1514 bytes as length since the Ethernet frame is included) for a TCP packet that would be the IP Header (20 bytes) + TCP Header (20 bytes) + TCP segment length (1460 bytes).

  • What is TCP MSS?

MSS stands for Maximum Segment Size which specifies the largest amount of data that a device can receive in a single TCP segment. The TCP MSS does not include the IP header or the TCP header. MSS is negotiated in the three way handshake between the client and the server at the beginning of a TCP connection.

  • What is Sequence numbers?

Sequence number is used to keep track of the data sent in a TCP communication. Both the server and the client will have different SEQ numbers and the SEQ numbers will be based on the length of the TCP segment in the packet. If you have “Relative sequence numbers” enabled in Wireshark each conversation will always start at 0. But in real the SEQ number the conversation could start with any number between 0 and 4,294,967,295.

Working example (The packets are captured on the client):
TCP.png
TCP.png (41.13 KiB) Viewed 732 times
Packet #1
Client sends SYN to server, since this is the first packet in the conversation the relative Sequence number will be 0. You can also see that the client has the MSS set to 1460. The Acknowledgement number is set to 0 since there is no data to ACK.

Packet #2
Server sends SYN/ACK back to the client; since this is the first packet the server sends it will also have the relative Sequence number of 0. The MSS is also set 1460 by the server, meaning that MSS that will be use in this conversation is 1460 bytes. (The MSS used will be the lowest MSS set by either side) The Acknowledgement number is 1 to indicate the receipt of the clients SYN in packet #1.

Packet #3
Client now send the ACK to complete the three way handshake. The Sequence number is increased by one since the client previously sent a SYN packet. The Acknowledgement number is also increased by one to indicate that the client has received the SYN from the server.

Packet #4
The client now sends the HTTP GET, this is the first packet that actually contains any payload. The Sequence number will stay at one since the client has not transmitted any data since the last packet in the stream. The Acknowledgement number will also stay at one since the client has not received any data yet from the server.

The interesting thing here is the “Next Sequence number” which is set to 753 and why is that? Next sequence number is based on the TCP segment length and the Sequence number of the packet. In this case the payload of the TCP packet is 752 bytes (806 – IP header(20) – TCP Header(20) – Ethernet frame(14) = 752)

This is also visible in Wireshark if you look at the TCP Header:
TCP2.png
TCP2.png (29.38 KiB) Viewed 732 times
The Next sequence number will therefore be Sequence number (1) + TCP segment length (752) = 753. We now know that next packet that the client will send will have the relative Sequence number of 753.

Packet #5
The server now ACKs the HTTP GET, still using the Sequence number 1 since it has not transmitted any payload yet but it has increased the Acknowledgment number to 753, meaning that the server has received 753 bytes of data so far.

Packet #6
The server now transmits the HTTP OK response to the HTTP GET sent in Packet #4. This packet now has the Sequence number of 1 and it still has the same Acknowledgement number 753 since the client has not sent any more data so there is nothing new to Acknowledge.

The interesting thing here is that the packet has the Next Sequence number of 959, this means that the next packet the server will send is going to have the Sequence number 959. As mentioned earlier (packet 4) we know this or rather Wireshark knows this because Next Sequence Number is calculated from the current Sequence number + the TCP segment length in this case 1 + 958 = 959.

You may also notice that this packet has the PSH flag set. The PSH flag in the TCP header informs the receiving host that the data should be pushed up to the receiving application immediately. The PSH flag is beyond the scope of this article and can be ignored for now.

Packet #7 - Packet #10
The server now starts to send the actual HTTP data to the client. The Acknowledgment numbers will still be 753 on all packets that the server sends since the client has not sent any more data so there is nothing new to Acknowledge.

The 7th packet has the sequence number 959 as we previously calculated in packet #6. The 7th packet has the TCP length 1460 so this means that the next packet will have Sequence Number 2419. 1460 is the MSS of this connection; this was agreed upon in the three way handshake.

Same goes for packet #8 and #9 both has 1460 as TCP length meaning that the Sequence number will increase by 1460 after every packet. Simply illustrated:

Code: Select all

Packet 7 (SEQ 959) - > Packet 8 (SEQ 2419) -> Packet 9 (SEQ 3879) -> Packet 10 (SEQ 5339)
Packet number 10 is the last packet that the server sends in this example this packet has the TCP length 816 meaning next packet that the server sends will have the sequence number 6155.

Packet #11
The Client now Acknowledge the packet that the server has sent, the sequence number of this packet has now increased to 753 as we mentioned in Packet #4. The Acknowledgment Number has now increased to 6155 this means that the client has received 6155 bytes of data from the server. This also means that the client has received all data between 0 and 6155 bytes.

Summary:
As you can see in this example nothing goes wrong both server and client receive all packets. We can also see that the sequence number is directly connected to the TCP length, after each packet the sequence number is increased by the TCP length of the packet. Both sides of the connection have their own unique SEQ number and the MSS is agreed upon in the three-way handshake.

How can I see that the issue is related to MSS/MTU:

We will now go through an example where it doesn’t work and try to analyze why the connection has issues. We will also have a look at Selective Acknowledgement (SACK) that sometimes can help you to trouble shoot MSS/MTU related issues.

(Capture taken from the WAN interface of the Clavister and this is a HTTPS connection.)
wancap.png
wancap.png (28.05 KiB) Viewed 732 times
Packet #1 - #3

Same as in the previous example, Three-way handshake is completed. The agreed MSS is 1460 bytes and also SACK is permitted by the server and the client (SACK_PERM=1). SACK stands for Selective Acknowledgements; if packets are lost the data receiver can inform the sender by sending a Duplicate ACK and appending a TCP option containing a range of noncontiguous data received. This allows for more efficient TCP transmission in packet loss scenarios. The data sender then only needs to retransmit the packets that the receiver did not get, instead of all packets.

Packet #4
The client now sends the Client Hello packet initiating the TLS handshake. The ACK number is still 1 since there is nothing new to Acknowledge and Next SEQ will be 132 since the packet length is 131 bytes. The Client now waits for the Server hello.

Packet #5
Now something goes wrong, the server sends a packet with Sequence number 2921, why? The sequence number should be 1 since the server has not transmitted any data yet.

Since we know that the sequence number should be 1 on this packet we can also calculate that we are missing 2920 bytes of data in this conversation (2921 - 1 = 2920).

Next packet that the server sends will have sequence number 3674.

Packet #6
And here is where SACK comes into play, client now sends the Duplicate ACK to tell the server “Hey, I did not get all packets but I got the data between SEQ number 2921 and 3674”.

Sequence number will still be 132 as we stated in Packet #4 but the Acknowledgment number will not increase since we have not received data between SEQ number 1 and 2921.

The Acknowledgment for the data between 2921 and 3674 will now instead be in the SACK option part of the TCP packet:
SACK.png
SACK.png (37.52 KiB) Viewed 732 times
This will tell the server to retransmit the data between 1 - 2921 but not the data between 2921 – 3674

Packet #7 - #9
The server now sends a RST to the client after 10 seconds and closes the connection.

Summary:
Here we have an example of when something goes wrong, it seems that we are missing some data. The client sends the “Client Hello” to initiate the TLS handshake but it never receives the response. Judging from Sequence numbers we are missing the data between SEQ 1 and SEQ 2921 so 2920 bytes of data is lost (2921 – 1 = 2920). Another thing that we can assume based on the MSS agreed upon in the three-way handshake (1460) is that the data we lost is most likely two “full size” TCP segments 2920/2 = 1460.

The conclusion we can draw from this is that most likely the MTU is lowered somewhere along the way causing the packets to be dropped. This is only an assumption since we cannot say for sure that this is the case since we have not seen the packet captures on the server side. But all evidence points towards that at least.

Slow internet speed:

Even though packets are dropped TCP should be able to “solve” or workaround the problem by retransmitting data in smaller packets, here is an example on how it works:
retrans.png
retrans.png (38.45 KiB) Viewed 732 times
Packet #1 - #3
Three-way handshake completed, the agreed MSS is 1460.

Packet #4
Client now sends the HTTP GET, Next SEQ will be 1440 since the TCP length is 1439. The client is now waiting for the server to acknowledge the packet.

Packet #5
Client now retransmits the packet since there was no ACK sent back from the server for 310ms. Next SEQ is still 1440 since this is a retransmission of Packet #4.

Packet #6
Client waits another 600ms and tries to retransmit the packet once again. Next SEQ is still 1440.

Packet #7
Still there is no answer from the server after almost 2 seconds. Client now retransmits the packet again but this time the packet is smaller, the packet has the TCP length 536 bytes. Why 536 bytes?

Ok so first 536 is only the TCP segment length, if we add the IP header and the TCP header we get 536 + 20 + 20 = 576 (Wireshark will say 590 since the Ethernet frame is included) which is the smallest datagram size that any host must be prepared to accept.

The next SEQ number will now be 537 instead of 1440 since the client will retransmit the packet in smaller chunks.

Packet #8
Now we finally get an answer from the server, the server now Acknowledge Packet #7. Acknowledgement number is now 537 since the server has not received the data between SEQ 537 and SEQ 1440.

Packet #9
The Client now retransmits another packet that contains 536 bytes of data. This packet now has Next SEQ 1073.

Packet #10
Client now retransmits the last data in a 367 bytes TCP segment. The client has now spread out the HTTP Get over three different packets, packet #7, packet #9 and packet #10. The total TCP data is still 1439 bytes (536 + 536 + 367 = 1439).

Packet #11 and Packet #12
The server now Acknowledge the two last packets sent by the server. All packets sent by the client has now arrived on the server.

Summary:
Even though there is a MTU/MSS problem in this network the connection was not dropped. However the packets were transmitted in a very inefficient way. By retransmitting the packet in smaller chunks we have increased the round trip time by about 2 seconds we have also doubled the number of packets that is sent in this connection.

How to configure the Clavister to avoid these problems:

There are basically three things you can do in order to improve the situation.
  • 1. Modify the MTU on the involved interfaces.
    2. Modify the TCP MSS Max advanced setting.
    3. Enable Path MTU Discovery on the service.
How do I know what to do? This is very situational and it depends on the Network topology. But we will try to break it down for you.

Modify the MTU on the involved interfaces.

First of what should we change the MTU to and which interface should we change it on? The easiest way to figure this out is with ping and the length parameter. Here is an example from Windows CMD:

Code: Select all

ping 8.8.8.8 –l 1372
This will send an ICMP packet that contains 1372 bytes of data to 8.8.8.8. Let’s say that 1372 is the largest amount of data that you can send and still get an answer, this means that the MTU is 1400. Remember we need to add the IP header and now we also need to add the ICMP header, 1372 bytes + 20 bytes + 8 bytes = 1400 bytes.

Now on which interface should we change the MTU, let’s say that we have a simple setup like this:

Code: Select all

Clients ---(LAN)Firewall(WAN)--- Internet.
TCP MSS will automatically be “clamped” to the lowest MTU of the involved interfaces. If you have two interfaces Lan(1400 MTU) and Wan(1500 MTU) the TCP MSS used will be 1360. It will be up to the administrator to decide on which interface you want to modify the MTU. Let’s say that we also have a DMZ interface where internal resources resides that the LAN clients are using. If so it might not be preferable to lower the MTU on the Lan interface since we will then also use the lower MSS when communicating between the LAN and DMZ interface.

Modify the TCP MSS Max advanced setting.

As mentioned changing the MTU will affect all traffic on that traffic including UDP traffic. Sometimes it could be beneficial to just change the TCP MSS Max setting. This will only affect TCP traffic but it’s however a global setting. Meaning, all interfaces will be affected (Excluding VPN interfaces). As mentioned this is very situational, there could be situations where only TCP traffic are affected.

The TCP MSS Max setting can be found under System -> Advanced Settings -> TCP Settings in the WebUI. Default value is 1460 bytes and as mentioned this is a global setting and will affect all TCP traffic passing through the firewall.
MSSMAX.png
MSSMAX.png (66.74 KiB) Viewed 732 times
This cannot be tested with ICMP since it only changes the MSS of TCP, in this case you have to look at packet captures. For example decrease the value by 10 to 1450 and try to visit any HTTP or HTTPS site, can a full size segment reach the server or can the server send a full size segment back. If not decrees TCP MSS Max even more.

Enable Path MTU Discovery on the service.

This will enable the possibility for the Clients to modify the MTU them self without the need for an administrator to do anything other than activating it on the firewall. But it does however require that all nodes between the Client and the Server to support Path MTU Discovery and that is not always the case.

PMTUD works by using the Don’t Fragment (DF) bit of the IP header and a subcode of the ICMP Destination Unreachable message, “Fragmentation Needed”.

Here is an example on how it works:
PMTUD.png
PMTUD.png (61.09 KiB) Viewed 732 times
  • 1. Client sends a 1500 byte TCP packet.
    2. Router sends a ICMP error “Fragment to 1300 bytes”
    3. Client now sends a 1300 byte TCP fragment.
    4. Client then sends the rest of 1500 bytes of data, 200 bytes.
    5. Server ACKs the data.
    6. Client now send 1300 bytes of data.
    7. Serer ACKs the data.
Now the Path MTU has been learned and the client can cache this value and future data for the destination is sent with the appropriate size.

In the Clavister Path MTU Discovery is enabled on a Service base, it’s not a “global” setting that affect the whole system. In order to activate it we need to enable two settings on the service:
PMTUD22.png
PMTUD22.png (54.97 KiB) Viewed 699 times
  • 1. “Forward ICMP Errors” – Allows ICMP error for active connections to be forwarded through the system.
    2. “Enable IPv4 Path MTU Discovery” – Allows communicating endpoints to negotiate optimal packet sizes. This prevents fragmentation by network equipment between the endpoints. Path MTU Discovery relies on ICMP message forwarding so ICMP forwarding must also be enabled.

Anton
Posts: 24
Joined: 16 Jun 2016, 18:50
Location: Clavister HQ - Örnsköldsvik

Re: How to troubleshoot MTU related issues using Wireshark.

Post by Anton » 12 Feb 2018, 14:28

How about UDP and fragmentation?

UDP works in a different way than TCP, there is no SEQ numbers or ACK numbers. A UDP packet can only be split on the IP layer. This is called Fragmentation, a UDP packet will be fragmented if it’s bigger than the Maximum transmission unit (Note that this can happen in TCP traffic as well).

In this example we have a Client that is trying to authenticate via RADIUS over UDP port 1812. The Access-Request sent by the Client is bigger than the MTU so it must be fragmented in order to reach the Server. I have added three columns to makes this a bit clearer. First is “Fragment Offset”, the fragment offset telling which order the receiver should reassemble the packet. Second is “Identification” which tells the receiver which fragments that belong with each other. Third is the “More Fragments” flag, if the “More fragments” flag is set in the IP header then we know that there will be more fragments with the same Identification.

To apply them as columns open the Internet Protocol filed on any packet. Right click on the following parameters and chose “Apply as columns”:
columnsIP.png
columnsIP.png (27.1 KiB) Viewed 696 times
Example packet capture that contains Fragmentation:
frag.png
frag.png (28.54 KiB) Viewed 696 times
fragment.rar
(725 Bytes) Downloaded 408 times
Packet #1
The first fragment sent by the client trying to authenticate, we can say that this is the first fragment since it has the Fragment Offset set to 0. We also know that there will be more fragments that will follow since the “More Fragments” flag is set. This packet contains 1480 bytes of UDP data (including the UDP header 8 bytes), 1514 bytes – Ethernet frame (14 bytes) – IP Header (20 bytes). Since we know that UDP data is 1480 bytes we also now that the next fragment will have the fragment offset equal to 1480, 0 bytes + 1480 bytes.
This packet has the Identification 0x72f7.

Packet #2
This is the second fragment that is sent by the client, we now that since the fragment offset equals to 1480 as stated in Packet #1 and since it has the same Identification as Packet #1 (0x72f7). This packet also contains 1480 bytes of UDP data and it also has the “More Fragments” flag set in the IP header. Meaning that there will be more fragments.

Packet #3
This is the last fragment sent by the Client. We can say that it’s the last since it does not have the “More fragments” flag set and since it has the same Identification as Packet #1 and #2. This packet contains 1095 bytes of UDP data, 1129 bytes – Ethernet frame (14 bytes) – IP header (20 bytes).
We now know that original packet contained 4047 bytes of data, (1480 + 1480 + 1095) – UDP Header (8 Bytes).

Packet #4
The server is able to reassemble the packet and sends Access-Accept, authenticating the client.

Post Reply