Fix Win NAT-T for L2TP and IKEv2


Windows 2012 RRAS IPsec VPN does not support NAT-T out-of-the-box.  By default, RRAS only works with public IP addresses -no NAT.  Windows 10 clients cannot connect with L2TP from outside the office.  Windows 2016 does not support L2TP for any client from behind routers running NAT.


Enable NAT-T on both Windows servers and the clients.  NAT-T allows the VPN server to serve clients (e.g., Windows 10, Android, Apple iOS) from behind the NAT device.  Modify MTU. 


Why NAT-T? 

IPsec uses Encapsulating Security Payload (ESP) to encrypt packet headers and payloads.  By default, ESP is not compatible with Port Address Translation (PAT).  This is because TCP uses ports and ESP does not.  

TCP and ESP are different Internet protocols. TCP uses protocol number 6.  N.B., TCP protocol number 6 is not the same thing as TCP port 6.  TCP ports are communication endpoints.  For example, TCP uses port 80 for web traffic.  

ESP uses protocol (i.e., not port) number 50.   ESP is a protocol without ports.  Network Address Translation (NAT) uses port translation PAT to bind traffic flows with internal hosts.  Therefore, ESP does not work with NAT.

NAT-T allows ESP to work from behind NAT.  It encapsulates ESP protocol 50 inside User Datagram Protocol (UDP) 4500.   N.B, NAT-T is not the same as IPsec over UDP.

Enable NAT-T 

NAT-T is enabled on most operating systems (e.g., Android) -Windows is the exception.  Fortunately,  we can enable NAT-T on Windows 10 and Windows 2012 with a few simple changes. 

Windows IPsec clients are supposed to work from any location.  Therefore, only enable NAT-T on the 2012 RRAS server.  

Create a new registry key to enable NAT-T.

  1.   Edit Registry or create GPO:


  1.   Create new DWORD value:   AssumeUDPEncapsulationContextOnSendRule

  1.   Modify DWORD value:  2

These changes will fix those pesky L2TP-NAT problem.  

Troubleshooting Issues

Make sure clients use the latest edition of Windows 10.  Early versions had quirks where clients simply would not connect via NAT-T.  

   NAT-T does not work with  the following editions:

  • version 10240
  • version 1511 (i.e. November Update)
   Unconfirmed (may or may not work):  
  • version 1607 (i.e., Anniversary Update)

  • version 1703 (i.e., Creators Update)
   NAT-T works great with the registry fix and Creators Update.


Some folks had to toggle the NAT-T registry value in order to connect (  I assume this fix was for the November or Anniversary Update.  


Don't forget to adjust the Max Segment Size (MSS):  

That's It!


  1. AssumeUDPEncapsulationContextOnSendRule is for L2TP, not for IKEv2

    1. Thanks for pointing that out. To be clear, this solution supports both L2TP/IPsec and IKEv2 VPNs. I should have stated that the article assumes the VPN server supports L2TP, IKEv2, and SSTP VPNs.

      To your point, IKEv2 (generally) does not require NAT-T. IKEv2 uses NAT detection to determine remote topology. NAT initiates UDP encapsulation for all all ESP and subsequent IKE traffic -unlike IKEv1 (i.e., L2TP/IPSec.)

      On the other hand, IKEv2 does support NAT-T. (RFC7296). Samir Jain, Microsoft Program Manager for RRAS states, "-although NOT RECOMMENDED" the Microsoft IKEv2 VPN server can sit behind a NAT router:

      (a) Use port redirection (e.g., VIP/PAT) or bi-directional NAT (e.g., MIP). This includes IKE packets (UDP port 500) and IPSec ESP packets (UDP port 4500) from the NAT router.

      (b) Enable NAT-T for both Windows client and Windows VPN server. (Technet, 2009).

      So should we enable NAT-T or not enable NAT-T on Windows IKEv2 VPN servers? RFC indicates that NAT-T is optional. Microsoft does not (officially) recommend NAT-T -assign public IPs instead. Unofficial documentation indicates NAT-T is necessary for IKEv2 servers behind NAT routers.

      The question we should ask ourselves, is why doesn't Microsoft recommend NAT-T for their IPSec VPNs? Most Microsoft documentation warns of "unintended side effects". Really? Can someone from Microsoft please elaborate? I suspect the RRAS VPN does not fully conform to IKEv2 RFC standards. Another possibility is that RRAS does not merit Microsoft's full support. Who buys Windows server for its routing capabilities? To be sure, SSTP and Direct Access are a big deal. Other than that, there haven't been a lot of RRAS innovations.

      Thanks for the feedback. Cheers!

  2. Are you sure that you type registry path correct??

    1. I can confirm, it's how I have it configured on my VPN server. However, I looked into it a bit more. According to Microsoft:

      (a) Windows Vista, Windows 2008, 2012:

      (b) Windows XP:

    2. FYI you put "Parameters" in your post for the regpath

    3. . I have a windows 2012 r2 server (NAT installed). Now I am able to connect L2TP with my iPhone of laptop from anywhere. But I have a VPN router (TPlink 604W) which should setup the VPN connection from the router itself. It's working when i do it with PPTP but it won't work with L2TP? The helpdesk of TPlink are saying this is possible but what am I doing wrong?

      Kind regard,


    4. Carlo, Sorry, that's not enough information to really help. There are two important things to be aware of:

      1. Make sure all your server and clients use the same cryptography settings:

      2. Make sure you have the correct ports open:

      For L2TP:
      IP Protocol Type=UDP, UDP Port Number=500 <- Used by IKEv1 (IPSec control path)
      IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv1 (IPSec control path)
      IP Protocol Type=ESP (value 50) <- Used by IPSec data path

  3. Does that mean enabling NAT-T on the server side will allow me to put IKEv2 servers behind a load balancer (which normally only works with TCP and UDP...not ESP)?

    1. Oh man, I'm going to get a headache thinking about NLB and VPN servers! However, my crystal ball tells me that NAT-T works when NLB uses affinity.

      If the VPN server has a public IP, or uses static NAT (i.e., it translates all source and destination traffic), IKEv2 negotiates via UDP port 500. Subsequent IKEv2 traffic uses IPSec ESP 50.

      However, in your situation, both client and server are behind NAT firewalls. What's more, NLB is not going to handle ESP 50. The negotiation will detect NAT and subsequent IKEv2 traffic uses UDP port 4500.

      We've already established that NLB works with UDP. I vote thumbs up.


My Instagram