8.3 L2TP/NAT-T MTU issues, anyone?

Unanswered Question
Jul 26th, 2010

Trying to work the last kinks out of 8.3 L2TP, I discovered that sometime between 7.2 series

and 8.3, the ASA became unable to ride over an intermediate link with a low MTU.  Where

we see this is on certain cable providers (read: Comcast) who set an MTU of 576 via

their DHCP server, which the household NAT router may honor, or may be broken and

not honor.  If it does honor it, you get problems.

Here's the setup:

<ASA Eth0/3.1 MTU1500>(Internet)<MTU???<Comcast cable router>MTU 576><MTU 576<Linux NAT>MTU1500><MTU1500 <IPSEC client>

This works reliably on another ASA is running 7.2(3).  On my test unit running 8.3(1.6) the connection will drop any packets larger than 498 bytes original unencrypted length (header included) and this behavior happens with both Strongswan and native Windows clients.

If you ignore the cable provider's MTU, and set it to 1500 on the Linux NAT, then 8.3(1.6) is all happy again.

I've already tried playing with tcpmss to no avail.

Can anyone think of any other knobs to twist to see if there's a different default in 8.3?  Anyone seen a bug ID for this?

(Full disclosure, the 8.3(1.6) box's crypto interface is a dot1q subinterface, while the 7.2(3) box is untagged, but I doubt that's the issue.)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
b.julin Tue, 07/27/2010 - 06:58

Nevermind.  Turned out to be an uppity packet shaper was in the path to the 8.3(1.6) box and I didn't realize it.


This Discussion