My first thought is that when you send data through a VPN tunnel the processing of IPSec adds extra header information to the packet. The addition of extra headers will make a normal full size (or almost full size) packet too large to fit throgh the tunnel. Unless you have some additional information about the problem I believe that the additional header may explain their problem.
For TCP based traffic I have found a very effective solution with the ip tcp adjust-mss command which is configured on the LAN interface(s) of the router. This command will cause the end stations to negotiate a mss that is small enough that fragmentation will not be needed. It may take some experimentation to find the optimum value to set to eliminate fragmentation. (The amound of overhead will vary depending on some options within IPSec and whether you are doing GRE with IPSec or IPSec without GRE. I frequently use 1375 in environments using both GRE and IPSec and find that works for us.)
For non-TCP traffic I have seen a solution which uses a route map to identify the IPSec traffic and to turn off the DF bit. This allows the packet to be fragmented as it passes through the IPSec tunnel. I have not used this solution so I can not speak to details of how it works.
Also, if the host is sending the packet with the DF bit set, then route will respond with an ICMP messege to the sending host notifying the host to decrease the packet size. You may have a firewall in place blocking these ICMP messeges from the VPN device.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...