I have the following situation: two sites are connected through an IP MPLS VPN. I want the two sites to be connected via an ipsec over gre tunnel. My problem is that I want the mtu to be 1500 B, in a transparent way to the applications. The SP give an mtu of 1536 B, so the part with the MPLS is not relevant. I am wondering how can the IOS 12.3(16) of my 3745 be configured so the final mtu will be 1500 B, like the physical interface. I know that the gre tunnel can be configured with the "ip mtu 1500", so it can fragment and then reassemble the packets at the other end. What I need to know is how the combination of ipsec with gre will handle the traffic. Do I need to setup something on the ipsec to do the same thing like the gre with the packets? Or maybe on the gre tunnel? (The fact is that I don't know when the gre is doing the disassembling and reassembling: before the traffic is passed to the ipsec or after the traffic is encrypted by ipsec - because the resulting mtu may differ)
You cannot set the mtu on the IPSec tunnel. What you can do is to set/unset the df-bit in the Crypto header. Reaching 1500 end-to-end with fragmentation should be no problem and may need no explicit config. However with DF-Bit set , you can probably unset the DF-bit in the IPSec header using crypto ipsec df-bit clear.
Fragmentation is performed as a packet is set to leave an interface. Assuming you are using IPSec to encrypt the GRE tunnel itself, first the packet is routed to the GRE interface. If you set the GRE MTUs to 1500, the tunnel will accept a full size packet. GRE will encapsulate the packet adding 24 bytes of overhead creating a 1524 byte packet. (Assuming we are not using packet pre-fragmentation) IPSec would then encapsulate the packet adding another 50 bytes of header and footer data taking the total to 1574. Since this is bigger than the 1536 bytes available to your MPLS interface, your IPSec packet will be fragemented. Your users wouldn't notice the difference, however the routers at either end have to buffer the IPSec packets until the fragements are recieved, then reassemble the packets, decrypt them, sned the packet to the virtual tunnel interface, and finally route them.
This approach should work and would be transparent to the user PC which will be generating and recieving maximum sized frames. Be aware that this will put extra load on your routers that are having to do the fragmentation and reassembly in addition to the other processing that they need to do. I believe that the question becomes do you want that processing load done on the network routers or do you want the end stations to control it. I have done IPSec with GRE tunnels many times and have used a slightly different aproach. I use the command ip tcp adjust-mss on the VPN router interfaces facing the end stations. I set the mss to a size that will not require fragmentation and thus reduce the processing load on the router. It is almost transparent to the end station (no change is required on the end station) and the impact is that the end stations will negotiate a frame size less than 1500.
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...