MTU and ipsec

[Antonio_1_2]

Hello,

I have this situation

CPE_B---(mtu1500)------R1-----(mtu1500)--------- R2--(mtu1500)------R3--(mtu1500)---CPE_A

  |                                                                                                                          |

  | --------------------------------------------IPSEC------------------------------------------------------------------ |

If I have default mtu values on interfaces in network then IPSEC between A and B works fine

But if I increase MTU values to 1524 on certain interfaces on routers R2 and R3 (shown below)

CPE_B---(mtu1500)------R1-(mtu1500)-------(mtu1524)- R2--------(mtu1524)------R3--(mtu1500)---CPE_A

  |                                                                                                                                         |

  | --------------------------------------------------------------------IPSEC--------------------------------------------------------- |

then IPSEC doesn't work.

All other traffic (TCP i.e like browsing) works fine

Link R1-R2 has mismatched MTU values as it can be seen.

Does anyone has idea why this increasing of MTU on core routers creates problem for IPSEC?

Because I thought that only lowering MTU values can cause problems. Not increasing

regards,

A

.

[danrya]

After you increase the MTU, can you still ping between the IPSec endpoints (not within the tunnel)?  Or is connectivity between the CPE's completely down?

Dan

[manish arora]

The IPSec will not work and other stuff like web or any other tcp would work fine as the router interface will Fragment the packets , whereas in case of IPSEC you cannot fragment the packets as doing that would mean that IPsec packet was modified enroute and is against the security policy for which ipsec was designed.

If you have two clients between tunnel endpoint, try using extended ping with -f -l 1500 + size , this wouldn't work as you have DF bit set to ON.

I hope i make sence here.

Thanks

Manish

[Antonio_1_2]

But doesn't all regular TCP/IP packets in tcp/ip stack has df bit set to 1 (for PMTUD)?

I think there shouldn't be fragmentation for TCP packets in network

A.

[Antonio_1_2]

yes.endpoints are stil pingable. Only ipsec doesn't work

A.

[Antonio_1_2]

Furthermore it is not the only customer that has problem with ipsec. I have also more complicated situation like shown below:

                                    -----------------------------------GRE(mtu1524)-------------------

                                    |                                                                          |

CPE_B---(mtu1500)------R1-(mtu1500)-------(mtu1524)- R2--------(mtu1524)------R3--(mtu1500)---CPE_A---IPsecVPN_Client

  |                                                                                                                                                           |

  | --------------------------------------------------------------------dynamic IPSEC-------------------------------------------------------------- |

This is VPN client tries to connect to Ipsec concentrator over GRE tunnel. It works fine if everywhere MTU has default 1500.

But if I increase MTU on interfaces as shown above then client can't connect to IPsec concentrator

A.

[jorge.calvo]

Hello,

You have to take in count the overhead that GRE and IPSEC adds to the IP packet.Hence you have to decrease you MTU to acomodate that over head. Please see the maximum MTU sizes for the interfaces creating the VPN:

IPsec Transform (Mode)	IP MTU on GRE Tunnel
AH/ESP (Tunnel)	1406
ESP (Tunnel)	1418
AH/ESP (Transport)	1426
ESP (Transport)	1438

This link may be useful to you:

http://www.iphelp.ru/doc/3/Cisco.Press.Comparing.Designing.and.Deploying.VPNs.Apr.2006/1587051796/ch07lev1sec4.html

Hope this helps.

[Antonio_1_2]

yes, but as I understand that should be done (decrease mtu)

on interfaces in front of ipsec tunnel which is not under my administration.

I can only increase MTU on my core routers. But as I explaind in previous posts it creates problems, and doesn't solve anything

regards,

A