VPN – Configuring L2TP VPN for iOS 14 and macOS Big Sur

l2tplibreswanmac-osxvpn

After Apple did this in Big Sur OS I can't connect to my own VPN on Libreswan 3.27 (netkey) on 3.10.0-1160.6.1.el7.x86_64

Starting with iOS 14 and macOS Big Sur (coming soon), IPsec supports
HMAC-SHA-256 with L2TP VPN. To make sure that VPN client devices
running iOS 14 and macOS Big Sur can connect to your L2TP VPN server,
configure the server to truncate the output of the SHA-256 hash to 128
bits. Truncating to fewer than 128 bits will result in L2TP VPN
failing to connect.

I'm not a professional server admin or Unix geek so I still can't understand what should I need to change in config to solve the situation.

Now my ipsec.conf is looks kinda this:

version 2.0

config setup
  virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.42.0/24,%v4:!192.168.43.0/24
  protostack=netkey
  interfaces=%defaultroute
  uniqueids=no

conn shared
  left=%defaultroute
  leftid=#serverIP#
  right=%any
  encapsulation=yes
  authby=secret
  pfs=no
  rekey=no
  keyingtries=5
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1,aes256-sha2;modp1024,aes128-sha1;modp1024
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes256-sha2_512,aes128-sha2,aes256-sha2
  sha2-truncbug=yes

conn l2tp-psk
  auto=add
  leftprotoport=17/1701
  rightprotoport=17/%any
  type=transport
  phase2=esp
  also=shared

conn xauth-psk
  auto=add
  leftsubnet=0.0.0.0/0
  rightaddresspool=192.168.43.10-192.168.43.250
  modecfgdns="8.8.8.8 8.8.4.4"
  leftxauthserver=yes
  rightxauthclient=yes
  leftmodecfgserver=yes
  rightmodecfgclient=yes
  modecfgpull=yes
  xauthby=file
  ike-frag=yes
  ikev2=never
  cisco-unity=yes
  also=shared

Thank you for any help you can offer.

Best Answer

I was having this same problem after updating,

change sha2-truncbug=yes > sha2-truncbug=no

Using IPsec and xl2tpd for L2TP over IPsec server. The client is macOS Big Sur Version 11.0.1

Unfortunately, I have not figured out what that configuration key does, and it's not documented anywhere so I cant give you a good explanation why this works.

Make sure to do a systemctl restart ipsec after updating the config file.

Edit: Found it documented on github

Related Solutions

Linux – selective routing through a VPN tunnel

This is the problem:

rightsubnet=0.0.0.0/0

with this line you tell openswan that the endpoint of the tunnel is "everything", so all packets are routed through the vpn.

Replace 0.0.0.0/0 with the network(s) you want to reach behind the gateway. The config on the client and server has to match, so edit both.

L2TP with PEAP Authentication on MacOS/iOS – Setup Guide

I haven't found official confirmation that Mac OS X doesn't support PEAP-EAP-MSCHAPv2, but I can't get it to work either (Windows SBS 2003 R2 and L2TP-over-ESP with a Mac OS X 10.8 client here). I'm not even seeing the login attempts in the IAS log file. (The Security Event Log is full of all kinds of stuff, so I haven't read through it very closely.) I did confirm to my satisfaction that at least ISAKMP and IPsec ESP were working by inspecting /var/log/racoon.log on the Mac, where I saw entries similar to the following (here 198.51.100.200 is the Mac and 192.0.2.100 is SBS):

DEBUG: agreed on pre-shared key auth.
INFO: NAT detected: ME PEER
INFO: ISAKMP-SA established 198.51.100.200[4500]-192.0.2.100[4500] spi:0123456789abcdef:0123456789abcdef
INFO: NAT detected -> UDP encapsulation (ENC_MODE 2->61444).
INFO: IPsec-SA established: ESP/Transport 192.0.2.100[4500]->198.51.100.200[4500] spi=01234567(0x012345)
INFO: IPsec-SA established: ESP/Transport 198.51.100.200[4500]->192.0.2.100[4500] spi=89abcdef(0x6789ab)

I also looked at /var/log/ppp.log, which has stuff like the following in it:

IPSec connection started
IPSec phase 1 client started
IPSec phase 1 server replied
IPSec phase 2 started
IPSec phase 2 established
IPSec connection established
L2TP sent SCCRQ
L2TP received SCCRP
L2TP sent SCCCN
L2TP sent ICRQ
L2TP received ICRP
L2TP sent ICCN
L2TP connection established.

This recaps the successful IPsec connection shown in racoon.log and adds a successful L2TP connection (which makes sense - L2TP is itself unauthenticated). Next, the Mac tries to build a PPP connection over L2TP, as expected, and this is where I start to see errors that I don't understand:

lcp_reqci: rcvd unknown option 13
lcp_reqci: rcvd unknown option 23
lcp_reqci: returning CONFREJ.

Followed by:

sent [LCP ConfRej id=0x0...
rcvd [LCP ConfAck id=0x1...
rcvd [LCP ConfReq id=0x1 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x1 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x2 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x2 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x3 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x3 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x4 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x4 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x5 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x5 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x6 <mru 1400> <auth eap>...
lcp_reqci: returning CONFREJ.
sent [LCP ConfRej id=0x6 <auth eap>]
rcvd [LCP TermReq id=0x7...
sent [LCP TermAck id=0x7]
Fatal signal 6

Note the 'auth eap' and 'auth chap MS-v2' in the above.

I'm going to try backing out some of the changes I made to the remote access policy:

re-enable all encryption types (no/basic/strong/strongest, was strongest only)
remove all EAP types and enable only MSCHAPv2 (was Protected EAP [PEAP]/EAP-MSCHAPv2)

Given that the entire exchange is protected by IPsec, I wonder about my actual risk. If someone's compromised a client such that they have access to the PSK or certificate used with IPsec, I'm not sure if having only PEAP to authenticate the PPP connection will matter (at least, for my threat model).

UPDATE: I re-enabled MSCHAPv2 in both the RRAS server properties and in the IAS policy that controls VPN access, and I enabled all encryption types. After making these changes the Mac was able to connect to the L2TP-over-IPsec VPN again, using MSCHAPv2 to authenticate over PPP. I toggled PEAP on and off in the IAS policy just to confirm that PEAP would not work, and in fact, with PEAP enabled (but MSCHAPv2 disabled), I now receive an authentication failure message, and Mac OS X logs the following:

MS-CHAP authentication failed: E=649 No dialin permission
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]

I suppose the more ambiguous behavior before was due to the fact that I disabled MSCHAPv2 in RRAS itself as well as in the IAS policy, whereas my current test configuration has MSCHAPv2 enabled in RRAS but disabled in the IAS policy.

Best Answer

Related Solutions

Linux – selective routing through a VPN tunnel

L2TP with PEAP Authentication on MacOS/iOS – Setup Guide

Related Topic