MTU problem with NAT64? RRS feed

  • Question

  • Problem:
    DirectAccess clients are connected to a UAG Server with SP1.
    IPv6 connectivity is working properly, but NAT64 is causing problems.

    • A custom .Net application is receiving lots of errors: 'The Operation has timed-out'
    • Internet Explorer hangs while loading different pages. Some pages cannot be displayed at all.
    • Offline folders are not being synced.
    • Almost every communication which relies on NAT64 is either very slow, or cannot succeed.
    • Very slow logon times (up to 30 minutes) were reported, which were solved after implemeting the workaround (see below).

    Technical Details:
    We have a server with the following IP-addresses:
        fde4:2360:6155:200:b1ef:ca30:5c2:9814 (which is resolved by DNS64 to fde4:2360:6155:4:4:4:a84:510f)

    In the transcript of a command-prompt, I refer to these two addresses as
        native-ipv6 for the 1st address
        nat64 for the 2nd

    C:\>ping -l 1224 nat64
    Pinging nat64 [fde4:2360:6155:4:4:4:a84:510f] with 1224 bytes of data:
    Reply from fde4:2360:6155:4:4:4:a84:510f: time=244ms
    Reply from fde4:2360:6155:4:4:4:a84:510f: time=130ms
    Reply from fde4:2360:6155:4:4:4:a84:510f: time=132ms
    Reply from fde4:2360:6155:4:4:4:a84:510f: time=83ms

    C:\>ping -l 1225 nat64
    Pinging nat64 [fde4:2360:6155:4:4:4:a84:510f] with 1225 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    C:\>ping -l 5000 native-ipv6
    Pinging native-ipv6 [fde4:2360:6155:200:b1ef:ca30:5c2:9814] with 5000 bytes of data:
    Reply from fde4:2360:6155:200:b1ef:ca30:5c2:9814: time=810ms
    Reply from fde4:2360:6155:200:b1ef:ca30:5c2:9814: time=699ms
    Reply from fde4:2360:6155:200:b1ef:ca30:5c2:9814: time=932ms
    Reply from fde4:2360:6155:200:b1ef:ca30:5c2:9814: time=1110ms

    Note: The above transcript is from our production environment. Slow response are 'normal', since these clients are connected over a Mobile Broadband Network (HSDPA) connection.
    I do have an isolated test-environment (without Mobile Broadband, without using the internet, without firewall, just UAG) where I was able to reproduce the exact same problem. (Including .Net HttpWebRequest calls which sporadically generate 'The Operation has timed-out' errors)

    My Preliminary Conclusion:
    Communications to the above NAT64 address are limited to a packet payload of 1224 bytes.
    Anything larger than that is just being dropped, whereas communications to the Native-IPV6 address is not suffering this limit.
    Notice however that exact limit of which packets are allowed changes, based on the ip-address.
    Communications to the following NAT64 address fde4:2360:6155:4:4:4:a00:6 are limited at 1232 bytes (which is 8 bytes more)

    When configuring a valid IPv6 address + the required AAAA records for each server, all communications work properly.


    Am I doing something wrong? Is there something I forgot to configure?

    Since I was able to reproduce this behaviour in an isolated test-environment, I believe this might be a bug in the NAT64 component.

    Is there a solution or fix for this problem?

    Monday, September 5, 2011 10:27 AM

All replies

  • Hi BVereeke,

    since none of the DA members has touched your posting so far, i would recommend to open an CSS request to get an official statement regarding this fragmentation issue. I would't love to read the official words on this issue, too. So please update your post if you got some interesting news...

    In the mean while, you may also use a intermediate router (between UAG and internal network) to inspect and tweak the TCP-MSS options during TCP handshakes. This its a common task for network enviroments when intermediate encapsulation takes place or different media types / network protocols requires some additional tweaks. It will allow you to inform the DA client and your internal server that they shouldn't put that much DATA into a single IP datagram and therefore eliminate the fragmentation issue you currently have.

    Cisco Config Guide: TCP MSS Adjustment


    • Edited by Kai Wilke Saturday, September 10, 2011 10:42 AM
    Saturday, September 10, 2011 10:34 AM
  • I concur with some of your interesting!

    Let me ask around ;)



    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: and
    Saturday, September 10, 2011 11:44 PM

    Thank you for your answer. If I don't get an answer on this forum, I will indeed open a support request.
    Concerning TCP-MSS options: I was able to reproduce the problem in a virtual test environment:

    • VM1 = DC in LanA
    • VM2 = WEBServer in LanA
    • VM3 = UAG in LanA + LANB
    • VM4 = Win7 in LANB
    • VM5 = DNS in LANB

    No real internet connectivity and no hardware involved. Everything running virtual, on the same box.
    LanB was assigned a virtual-public network segment.
    The only routing/NAT in place, was the one done by UAG/NAT64 and/or directaccess.

    Same problem in this lab.


    Kind regards,

    Bert Vereecke

    Monday, September 12, 2011 4:04 PM
  • The same tests produced different results for me...I had the same maximum MTU problems with BOTH NAT64 and native IPv6 addressed intranet hosts...

    However, I don't get the same problems you list in your first post, even with the apparent MTU limitations. 

    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: and

    Monday, September 12, 2011 4:13 PM
  • Hi all,

    I'm working on a test project to translate to/from IPv4 to IPv6  using NAT-PT, due to my hardware limitation I stuck with NAT-PT. So I have the same issue where I can ping from IPv4 windows (laptop) to an IPv6 address (getting the IPv6 address from the NAT-PT router).

    and pinging with default 32 bytes work fine upto 1224 bytes. I can only go upto 1452 bytes if I used -f while pingning basically like this:

    c:>ping -l 1452 - f <means Don't fragment bit) I can ping fine. so please see  RFC 2765, Sec. 3 para:2 & 3.

    so with having the server DF set to 1 means do not fragment you can get 1452 which is max MTU 1500-40 bytes MSS-8 bytes of fragment header.

    Remember min MTU for IPv6 is 1280. So I'm still working on getting the wireshark to get more info.


    Hope this somewhat helpful?


    Maz Mohamed


    Wednesday, October 26, 2011 6:35 PM
  • Hi all.

    Any news about MTU issues and possible solution?

    Thanks in advance.

    Sunday, November 4, 2012 12:08 PM