1

I'm trying to set up l2tp inside an AWS VPC, I'm having problems.

I'm on a MAC OS and I keep getting an error "A connection could not be established to the PPP server. Try reconnecting. If the problem continues, verify your settings and contact your Administrator." Other l2tp connections from the Mac work so I'm thinking it's a server-side configuration issue having to do with AWS networking.

The server does have an EIP and the Security Group is open for the traffic. I have set UDP encapsulation as well, but no joy.

Edit:

I have confirmed it is not working on a Windows machine either. The error is: "The L2TP connection attempt failed because the security layer encountered a processing error during the initial negotiations with the remote computer"

Here's the log from my Mac:

Tue Mar  2 21:06:53 2021 : publish_entry SCDSet() failed: Success!
Tue Mar  2 21:06:53 2021 : publish_entry SCDSet() failed: Success!
Tue Mar  2 21:06:53 2021 : l2tp_get_router_address
Tue Mar  2 21:06:53 2021 : l2tp_get_router_address 172.20.10.1 from dict 1
Tue Mar  2 21:06:53 2021 : L2TP connecting to server 'XXXXXXXXXXXX' (XX.XX.XX.XXX)...
Tue Mar  2 21:06:53 2021 : IPSec connection started
Tue Mar  2 21:06:53 2021 : IPSec phase 1 client started
Tue Mar  2 21:06:53 2021 : IPSec phase 1 server replied
Tue Mar  2 21:06:54 2021 : IPSec phase 2 started
Tue Mar  2 21:06:54 2021 : IPSec phase 2 established
Tue Mar  2 21:06:54 2021 : IPSec connection established
Tue Mar  2 21:06:54 2021 : L2TP sent SCCRQ
Tue Mar  2 21:06:54 2021 : L2TP received SCCRP
Tue Mar  2 21:06:54 2021 : L2TP sent SCCCN
Tue Mar  2 21:06:54 2021 : L2TP sent ICRQ
Tue Mar  2 21:06:54 2021 : L2TP received ICRP
Tue Mar  2 21:06:54 2021 : L2TP sent ICCN
Tue Mar  2 21:06:54 2021 : L2TP connection established.
Tue Mar  2 21:06:54 2021 : L2TP set port-mapping for en0, interface: 6, protocol: 0, privatePort: 0
Tue Mar  2 21:06:54 2021 : using link 0
Tue Mar  2 21:06:54 2021 : Using interface ppp0
Tue Mar  2 21:06:54 2021 : Connect: ppp0 <--> socket[34:18]
Tue Mar  2 21:06:54 2021 : sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x312e33e6> <pcomp> <accomp>]
Tue Mar  2 21:06:57 2021 : sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x312e33e6> <pcomp> <accomp>]
Tue Mar  2 21:06:57 2021 : rcvd [LCP ConfReq id=0x0 <mru 1400> <auth eap> <magic 0x7ad21b17> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint 13 17 01 4f 48 20 23 13 c3 46 18 8f aa 74 9e ef 65 fe 3a 00 00 00 00>]
Tue Mar  2 21:06:57 2021 : lcp_reqci: rcvd unknown option 13
Tue Mar  2 21:06:57 2021 : lcp_reqci: returning CONFREJ.
Tue Mar  2 21:06:57 2021 : sent [LCP ConfRej id=0x0 <callback CBCP> <mrru 1614>]
Tue Mar  2 21:06:57 2021 : rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x312e33e6> <pcomp> <accomp>]
Tue Mar  2 21:06:57 2021 : rcvd [LCP ConfReq id=0x1 <mru 1400> <auth eap> <magic 0x7ad21b17> <pcomp> <accomp> <endpoint 13 17 01 4f 48 20 23 13 c3 46 18 8f aa 74 9e ef 65 fe 3a 00 00 00 00>]
Tue Mar  2 21:06:57 2021 : lcp_reqci: returning CONFNAK.
Tue Mar  2 21:06:57 2021 : sent [LCP ConfNak id=0x1 <auth chap MS-v2>]
Tue Mar  2 21:06:57 2021 : rcvd [LCP ConfReq id=0x2 <mru 1400> <auth chap MS-v2> <magic 0x7ad21b17> <pcomp> <accomp> <endpoint 13 17 01 4f 48 20 23 13 c3 46 18 8f aa 74 9e ef 65 fe 3a 00 00 00 00>]
Tue Mar  2 21:06:57 2021 : lcp_reqci: returning CONFACK.
Tue Mar  2 21:06:57 2021 : sent [LCP ConfAck id=0x2 <mru 1400> <auth chap MS-v2> <magic 0x7ad21b17> <pcomp> <accomp> <endpoint 13 17 01 4f 48 20 23 13 c3 46 18 8f aa 74 9e ef 65 fe 3a 00 00 00 00>]
Tue Mar  2 21:06:57 2021 : sent [LCP EchoReq id=0x0 magic=0x312e33e6]
Tue Mar  2 21:06:58 2021 : rcvd [CHAP Challenge id=0x0 <74364045b7347b39c5b1dfc36728e117>, name = "XXX"]
Tue Mar  2 21:06:58 2021 : sent [CHAP Response id=0x0 <734347e818645e3291e5aadb64eba088000000000000000068b867912db9f4098b52051c0e350df91af72a1774b6708700>, name = "XXXXX"]
Tue Mar  2 21:06:58 2021 : rcvd [LCP EchoRep id=0x0 magic=0x7ad21b17]
Tue Mar  2 21:06:58 2021 : rcvd [CHAP Success id=0x0 "S=FB69C2CC6DD794FF835AF55ED91E9DBAB6278C81"]
Tue Mar  2 21:06:58 2021 : sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Tue Mar  2 21:06:58 2021 : sent [IPV6CP ConfReq id=0x1 <addr fe80::167d:daff:fece:57fd>]
Tue Mar  2 21:06:58 2021 : sent [ACSCP ConfReq id=0x1 <route vers 16777216> <domain vers 16777216>]
Tue Mar  2 21:06:58 2021 : rcvd [CCP ConfReq id=0x4 <mppe +H -M -S -L -D +C>]
Tue Mar  2 21:06:58 2021 : Unsupported protocol 'Compression Control Protocol' (0x80fd) received
Tue Mar  2 21:06:58 2021 : sent [LCP ProtRej id=0x2 80 fd 01 04 00 0a 12 06 01 00 00 01]
Tue Mar  2 21:06:58 2021 : rcvd [LCP ProtRej id=0x5 80 21 01 01 00 16 03 06 00 00 00 00 81 06 00 00 00 00 83 06 00 00 00 00]
Tue Mar  2 21:06:58 2021 : rcvd [LCP ProtRej id=0x6 80 57 01 01 00 0e 01 0a 16 7d da ff fe ce 57 fd]
Tue Mar  2 21:06:58 2021 : rcvd [LCP ProtRej id=0x7 82 35 01 01 00 10 01 06 00 00 00 01 02 06 00 00 00 01]
Tue Mar  2 21:06:58 2021 : sent [LCP TermReq id=0x3 "No network protocols running"]
Tue Mar  2 21:06:58 2021 : Connection terminated.
Tue Mar  2 21:06:58 2021 : L2TP disconnecting...
Tue Mar  2 21:06:58 2021 : L2TP sent CDN
Tue Mar  2 21:06:58 2021 : L2TP sent StopCCN
Tue Mar  2 21:06:58 2021 : L2TP clearing port-mapping for en0
Tue Mar  2 21:06:58 2021 : L2TP disconnected

Here's the logs from the Windows server:

"XXX","RAS",03/02/2021,21:07:24,4,"XXXXXX",,"XX.XX.XX.XX","XX.XX.XX.XX",,,"XXX","XXXXX",1,,"XX.XX.XX.XX","XXX",1614737244,,5,,1,2,,,0,"311 1 fe80::edb8:9338:cb73:6adf 03/03/2021 01:54:30 4",,,,,1,,,,"5",2,,,,,"7",1,,3,1,"174.247.13.222","XX.XX.XX.XX",,,,,,,"MSRASV5.20",311,,"0x00504545524C455353",4,,"Microsoft Routing and Remote Access Service Policy",1,,,,
"XXX","RAS",03/02/2021,21:07:26,4,"XXXXX",,"XX.XX.XX.XX","XX.XX.XX.XX",,,"XXX","XX.XX.XX.XX",1,,"XX.XX.XX.XX","XX.XX.XX.XX",1614737244,,5,,1,2,,,0,"311 1 fe80::edb8:9338:cb73:6adf 03/03/2021 01:54:30 4",,,,,2,,292,407,"5",2,0,11,13,1,"7",1,,3,1,"174.247.13.222","XX.XX.XX.XX",,,,,,,"MSRASV5.20",311,,"0x00504545524C455353",4,,"Microsoft Routing and Remote Access Service Policy",1,,,,

I am totally stumped on this.

Tim Beekley
  • 11
  • 3

2 Answers2

0

The key to the problem is lcp_reqci: rcvd unknown option 13 - apparently it's got something to do with the authentication methods configured on both sides.

Maybe this answer will help: L2TP with PEAP authentication from MacOS/iOS

MLu
  • 23,798
  • 5
  • 54
  • 81
  • I did check that out, and followed it, still no dice. I also tried a windows machine and also got an error. I'm definitely thinking it's network-related on the AWS side, I just don't know when to start with that. – Tim Beekley Mar 03 '21 at 16:43
  • What makes you think it’s AWS problem? AWS is only concerned with letting or not letting the packets through, and they obviously get through. I’m pretty confident that it’s a non-compatible config between your laptop and the server. – MLu Mar 03 '21 at 21:11
  • Try connecting to the server from a Windows laptop - that may be a good test whether it’s the app level or a neteork level problem. – MLu Mar 03 '21 at 21:12
  • It turns out it was a Server-Side issue, I found this super old AWS Forum post: https://forums.aws.amazon.com/thread.jspa?messageID=487251, adding the static route that the user terralign posted about is what fixed the issue. – Tim Beekley Mar 05 '21 at 20:15
0

It seemed to be a routing issue on the AWS EC2 server itself, I followed an old post on the AWS Forums: https://forums.aws.amazon.com/thread.jspa?messageID=487251. The last post on this thread is what I followed along with and everything started working as expected, I have added his post here so that it can be saved in case the link goes stale. The trick for me was adding the static route, as I had previously done most of the post or it didn't apply in my situation.

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:

  1. Internet gateway
  2. VPC with one or more subnets (we're using 2 - one is exclusively for RRAS & another is for LAN server).
  3. 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).
  4. Windows 2012 instance (our LAN server) with 1 network interface, static IP assigned
  5. 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:

  1. 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

  1. 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. ;)

Tim Beekley
  • 11
  • 3