Home > Computer network > Problem with MTU

Problem with MTU

Problem

One of our customer has two branches. There is Site-2-Site VPN (based on Cisco ASA devices) between those two branches. There was weird problem when traffic went through that Site-2-Site VPN tunnel. Some communications were fine, but most of them didn’t work. Problems that we noticed:

  • OutlookAnywhere didn’t work
  • Domain controllers from both sides couldn’t replicate
  • HTTPS connections didn’t work
  • ESX client didn’t connect to ESXi server via tunnel (Call “ServiceInstance.RetrieveContent” for object “ServiceInstance” on Server…)

Solution

Change MTU on computer to something lower than 1500 MTU. You can use following commands:

netsh int ip show int

netsh interface ipv4 set subinterface “Local Area Connection” mtu=1300 store=persistent

If everything works, you need to adjust MTU on Cisco ASA devices. There is great article about it HERE. We used Method 2.

This change made local administrators very very very happy 🙂

Categories: Computer network Tags:
  1. Peter Palúch
    April 16th, 2015 at 20:17 | #1

    Hi Ondrik,

    Nice observation! I hope, though, that you haven’t left the end hosts with the decreased MTU.

    By the way, there’s also another way of testing for MTU issues without meddling with the sensitive interface settings such as MTUs – just use the ping with the DF bit set while varying the payload size. With all things good, pings of up to 1500 bytes including IP and ICMP headers should be sent and received well. If any MTU issue exists along the path, you’ll either get no responses, or Destination Unreachable/Packet Too Big replies from routers on the path, for all pings whose total size approaches, though isn’t equal to, 1500 bytes.

    Best regards,
    Peter

  2. April 17th, 2015 at 11:51 | #2

    Hello Peter 🙂

    Thank you for your comment. MTU on end user machine was not changed. It was solved by changing settings on ASAs.

  3. Stanmoreiyo
    April 24th, 2022 at 04:39 | #3

    (palimpsests). In the XIII-XV centuries in

  4. Frankdok
    October 29th, 2024 at 00:11 | #4
  1. No trackbacks yet.