[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MTU and IPSec VPN's

Title: MTU and IPSec VPN's
This is definitely a compliance issue.  Per RFC 2401,
 
6.1.1 DF Bit
 
   In cases where a system (host or gateway) adds an encapsulating
   header (ESP tunnel or AH tunnel), it MUST support the option of
   copying the DF bit from the original packet to the encapsulating
   header (and processing ICMP PMTU messages).  This means that it MUST
   be possible to configure the system's treatment of the DF bit (set,
   clear, copy from encapsulated header) for each interface.  (See
   Appendix B for rationale.)
This is addressed in ios 12.2, not sure about redcreek.
 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ftdfipsc.htm
 
Mike Horn
-----Original Message-----
From: Christopher Gripp [mailto:cgripp@axcelerant.com]
Sent: Wednesday, June 13, 2001 2:07 PM
To: ipsec@lists.tislabs.com
Subject: MTU and IPSec VPN's

When using various vendor implementations of IPSec (RedCreek and Cisco to name a couple) we have run across an issue where the MTU must be changed on the PCs and/or servers for certain traffic (Outlook/Exchange, certain WWW pages) to flow through the VPN.

The problem is with large datagrams that need to be fragmented for the IPSec overhead to be added.

Lowering the MTU on the PC, for instance, to ~1492 alleviates these issues.

However the proposition of hacking the registry of 10,000 windows machines is at best ugly.

Is there something in the vendor implementation that can be changed?  Is it an RFC compliancy issue?  Or is this strictly a system configuration issue with the nodes involved.