Nothing special about this post, but I ran into an issue today and wanted to pass along the fix. I’ve noticed some of my posts that revolve around bug fixes are the most popular, so here goes. In this case, I had an IPSEC VPN tunnel between two Cisco ASA firewalls. I was getting ping times that were noticeably higher than normal, packet loss, and users complaining of application issues (more than normal!). The log message that I was receiving was “PMTU-D packet 1420 bytes greater than effective mtu 1386, dest_addr=192.168.1.1, src_address=192.168.2.2, prot=TCP“. IP addresses have been changed, but otherwise that was the same thing I was looking at. You can quickly notice the mention of the PMTU-D packet in the log message, which for me at least, is not something I normally see.
What is a PMTU-D Packet
Good question. We are going to look to RFC1191 for that one: https://www.ietf.org/rfc/rfc1191.txt A bit of a summary from the RFC is that a PMTU packet is a path MTU packet that attempts to determine the highest MTU setting of an internet path used for data transfer. There are two lines in this RFC that cleared it up the most for me when I was reading it:
It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the MTUs of each hop in the path.
In short, the PMTU packet tries to determine the lowest MTU value used in the path that data will be transferred. That way, the correct MTU size can be used and data will not need to be fragmented.
So back to that syslog message
Knowing what we know now, let’s read that log message again: “PMTU-D packet 1420 bytes greater than effective mtu 1386, dest_addr=192.168.1.1, src_address=192.168.2.2, prot=TCP“. In short, the ASA is sending traffic with an MTU of 1420 when the PMTU-D packet determined that 1386 was best.
How do we fix it?
I came across a few sites and supportforum cases mentioning ways to fix the issue. There were two that stuck out:
- Issue command “sysopt connection tcpmss 1300”
- Issue command “crypto ipsec df-bit clear outside”
Globally reduce the tcpmss to a level that would be acceptable for the PMTU responses that I was seeing. This was a global fix not specifically related to IPSEC VPN tunnels, so I skipped over this. I wanted to make a not nonetheless though.
This fix involved the IPSEC Do Not Fragment bit within IPSEC traffic. That immediately made me feel this might be the better solution for my issue. I ran the show command “show crypto ipsec df-bit outside” and the response was “df-bit outside copy”. When this bit is set to “copy” by default, the IPSEC packets are not allowed to be fragmented and are therefore dropped per the material I read earlier today. Sure seems like part of my issue! I found another Cisco VPN Doc located HERE that said “This command clears the Don’t Fragment (DF) bit from the encapsulated header. A DF bit is a bit within the IP header that determines whether the packet can be fragmented.” I chose this route for my fix since it would not globally adjust the MTU settings of this firewall. All of that being said, I entered the command “crypto ipsec df-bit clear-df outside” and the log message ceased immediately. My users did notice an increase in standard internet speed tests, etc through the IPSEC VPN tunnel at that time. For that specific issue, this command was my fix of choice. Word of caution though, the VPN tunnel did drop. It immediately re-established itself, but I wanted to call that out.
As always, toss any questions you have below.