We have two sites, a large Southern site and a small Northern site, that have a VPN between them defined on two Cisco PIX Firewalls. Over this VPN Shoretel IP phone traffic travels as well as all other network traffic. We recently switched the smaller Northern office to Bt Infinity (fiber) and all systems worked perfectly, that is, they worked perfectly until last week. Note, nothing change on that day.

Traffic coming down the VPN from Manchester works on all fronts, apart from for the telephone system. Our tame telephone engineers from Shoretel tell us this is all due to the telephone system packets having the DF (do not fragment) bit switched on on their traffic and a required payload of 1472, and with the IPSec overhead, 1472 will not fit down the lines MTU.

If I do a ping MTU test from our Southern office to our Northern office I get the following:

C:\>ping <NorthernOfficeServerIP> -f -l 1472

Pinging <NorthernOfficeServerIP> with 1472 bytes of data:
Reply from <OutsideInterfaceOfSourthernPixIP>: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

The VPN setup on the PIX is as follows:

sysopt connection permit-ipsec
crypto ipsec transform-set chevelle esp-des esp-md5-hmac
crypto map transam 1 ipsec-isakmp
crypto map transam 1 match address 101
crypto map transam 1 set peer <Peer IP> 
crypto map transam 1 set transform-set chevelle
crypto map transam interface outside
isakmp enable outside
isakmp key ******** address <Peer IP> netmask
isakmp keepalive 10
isakmp nat-traversal 20
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption des
isakmp policy 1 hash md5
isakmp policy 1 group 1
isakmp policy 1 lifetime 86400

The first thing I tried on the PIX was to get it to clear the DF flag on the packets as below:

pix(config)# crypto ipsec df-bit clear-df outside

Unfortunately, this just gives:

ERROR: unrecognized usage: [no] crypto ipsec { transform-set | security-association} ... Type help or '?' for a list of available commands.

But then our PIX firmware is quite venerable, the show ver gives me:

Cisco PIX Firewall Version 6.3(5)
Cisco PIX Device Manager Version 3.0(4)

Compiled on Thu 04-Aug-05 21:40 by morlee

chathampix up 14 hours 54 mins

Hardware:   PIX-506E, 32 MB RAM, CPU Pentium II 300 MHz
Flash E28F640J3 @ 0x300, 8MB
BIOS Flash AM29F400B @ 0xfffd8000, 32KB

I have tried altering the MTU size on the PIX, I've had the Outside interface at 1500, 1492 (8 bytes for PPP) and BTs recommendation of 1458 to try and mitigate the problem. The 56 byte overhead of the VPN means that the packets with the DF bit set at 1472 bytes will always be dropped by the VPN.

Does anyone know the equivalent command for "pix(config)# crypto ipsec df-bit clear-df outside" for a PIX with this firmware? Or do you have any other ideas??


The show crypto ipsec sa for the Northern PIX is below:

interface: outside
    Crypto map tag: transam, local addr. <NorthernOutsideInterfaceIP>

   local  ident (addr/mask/prot/port): (
   remote ident (addr/mask/prot/port): (
   current_peer: <SouthernOutsideInterfaceIP>:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 107592, #pkts encrypt: 107592, #pkts digest 107592
    #pkts decaps: 114302, #pkts decrypt: 114302, #pkts verify 114302
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 8, #recv errors 0

     local crypto endpt.: <NorthernOutsideInterfaceIP>, remote crypto endpt.: <SouthernOutsideInterfaceIP>
     path mtu 1492, ipsec overhead 56, media mtu 1492
     current outbound spi: 4ada0b77

     inbound esp sas:
      spi: 0xe7c2815(243017749)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 1, crypto map: transam
        sa timing: remaining key lifetime (k/sec): (4516828/21982)
        IV size: 8 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x4ada0b77(1255803767)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2, crypto map: transam
        sa timing: remaining key lifetime (k/sec): (4598687/21980)
        IV size: 8 bytes
        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:

And the MTU for the Southern PIX and Northern PIX is:

mtu outside 1500
mtu inside 1500

The MTU is automatically set less the 8 bytes for PPP by the PIX I believe.

  • very good question, I am interested in someone with a nicely authoritative answer replying. I can tell you in dealing with iSCSI replication we ended up moving the MTU down as far as 1350 and saw improvements. Jun 7, 2012 at 12:57
  • What do the interface MTUs look like on the remote PIX? And is any path MTU discovery being shown for the VPN tunnel in show crypto ipsec sa? Force-clearing the DF bit is a rather hackish workaround, and may end up affecting performance. While it'd be preferable to avoid using that, if it ends up being necessary you'll need to upgrade; that feature was added in 7.0. Jun 7, 2012 at 16:19
  • good point on path-mtu-discovery, I enable this on most of my Juniper SRX devices Jun 7, 2012 at 16:32
  • I agree, the DF flag is turned on by the Shoretel switch for QOS, and forcing that flag off could lead to all sorts of other problems. I will update the post with the information you requested. Jun 8, 2012 at 8:46
  • @MagicalArmchair, are you still having a problem with this? Jul 7, 2012 at 8:29

1 Answer 1


For traffic exceeding the outbound interface MTU after IPSec overhead is added there are several "fixes" PIX/ASA side.

Change the MTU on the PIX/ASA to a lower number (1380 is common) forcing sending stations to react -- not always in the desired manner.

Change the MSS (TCP only, not useful for UDP)

Let the PIX/ASA Fragment.

In the event that df-bit is set in the inner IP header and fragmentation is required to fit through an IPSec tunnel, permitting the PIX/ASA to clear the df-bit is also an option.

Note that clearing the df-bit requires PIX/ASA OS 7.0 and greater. The "venerable" PIX 6.3(5) will not cut it.

A more important question is why your VoIP traffic is tripping the MTU at all? All VoIP codecs I am aware of (including the very common G.711 and G.729) produce per "packet" codec payloads of less than 160 bytes. Add in RTP, UDP, and IP overhead -- roughly 40 bytes total and a L2 payload size of no larger 200 bytes results. Add in another 56 bytes for IPSec ESP and it is still nowhere near typical Ethernet interface MTU's.

What are your VoIP admins pushing over the wire that requires a 1472 byte L2 payload?


Voice Over IP - Per Call Bandwidth Consumption

Tech Info - VoIP CODECs

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .