L2TP/IPSec doesn't work in Windows 2016

L2TP is available in AWS. If you cannot use L2TP even if it is configured correctly, I suspect that your EC2 specs are not sufficient.

I assume you are using t3.micro, but it is not sufficient to run Windows Server. (For a server with Desktop Experience, a minimum of 2 GB of memory is recommended.)

Please check the CPU and memory utilization to see if the specifications are insufficient.

The memory usage rate can be obtained by referring to the following

https://repost.aws/knowledge-center/cloudwatch-memory-metrics-ec2

Where are you trying to access over that vpn? The rest of your VPC?

If so, have you set Source/Destination Check off in the instance? Would be the first thing that comes to mind with the description.

Found a similar case on ServerFault, copying a solution that helped from there used to be at https://forums.aws.amazon.com/thread.jspa?messageID=487251 , that may or may not be what you're looking for, but might help:

A little late in the game, since this post is almost 2 years old; however, we just finished configuring RRAS w/L2TP IPSEC VPN & NAT on a Win2012 instance. Hoping this helps anyone else who happens to find their way to this thread.

This setup is pretty open & you'll want to lock down your ACLs and SecGroups once you get everything working; however, this should get you on your way:

NOTE: ^ = right-click

Prerequisites:

Internet gateway
VPC with one or more subnets (we're using 2 - one is exclusively for RRAS & another is for LAN server).
Windows 2012 instance (our RRAS server) with 2 network interfaces. Assign static IPs to each interface (we have sequential IPs, but not sure that's required). Attach and EIP to Eth0. Disable SRC/DEST checking on each interface (note: in my experience, disabling SRC/DEST on the instance only affects Eth0. Better to do this manually on each interface).
Windows 2012 instance (our LAN server) with 1 network interface, static IP assigned
RRAS server is joined to your domain (pretty sure this is required for RRAS, but it's certainly required for our setup, as VPN users authenticate against AD). You should already have your ACLs and SG settings configured to allow the RRAS server to communicate with your DC(s).
Configure ACL (for testing, we have the ACL applied to both the RRAS and LAN subnets) Inbound: Port 3389 (RDP); TCP; YOUR IP or IP range (this is for mgmt purposes; can be deleted or modified after your VPN is up) Inbound: All; All; All; VPC subnet (for NAT) Inbound: Port 500; UDP; 0.0.0.0/0; Allow (for VPN) Inbound: Port 4500; UDP; 0.0.0.0/0; Allow (for VPN) Inbound: All; ESP (50); 0.0.0.0/0; Allow (for VPN) Inbound: 1701; UDP; 0.0.0.0/0; Allow (for VPN) Inbound: Range 49152-65535; TCP & UDP; 0.0.0.0/0; Allow (replies to LAN traffic) Outbound: All; All; 0.0.0.0/0; Allow (for NAT & VPN)

Configure security group for RRAS server Inbound: All; All; LAN SG ID Inbound: TCP; 3389 (RDP); YOUR IP or IP range (also for mgmt purposes; can be deleted or modified after your VPN is up) Inbound: -- Inbound: UDP; 500; 0.0.0.0/0 Inbound: UDP; 1701; 0.0.0.0/0 Inbound: UDP; 4500; 0.0.0.0/0 Inbound: ESP (50); ALL; 0.0.0.0/0 Outbound: All; All; 0.0.0.0/0

Configure security group for LAN server Inbound: All; All; RRAS SG ID Inbound: TCP; 3389 (RDP); YOUR IP or IP range (also for mgmt purposes; can be deleted or modified after your VPN is up) Outbound: All; All; 0.0.0.0/0

Configure route table for RRAS server (we use the Main rtb) VPN Subnet; local; active 0.0.0.0/0; IGW ID; active

Configure route table for LAN server (required for NAT) VPN Subnet; local; active 0.0.0.0/0; RRAS Eth1 interface ID; active At this point, you should be able to RDP to both servers from your local machine, as well as from one server to another. Additionally, the RRAS server should be able to reach a public site (e.g., Google), whereas the LAN server should not. Now for the voo-doo to bring it all together:

Install Routing and Remote Access on your RRAS server

Server manager > Add roles and features > Role-based Remote Access (accept defaults) When prompted, include the Routing role services

Configure Routing and Remote Access services Note: we're using a PSK & static address pool for this exercise; your final configuration might differ Routing and Remote Access ^ Server Name > Configure and Enable Routing and Remote Services Custom Configuration > VPN Access, NAT

Routing and Remote Access ^ Server Name > Properties Security > Authentication Methods > Uncheck EAP (this caused unnecessary headaches) Check: Allow custom IPsec policy for L2TP/IKEv2 > enter PSK

Routing and Remote Access > Server Name > IPv4 Select Static Address Pool & enter an appropriate range [Note: we opted to use IPs from the RRAS subnet, although any private IP range should work, as long as there's no chance of an IP conflicting with that of an instance in your VPC)

Routing and Remote Access > Server Name > IPv4 ^ NAT > New interface > Ethernet (this should be Eth0 - verify by IP) Select: Public interface connected to the internet Check: Enable NAT on this device

Routing and Remote Access > Server Name > IPv4 ^ NAT > New interface > Ethernet 2 (this should be Eth1 - verify by IP) Select: Private interface connected to the to private network Okay, that takes care of Routing and Remote Services; but, it's not going to work quite yet. Remember that "voo-doo" I mentioned? Time to tweak the RRAS server into submission...

Voo-doo Item #1 (thank you, AWS support, for providing this only after my 5th support call)

RegEdit > HKLM\SYSTEM\CurrentControlSet\Services\Tcpip ^ Parameters > New DWORD: DisableTaskOffload ^ DisableTaskOffload > Modify > Value data: 1

Voo-doo Item #2 (thank you, Comcast, for screwing up my home network this week & giving me the AHA moment that finally got NAT working) Routing and Remote Access > Server Name > IPv4 ^ Static Routes > New static route > Interface: Ethernet (i.e., Eth0); Destination: 0.0.0.0; Network Mask: 0.0.0.0; Gateway: RRAS server's default gateway (grab this from IPCONFIG/ALL); Metric: 1 Routing and Remote Access > Server Name > IPv4 ^ Static Routes > New static route > Interface: Ethernet 2 (i.e., Eth1); Destination: VPC Subnet; Network Mask: VPC Subnet Mask; Gateway: RRAS server's default gateway; Metric: 1

Finally, the client machine. In our case, Win7x64, but also works on Win8x64:

Create the VPN connection Network and Sharing Center > Setup a new connection or network > Connect to a workplace Create a new connection
Use my internet Connection Internet address: RRAS EIP Destination name: Check: Don't connect now; just set it up so I can connect later (trust me) Enter domain credentials Create > Close
Configure the VPN connection ^ "AWS L2TP" (or whatever you named it) > Properties Security tab Type of VPN: Layer 2 Data encryption: require Deselect: CHAP Advanced tab Use PSK
Voo-doo Item #3 (what... you thought it was over?) RegEdit > HKLM\SYSTEM\CurrentControlSet\services\PolicyAgent ^ AssumeUDPEncapsulationContextOnSendRule > Modify > Value data: 2

You should now be able to [a] establish an L2TP VPN connection to your RRAS server & access your LAN server by private IP and FQDN (assuming your VPC was previously configured to allow communication between RRAS and your DC); establish a connection from your LAN server to a public resources. Tracert should confirm that the traffic is traversing the RRAS server.

There you have it. Easy peasy, VPC...sy?

A final word: the ACLs and SG settings are pretty lax at this point, as I had mentioned earlier. The goal here is not to have a fully secure network, but a proof of concept. I strongly suggest that you tweak your ACLs and SG settings to tighten up your VPC, testing your connections as you go along. In other words, I'm not responsible - you are. ;)