none
NAT64 translation failure

    Question

  • NAT64 recently started to give errors.

    ERROR
    NAT64 translation failures might be preventing remote clients from accessing IPv4-only servers in the corporate network.

    CAUSES
    1. NAT64 is not enabled on the server.
    2. The NAT64 server cannot be reached.
    3. NAT64 translation has failed.

    RESOLUTION
    1. Ensure that the NAT64 server can be reached on the corporate network.
    2. Ensure that NAT64 is enabled on the server.
    3. If you have native IPv6 connectivity, ensure that the NAT64/DNS64 prefix is configured in the DirectAccess settings.
    4. In the Remote Access Server Setup Wizard, ensure that the default NRPT entry points to the internal address of the NAT64/DNS64 server.

    I'm not sure what the cause is or how to troubleshoot it. Any ideas?


    Mike Pietrorazio

    mercredi 19 octobre 2016 12:48

Toutes les réponses

  • We are facing the same issue....DirectAccess works fine; the NAT64 sometimes works fine and sometimes it throws a warning randomly ...

    Dear Experts...Please help us to resolve the issue....

    


    Dev T

    lundi 9 octobre 2017 04:25
  • Why not use only iphttps?

    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!

    lundi 23 octobre 2017 13:23
  • We have to use IPHTTPS and NAT64 or DA will not work.

    https://blogs.technet.microsoft.com/edgeaccessblog/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action/ 


    Dev T

    lundi 30 octobre 2017 04:31
  • Dear Experts....Any help on this?

    Dev T

    lundi 6 novembre 2017 04:49
  • We have to use IPHTTPS and NAT64 or DA will not work.

    https://blogs.technet.microsoft.com/edgeaccessblog/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action/ 


    Dev T


    You are looking on 2009 old info! DA works with IPHTTPS and it is preffered protocol as I see. I had a working lab enviroment on W2012 R2 with IPhttps only, I disabled everything else.

    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!

    mardi 7 novembre 2017 07:05
  • Also, patch your DA server 100%. For Windows 7 clients, there are spesific hotfixes which needs to be distributed as well (if you still want to get NAT64 to work).

    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!

    mardi 7 novembre 2017 12:44
  • DirectAccess is works on IPv6, we need to use NAT64 and DNS64 to let DirectAccess clients access the IPv4 internal resources. NAT64 will translate the IPv6 addresses of clients to the internal IPv4 address of the DirectAccess Server. 

    Dev T

    mercredi 8 novembre 2017 06:13
  • We also have been having some intermittent connection issues for our direct access clients.

    The only events we can find that match are as follows however searching for anything on how to troubleshoot a nat64 issue seems to be few and far between. We are currently running this on Server 2012 R2 inside a Microsoft VM.

    The event looks to be coming from a monitoring program in direct access however we don't see anything for diving into Nat64 and troubleshooting it.

    Nov 13 22:53:30 servername.domain MSWinEventLog 4 Microsoft-Windows-RemoteAccess-RemoteAccessServer/Admin 139 Mon Nov 13 22:53:20 2017 10039 Microsoft-Windows-RemoteAccess-RemoteAccessServer S-1-5-20 N/A Warning servername.domain 2 NAT64 monitor has gone from HEALTHY state to WARNING state on 11/14/2017 at 4:53 AM on SERVERNAME. The failure heuristic IDs for state change of NAT64 are 80070003.


    Nov 13 23:03:21 servername.domain MSWinEventLog 6 Microsoft-Windows-RemoteAccess-RemoteAccessServer/Admin 140 Mon Nov 13 23:03:20 2017 10040 Microsoft-Windows-RemoteAccess-RemoteAccessServer S-1-5-20 N/A Information servername.domain 2 NAT64 monitor has gone from WARNING state to HEALTHY state on 11/14/2017 at 5:03 AM on SERVERNAME.

    Do you have any tips on how to trouble shoot this as the info on nat64 is really lacking?

    Thanks

    Brad

    mardi 14 novembre 2017 19:53
  • Experts....Please help...

    Dev T

    jeudi 30 novembre 2017 06:26
  • Experts....Please help...

    Dev T

    Is your DA server 100% patched?

    For W2012 R2 native DA solution, I would suggest this forum class: https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverNIS

    I believe UAG and Edge is obsolete...


    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!


    • Modifié yannara jeudi 30 novembre 2017 07:03
    jeudi 30 novembre 2017 07:03
  • Moved this thread to

    https://social.technet.microsoft.com/Forums/en-US/a5258dba-6686-49f1-8fac-0cb22e7c5144/nat64-translation-failure?forum=winserverNIS

    Many thanks...


    Dev T

    lundi 4 décembre 2017 09:16
  • Hey guys, just to clear the air for anyone else visiting this post - this NAT64 warning is actually a fairly common thing to see on a DirectAccess server that is running higher capacity user connections. I don't know how many connections you are running, but the NAT64 engine has a hard-stop limit of 41,000 sessions/transactions simultaneously. Each of your clients can be utilizing a number of NAT64 sessions simultaneously, so this in no way means you can run 41,000 users.

    This NAT64 warning presents itself upon hitting a predetermined warning threshold against that 41,000. I don't know exactly when it hits, but I have numerous high-capacity customers who see this warning regularly, yet they have never had an outage from it so the warning threshold is set pretty low.

    I wouldn't be worried about it, but you should also be watching your CPU/memory utilization numbers and if you think your server is getting close to tapping out, start making plans to add an additional DirectAccess server node.

    Also to clear the air on IP-HTTPS vs NAT64 as was stated above - these are two completely different things. NAT64 is ALWAYS used by DirectAccess when you have your DA server running in an IPv4 internal network. IP-HTTPS is an external tunneling protocol and has nothing to do with NAT64. I think the person commenting about using "only IP-HTTPS" is thinking of Teredo, not NAT64, as the other transition tunneling technology and you are correct, Teredo is not needed for DirectAccess to work properly. But having IP-HTTPS and NAT64 both working are essential to making DA work in 99% of networks out there. Hope that clears it up!

    jeudi 7 décembre 2017 13:56
  • Thank you Jordan for the information on nat64. I will see about setting some CPU/Memory monitoring on the server but I feel as though the issue may be something else at our end.

    Our Direct Access Server load stats I believe are well below the 41,000 you indicated. The Remote Access console has the following reported numbers from last week.

    Total DirectAccess Sessions 21052
    Maximum concurrent sessions: 121
    Total Unique users: 166
    Unique Direct Access Clients: 166


    mercredi 13 décembre 2017 17:49
  • At any given point in time not more than 200 clients are connected in our environment...Secondly we have SCOM monitoring the CPU utilization and email alert is at 50%...We are not getting any alerts...I physically checked the CPU 6 to 7 times and everything looks good (Below 35%)

    Dev T

    lundi 18 décembre 2017 07:15
  • Anything new on this. I'm getting the warning too but it doesn't seem to be effecting DA usability.
    mercredi 14 mars 2018 05:10
  • Also seeing this on a fresh implementation with Windows Server 2016.  It doesn't seem to cause any issues but the error goes in and out of warning state for what appears to be at random.  Most clients we've ever had connected at once so far is 17.   
    jeudi 12 avril 2018 19:22
  • I've rebuilt DA twice on 2016 and the error always shows up. Still, doesn't seem to negatively impact anything so I've given up on troubleshooting it. Actually, I'm now building an "Always on VPN" server which is going to be the successor of Directaccess. https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-map-da

    Mike Pietrorazio

    jeudi 12 avril 2018 19:32