Welcome to the last TCP portion of our course, TCP Issues with MTU and MSS.
These issues can cause you some serious heartache for days.
But don't worry because after this section you'll be
well‑armed against these type of issues.
MTU stands for maximum transmission unit,
and MTU is responsible for forcing fragmentation
across mediums that exceed the MTU.
Generally MTUs run at the default of 1500 bytes.
MSS stands for maximum segment size.
MSS is responsible for the maximum amount of data that
could be transmitted across a medium.
Now I say actual data because all MSS cares about is actual user data,
nothing with the IP header.
MSS works in parity with MTU,
and generally it's 40 bytes smaller than the maximum MTU.
And I say generally because this is where our problems start.
Let's drop to a diagram to help explain this subject in much further detail.
In this scenario, we have two businesses connected over a point‑to‑point,
long‑range wireless system.
Each radio is connected to a router.
The network on the left has the IP scope of 192.168.1.0/24,
while the network on the right hosting the web server
has the IP scope of 192.168.2.0/24.
The radios are successfully set up and configured as
they both have excellent signal.
And furthermore, both networks can pin each other.
There is a problem though.
Even though ICMP is working, no other traffic is successfully connecting.
In fact, when the 192.168.1.0/24 network attempts to access the web server,
it's timing out.
The issue here is really tricky as running Wireshark
really wouldn't reveal much information,
and here's why.
Both routers are running a 1500 MTU.
Remember, that's the standard.
But the radios are using a 1300 MTU.
So the traffic passes successfully to the router,
but the packets are too large for the radio,
which in turn drops the data.
Now you may be saying to yourself, why is ICMP working?
And the simple answer is it's smaller than the 1260 MSS.
Remember, the MSS is generally the MTU minus 40 bytes.
Now I say generally because this isn't always the case.
Can you imagine adding a VPN with all of its overhead
to the radio network like this?
Well, I had this very experience.
I was once installing a site‑to‑site VPN for a police
department to connect back to 911.
The police department utilized a local ISP who was
running their internet service over a WISP.
After some time,
I successfully established the site‑to‑site VPN and
could ping both ends of the tunnel, but I couldn't pass any data.
After talking with our ISP,
I discovered their radio network utilized a 1300‑byte MTU.
To resolve this, I had to calculate the size of my overall MTU.
To accomplish this,
I utilized the ping command of ping ‑f ‑l and then my test
MTU size and then my destination IP.
This allowed me to simulate larger data packages across the connection.
I then began to ping the destination.
After every successful ping,
I would increment my MTU by 100 bytes until I received the error,
packet needs to be fragmented but DF set.
Finally, I found my MTU, and it was around 1240 bytes.
Taking this into consideration,
I had to manually set my MSS to 1180 bytes, and then my
traffic successful began to pass.
Now you may be wondering why I had to adjust the MSS past the 40‑byte norm.
The issue was even though the traffic would operate with a minus 40 MSS,
it was extremely sluggish over the VPN network. And lowering the MSS
really helped on the performance of the web pages.
Now you may be thinking holy cow, that connection has to fragment
a ton of packets, and you're right. It does.
But sometimes you have to adapt and overcome.
And as a side note,
I have seen this issue present itself on non‑radio VPN networks.
So if you're having problems passing traffic and you're sure
it's not a firewall issue and ICMP works, I would investigate an MTU/MSS issue.