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 255.255.255.0
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??
UPDATE:
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): (192.168.16.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
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.
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?
Ref:
Voice Over IP - Per Call Bandwidth Consumption
Tech Info - VoIP CODECs