Windows 7 l2tp aes

Время на прочтение6 мин

Количество просмотров251K

Недавно я озадачился поиском возможности создания шифрованного подключения к своему офису средствами L2TP/IPsec протокола. Задача усложнилась, когда, кроме Windows клиентов, появилась потребность пускать в сеть еще iOS и Android клиентов. В Интернете множество статей как проделать это на Windows Server с «внешним» IP-адресом. Но я хочу предложить сообществу реализацию стандартными средствами Windows 7/8 шифрованного L2TP тоннеля в локальную сеть с популярной, на мой взгляд, топологией.

Структура сети

Маленькая сеть из десяти Windows 7/8 клиентов с выделенным сервером на базе Windows Server 2008 Std (на него пока не обращаем внимание) и с доступом в Интернет средствами простого роутера. Для VPN сервера я выделил одну из машин на Windows 7 Pro. Далее будет описано два способа поднятия L2TP/IPsec сервера на Windows 7 Pro.

Windows 7 L2TP/IPsec AES 128-bit с использованием сертификата

• Первым делом нужно сгенерировать сертификат компьютера и пользователя на VPN сервере.
  Для этого воспользуемся бесплатной утилитой Simple Authority.
  Устанавливаем, запускаем. Сразу программа предложит сгенерировать сертификат компьютера. Заполняем поля. Хаотично клацаем по клавиатуре, тем самым генерируя случайное число. Вводим пароль (лучше длиннее 8-ми символов, иначе могут быть глюки) Сертификат компьютера (CA) готов. Если пользователь не добавлен, то добавляем. Справа заполняем необходимые поля. Жмем «New certificate». После этого на рабочем столе появится два файла сертификатов с расширениями *.cer и *.p12
• Установим сертификаты на наш VPN сервер.
  Для этого делаем Win+R(«Выполнить»), вводим mmc, жмем Enter. Откроется Консоль.
  Добавляем оснастку (Файл->Добавить удалить оснастку). Выбираем «Сертификаты». Жмем «Добавить». Выбираем пункт «учетной записи компьютера» при вопросе, где будет управлять эта оснастка сертификатами. Далее, «Личное»->Правой кнопкой мыши->Все задачи->Импорт->Выбираем файл сертификата с расширением *.p12 (именно его). Вводим пароль, ставим галку «Пометить этот ключ как экспортируемый». В категории «Личное» появится два сертификата. Тот сертификат, у которого поля «Кому выдан» и «Кем выдан» одинаковые, нужно перенести в категорию «Доверенные корневые центры сертификации».
• Нужно убедиться в отсутствии параметра ProhibitIpSec=1.
  Идем в реестр (Win+R -> regedit). Ищем ветку HKLM\System\CurrentControlSet\Services\Rasman\Parameters. Если вышеуказанного параметра там нет или он равен 0, то все хорошо. Иначе, исправляем это.
• Создаем входящее подключение.
  Идем в «Центр управления сетями и общим доступом»->«Изменение параметров адаптеров». Жмем клавишу Alt, сверху выпадет меню. Далее Файл->«Новое входящее подключение». Выбираем нужных пользователей, ставим галку «Через интернет… VPN». Выбираем нужные протоколы. На TCP/IP v4->Ставим галку «Разрешить доступ к локальной сети» и обязательно устанавливаем пул адресов, выдаваемых клиенту. После создания подключения обязательно откройте его свойства и во вкладке «Пользователи» проверьте наличие галки «Пользователи должны держать пароли в секрете»
• Проверим, открылись ли нужные нам порты. Открываем командную строку и командой netstat /a /p udp смотрим, открылись ли UDP 1701 UDP 4500 UDP 500.

Создание клиентского подключения для этого способа

• Установим сертификаты на нашего VPN клиента. Копируем с VPN сервера сертификаты, которые создали ранее. Устанавливаем их точно таким же способом, как и на сервере.
• Создадим VPN подключение. Идем в «Центр управления сетями и общим доступом» -> Настройка нового подключения или сети. Далее «Подключение к рабочему месту» -> Использовать мое подключение к Интернет. Вводим адрес нашего VPN сервера. Подключение готово.
• Настроим наше VPN подключение. Имя пользователя и пароль, думаю, вопросов не вызывают. Во вкладке «Безопасность» выбираем тип VPN L2TP/IPsec и в дополнительных параметрах выбираем «Использовать сертификат» и убираем галку «Проверить атрибуты имени сертификата». Шифрование ставим Обязательное и «Разрешаем следующие протоколы» проверки подлинности: MS-CHAPv2. Далее вкладка Сеть -> TCP/IPv4 свойства -> Дополнительно -> Убираем галку «Использовать основной шлюз».
• Если не поднимается подключение. То на Windows 8 стоит попробовать такой ключ реестра HKLM\SYSTEM\CurrentControlSet\Services\IPsec создаем параметр DWORD с именем AssumeUDPEncapsulationContextOnSendRule и значением 2. Для Windows 7/Vista этот параметр нужно создать в HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent

Итоги этого способа

Для Windows клиентов это хороший способ реализации L2TP/IPsec, но когда дело доходит до iOS клиентов, задача расширяется. Проблема в том, что iOS могут подключаться по L2TP только с шифрованием по Заранее подготовленной ключевой фразе (Preshared Key), а по сертификату могут подключаться только к Cisco VPN. Второй способ расскажет, как решить эту проблему.

Windows 7 L2TP/IPsec Preshared Key с ESP 3DES шифрованием и контролем целостности

• Вернемся к чудо-параметру ProhibitIpSec=1. Идем в Реестр, в ветку HKLM\System\CurrentControlSet\Services\Rasman\Parameters и создаем там параметр типа DWORD с именем ProhibitIpSec и присваиваем ему значение 1. После этого необходимо или перезагрузить ОС, или перезапустить службы RemoteAccess и RasMan. Этим действием мы отключаем локальную политику IP безопасности по-умолчанию для IPsec.
• Создадим теперь новую политику безопасности IP. «Выполнить» -> mmc -> Добавить оснастку -> «Управление политикой IP-безопасности» и выбираем Локальный компьютер. Далее «Создать политику IP-безопасности». «Далее» -> Вводим имя -> Галку «Использовать правило по умолчанию» не ставим -> Далее -> «Изменить свойства» галку оставляем. Откроются свойства новой политики. Здесь убрать галку «использовать мастер» и «Добавить». Теперь по порядку о каждой вкладке:
  • Список IP-фильтров. Вводим имя, снимаем галку «Исп. мастер», «Добавить». Адрес источника: «Любой». Адрес назначения: «Любой». Вкладка протокол. В выпадающем списке выбираем UDP. Пакеты ИЗ этого порта: 1701. Пакеты НА любой порт. ОК, ОК и возвращаемся в список IP-фильтров. Здесь вновь созданный фильтр отмечаем «точкой» и переходим на следующую вкладку.
  • Действие фильтра. По аналогии. Имя, галку про мастер, «Добавить». Выбираем «Согласовать безопасность», «Добавить». Выбираем «Шифрование и обеспечение целостности. (ESP)». ОК. Смотрим, чтоб не стояло никаких галок ниже списка методов безопасности. ОК. Аналогично отмечаем точкой и переходим к очередной вкладке.
  • Тип подключения. Все сетевые подключения.
  • Параметры туннеля. Это правило не указывает туннель IPsec.
  • Методы проверки подлинности. Не обращаем пока внимание на Kerberos, жмем «Добавить». Выбираем «Использовать данную строку (Предварительный ключ)» и вводим наш заранее придуманный Ключ. ОК. И теперь можно удалить Kerberos. В этой же вкладке можно добавить проверку подлинности по Сертификату. Процесс генерации и установки Сертификата описан в первом способе.
• Обязательно нужно назначить новую политику IP-безопасности. Правой кнопкой мыши по ней, «Назначить».

Создание клиентского подключения для этого способа

• Отличается от создания клиентского подключения для первого способа только Дополнительными свойствами L2TP/IPsec, где вместо использования сертификата выбираем «… использовать общий ключ».

Доступ к VPN серверу

На роутере я использовал службу Dynamic DNS, т.к. внешний IP динамический. Для возможности подключения необходимо сделать проброс портов (Port Forwarding) для портов UDP 1701 UDP 4500 UDP 500 к нашему VPN серверу. Мы подобрались к финишному этапу, где нас ждет еще одна немаленькая проблема. Дело в том, что Windows 7/8 имеет ограничение на максимальное количество подключений для удаленного доступа, и оно равно 1. Такого ограничения нет на Windows Server. Тут и напрашивается фраза «А на фига ты тут всё это написал?!» Есть два способа решения. Первый: один хороший человек провел немаленькую работу и написал патч, снимающий ограничение для Windows 7 Pro SP1. Здесь подробно описан сам процесс поиска решения и присутствует патч. Второй: использовать Windows Server. Но использовать не так, как написано в большинстве статей, где говорится о назначении серверу Роли «Маршрутизации и удаленного доступа» и использовании специальных оснасток, в которых чёрт ногу сломит, а использовать вышеописанный метод. Он отлично работает на Windows Server без назначения специальных ролей и без ограничений на число подключений.

Переработанный материал:

• Windows XP Pro as a L2TP IPSec VPN Server
• VPN сервер L2TP на Windows 7
• Конфигурация подключений L2TP/IPSec, использующих проверку подлинности на основе предварительного ключа
• Роль сервера удаленного доступа или VPN-сервера: настройка сервера удаленного доступа или VPN-сервера

Создание VPN-подключения в Windows 7

Перед созданием VPN-подключения для протоколов SSTP, L2TP и IKEv2, следует установить корневой сертификат локально на компьютер:

1. Скачайте корневой сертификат Let’s Encrypt по ссылке ;

2. Нажмите Пуск, найдите и запустите mmc.exe;

3. Нажмите Файл -> Добавить или удалить оснастку:

4. Выберите Сертификаты и нажмите Добавить:

5. Установите флаг в строке учетной записи компьютера, нажмите Далее -> Готово -> ОК:

6. В окне Консоль появится пункт Сертификаты (локальный компьютер):

• Выберите его и нажмите правой кнопкой мыши на пункте Доверенные корневые центры сертификации;

• Далее Все задачи -> Импорт

• В окне Мастер импорта сертификатов нажмите Далее -> Обзор -> Выберите скачанный в пункте 1 -> Далее -> Далее -> Готово.

Создание VPN-подключения

1. Выберите Сеть -> Центр управления сетями и общим доступом:

2. Нажмите Настройка нового подключения или сети:

3. Выберите Подключение к рабочему месту и Далее:

4. Нажмите Использовать мое подключение к интернету (VPN) и заполните следующие поля:

• Интернет-адрес — впишите имя VPN-сервера, например vpn.test.ru

• Имя местоназачения — напишите произвольное название подключения

Установите флаг в пункте Не подключаться сейчас, только выполнить установку для подключения в будущем

5. В окне Введите имя пользователя и пароль заполните соответствующие поля;

6. Нажмите Создать, далее Закрыть;

7. В окне Центр управления сетями и общим доступом, выберите в левом верхнем углу Изменение параметров адаптера:

8. Нажмите правой кнопкой мыши на созданное подключение, выберите Свойства:

9. В открывшемся окне выполните следующие действия:

• На вкладке Сеть — снимите отметки со всех пунктов, кроме Протокол Интернета версии 4

• На вкладке Безопасность:

  • в строке Тип VPN выберите нужный тип подключения

  • в строке Шифрование данных выберите обязательное(отключиться, если нет шифрования)

  • в строке Проверка подлинности выберите Разрешить следующие протоколы

  • При необходимости заполните Дополнительные свойства

10. Нажмите OK и закройте Центр управления сетями и общим доступом;

11. В трее нажмите Сеть. Откроется окно с созданным VPN-подключением;

12. Нажмите правой кнопкой мыши по подключению и выберите Подключить.

Ошибки работы VPN-подключений

Если VPN-подключение по протоколам IPSeс в Windows автоматически разрывается через 7 часов 45 минут и при подключении по IKEv2 возникает ошибка «Ошибка сопоставления групповой политики» или ошибка с кодом «13868»

оставьте флаг только в пункте Протокол Microsoft СНАР версии 2 (MS-CHAP v2)

Автор
Сообщение

20 июл 2012, 14:22

Black-Dragon

20 июл 2012, 15:51

Dmitry[kiev]

20 июл 2012, 16:41

Izobretatel

20 июл 2012, 23:07

Dmitry[kiev]

21 июл 2012, 13:02

Black-Dragon

21 июл 2012, 14:06

Dmitry[kiev]

20 авг 2012, 18:46

gvur

29 май 2013, 10:13

Important
IPsec/L2TP is considered a legacy VPN protocol. For modern clients, (Windows since Windows 7, Android since 11, macOS since 10.11, iOS since 9) consider IPsec IKEv2 MSCHAPv2 VPN server instead. Note strongSwan can simultaneously handle legacy IKEv1/L2TP clients and modern pure IKEv2/MSCHAPv2 clients, if both need to be supported

Many operating systems support an L2TP/IPsec VPN out-of-the-box. By combining the confidentiality- and authentication services of IPsec (Internet Protocol security), the network tunneling of the Layer 2 Tunnel Protocol (L2TP) and the user authentication through pppd, administrators can define VPN networks across multiple, heterogeneous systems. This allows setting up a VPN across Android, Windows, Linux, MacOS and other operating systems without any commercial software requirements.

Introduction

IPsec/L2TP is a commonly used VPN protocol used in Windows and other operating systems. All version of Windows since Windows 2000 have support built-in, not requiring an external client (like OpenVPN does) making it very convenient. However, it is significantly harder to set up on the server side on Linux, as there’s at least 3 layers involved: IPsec, L2TP, and PPP.

1. The IPsec setup provides the confidentiality of the network communication and the client (system) authentication
2. With L2TP a tunnel is set up so that the VPN traffic goes over IPsec in a transparent manner
3. The PPP (Point-to-Point Protocol) setup manages the authentication of the users

This guide will not cover setting up DHCP, RADIUS, Samba or a Public Key Infrastructure (PKI). It also does not really cover how to configure Linux clients, although the step to do so can be derived from the guide pretty easily. It does cover some Windows client configuration for the purpose of troubleshooting the server setup.

Assumptions and example settings

For the purpose of this guide, the following assumptions (or sample settings) are used:

• Domain is example.com
• Server name is vpn.example.com
• CA file is called ca.crt
• Server cert is vpn.example.com.crt
• Server key is vpn.example.com.key
• Client cert is client.example.com.crt
• Client key is client.example.com.key

IPsec

The first layer to set up is IPsec. Note IPsec is peer-to-peer, so in IPsec terminology, the client is called the initiator and the server is called the responder.

There are 2 implementations of IPsec in Portage: LibreSwan and strongswan. Both have NAT traversal enabled by default, but if the VPN server is behind NAT and the client is Windows, special client configuration is required.

In the next sections, the different configurations are explained. For each option, document

• how to use PSK for authentication, and
• how to use certificates for authentication

Make sure to pick one (either PSK or certificates). Note there is no provision within the IKEv1 protocol to negotiate PSKs. The only information available to choose which key to use is based on the source and destination IP addresses. Since, in the usual scenario, the responder won’t know the initiator’s IP in advance, everyone must use the same pre-shared key. Therefore, certificates (PKI) are highly recommended over pre-shared keys (PSK), even for only a single user. However generating certificates and creating a PKI is a rather complex process and out of scope of this document, but the app-crypt/easy-rsa package can make it less painful.

For this tutorial, when using certificate based authentication, the necessary certificates are already available.

Option 1: LibreSwan

LibreSwan is a fork of Openswan (which itself a fork of FreeS/WAN). It is actually forked by the remaining original developers of Openswan, however after the original developers left Xelerance, a dispute about the «Openswan» name escalated to a lawsuit, after which the name LibreSwan was taken.

PSK setup for LibreSwan

A shared key must be created. It may either be specified by a quoted string or by a hex number. Based on the next example, PUT_VPN_SERVER_IP should be replaced by the server’s IP address. The domain name can be used, but it is not recommended by the LibreSwan developers. The %any setting allows any client to use this PSK.

FILE /etc/ipsec.d/vpn.example.com.secret

PUT_VPN_SERVER_IP %any : PSK 0x87839cfdab5f74bc211de156d2902d128bec3243
# Or to use a plain text key instead of hex:
# PUT_VPN_SERVER_IP %any : PSK "password_pass"

Then create /etc/ipsec.d/vpn.example.com.conf:

FILE /etc/ipsec.d/vpn.example.com.conf

conn vpnserver
        type=transport
        authby=secret
        ikev2=no
        pfs=no
        rekey=no
        keyingtries=1
        left=%defaultroute
        leftprotoport=udp/l2tp
        leftid=@vpn.example.com
        right=%any
        rightprotoport=udp/%any
        auto=add

Certificate based setup for LibreSwan

LibreSwan requires Network Security Services (NSS) to be properly configured and used for the certificate management. To make things easy, a PKCS#12 bundle should be created containing the server’s secret key, the server’s certificate and the CA certificate.

The bundle can then be imported into the NSS database:

The LibreSwan configuration files will refer to the nickname for the imported objects. Use certutil -L -d /var/lib/ipsec/nss and certutil -K -d /var/lib/ipsec/nss to see what they are.

Above, vpn.example.com is used for the nickname obtained through the certutil -K -d . command.

FILE /etc/ipsec.d/vpn.example.com.conf

conn vpnserver
        type=transport
        authby=rsasig
        ikev2=no
        pfs=no
        rekey=no
        keyingtries=1
        left=%defaultroute
        leftprotoport=udp/l2tp
        leftcert=vpn.example.com
        leftid=@vpn.example.com
        right=%any
        rightprotoport=udp/%any
        rightrsasigkey=%cert
        auto=add

Here, vpn.example.com was the nickname obtained via the certutil -L -d . command.

Option 2: strongSwan

strongSwan is a fork of FreeS/WAN (although much code has been replaced).

While strongSwan supports the legacy (stroke) ipsec.conf configuration mechanism, it introduces a new kind of config file for a new
interface: the Versatile IKE Control Interface (VICI).

To use it, a few directories need to be defined:

mkdir /etc/swanctl/{bliss,conf.d,ecsda,pkcs12,pkcs8,private,pubkey,rsa};\
mkdir /etc/swanctl/x509{,aa,ac,ca,crl,ocsp};\
mkdir /etc/ipsec.d;\
mkdir /etc/ipsec.d/{private,certs,crls,ocspcerts,aacerts,acerts,reqs}; )

PSK setup for strongSwan

A shared key must be created. It may either be specified by a quoted string or by a hex number.

FILE /etc/swanctl/conf.d/vpn.example.com.conf

connections {
	linuxvpn {
		version=1
                proposals=aes128-sha1-modp1024,default
		local-1 {
			auth=psk
			id = @vpn.example.com
		}
		remote-1 {
			auth=psk
		}
		children {
			only {
				mode=transport
				local_ts=dynamic[udp/l2tp]
				rekey_time=0
			}
		}
	}
}
pools {
}
secrets {
	ike-1 {
		secret = "password_pass"
	}
}
authorities {
}

The proposals=aes128-sha1-modp1024,default is for Windows 7 and Android. Without it, they will be unable to connected. See the client notes below.

Certificate based setup for strongSwan

The files must be copied to the correct place:

Finally update the /etc/swanctl/conf.d/vpn.example.com.conf file as follows:

FILE /etc/swanctl/conf.d/vpn.example.com.conf

connections {
	linuxvpn {
		version=1
                proposals=aes128-sha1-modp1024,default
		local-1 {
			auth = pubkey
			certs = vpn.example.com.crt
			id = @vpn.example.com
		}
		remote-1 {
			auth = pubkey
		}
		children {
			only {
				mode=transport
				local_ts=dynamic[udp/l2tp]
				rekey_time=0
			}
		}
	}
}
pools {
}
secrets {
}
authorities {
}

The proposals=aes128-sha1-modp1024,default is for Windows 7 and Android. Without it, they will be unable to connected. See the client notes below.

L2TP

The second layer, Layer 2 Tunneling Protocol (L2TP), is much easier to setup. Like IPsec, L2TP is a peer-to-peer protocol. The client side is called the L2TP Access Concentrator or LAC and the server side is called the L2TP Network Server or LNS.

Restricting L2TP to the IPsec tunnel

Warning
L2TP is insecure, and should not be accessible outside the IPsec connection

iptables

When using iptables, use the following rules to block all L2TP connection outside the ipsec layer:

nftables

When using nftables, use the following script to block all L2TP connection outside the ipsec layer:

#!/sbin/nft -f
 
table ip l2tp-ipsec {
        chain INPUT {
                type filter hook input priority filter; policy accept;
                meta ipsec exists udp dport 1701 counter accept
                udp dport 1701 counter reject
        }
 
	chain OUTPUT {
                type filter hook output priority filter; policy accept;
                rt ipsec exists udp sport 1701 counter accept
                udp sport 1701 counter reject
        }
}

firewalld

Firewalld only blocks incoming connection, not outgoing, and even «rich» rules are not expressive enough to state what is needed for inbound. However, firewalld is designed to live with nftables tables, so the nftables solution above will work and not interfere with it.

Using xl2tpd

Unlike other L2TP servers, xl2tpd can maintain an IP address pool without a DHCP or RADIUS server. This is a layering violation, but for a small setup it is extremely convenient:

FILE /etc/xl2tpd/xl2tpd.conf

[global]
port = 1701
access control = no
 
[lns default]
ip range = 172.21.118.2-172.21.118.254
local ip = 172.21.118.1
require authentication = yes
name = LinuxVPN
pppoptfile = /etc/ppp/options.xl2tpd

To use a RADIUS or DHCP server, leave off the ip range and local ip parts.

Create the options file as well:

FILE /etc/ppp/options.xl2tpd

This line is for Windows’s benefit. Without it, (at least as of Windows 10) Windows will send EAP probes, which pppd rejects, but Windows will insist, rather then fall back. Manual configuration of the VPN connection will be for Windows to use MSCHAPv2 instead of EAP. By limiting Windows’s choice, it will work «out of the box».

If more flexibility is desired and Windows client configuration is not an issue, this line can be dropped.

PPP

The final layer to configure is the Point-to-Point Protocol (PPP) layer. The package to install here is net-dialup/pppd.

Authentication

PPP is used to perform authentication. Unlike the certificate based or PSK authentication, the PPP layer is more for authenticating (and authorizing) the end users’ access to the VPN.

Authentication via chap.secrets

For small users (typically, those wanting to connect their home network from elsewhere), authentication can be done through the chap.secrets file:

FILE /etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
avatar          *       unontainium              *

Note
When authenticating with domains, the client name will need to be mangled appropriately, in this case, EXAMPLE\\avatar.

Warning
/etc/ppp/chap-secrets contains unencrypted passwords, so make sure only root can read or write it

Authentication via Samba

When the machine is part of (or hosting) an MS Domain or AD forest, and the clients are using winbind, then Samba can do the authentication. Add plugin winbind.so to the ppp options. Setting up Samba and pppd to do this is beyond the scope of this document.

Authentication via RADIUS

pppd can use RADIUS. Ensure the radius USE flag is set on net-dialup/ppp. Then add plugin radius.so and plugin radattr.so to the PPP options. Setting up RADIUS is beyond the scope of this document.

Authentication via EAP-TLS

If individual users have certificates (which is not the same as the machine certificate above), then setup pppd to authenticate via EAP-TLS. Ensure the eap-tls USE flag is set on net-dialup/ppp. The require-eap option might need to be included in the PPP options file as well. Setting up pppd to do this is beyond the scope of this document.

Server Notes

Server behind NAT

When the server is behind NAT (Network Address Translation), which is usually the case when the server is hosted after a home router, some specific attention pointers can help in ensuring the IPsec connection is stable and working.

Opening ports

2 ports need to be open:

• UDP port 500 (for ISAKMP)
• UDP port 4500 (for NAT Traversal)

Make sure to forward those to the VPN server.

Also the following Internet Protocols (not ports) need to be allowed as well:

• 50 (ESP)
• 51 (AH)

This might need to be configured on the router side if the router has protocol specific settings (most don’t though).

Client Notes

General

Creating the PKCS12 file

The certificate should be packaged in a PKCS12 package. This can be done through openssl or gnutls:

Be sure to set a password. Some clients (like MacOS) will not open a passwordless p12 file. Some legacy clients can only handle DER encoded p12 files (default for openssl, certtool defaults to PEM). Also remember the certificate belongs to the machine/system, not the user.

Windows

RRAS Error 809: The network connection between your computer and VPN could not be established because the remote server is not responding…

When importing, it’s important to choose «Local Machine» to import to, NOT «Current User». Otherwise, Windows can’t find the certificate and just times out without ever contacting the IPSec server.

Weak proposals

Unlike other clients, Windows prefers the weakest proposal. So if 3des-sha1-modp1024 is offered, it will take it over a better option. On strongSwan, the added proposal aes128-sha1-modp1024 is added for the benefit of legacy clients (Windows 7 and earlier). Older version of Windows won’t offer anything stronger than modp1024 by default. It is possible to allow or force Windows to accept a better proposal through a registry hack. Set DWORD HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256 to 1 to enable Windows to accept aes256-sha1-modp2048, set it to 2 to not allow anything weaker.

If there are no legacy clients (see Android section below), and all Windows clients are at least Windows 10 21H2 (might work with earlier versions) OR have the above registry hack applies, and the server is running strongSwan, the proposal=aes128-sha1-modp1024 may be removed or adjusted.

Enabling split tunneling

By default, Windows connects via full tunnel mode (everything is routed over the VPN), however it’s possible to enable split tunnel in Windows.

Enable split tunneling via the GUI

Go to «Change adapter options» to show the adapters. Right-click the VPN connection, choose Properties, then Networking, then Internet Protocol Version 4 (TCP/IPv4), then Properties, then Advanced, then uncheck «Use default gateway on remote network».

Via PowerShell

Set-VPNconnection -name vpn.example.com -SplitTunneling $true

Substitute vpn.example.com with the given VPN connection name

Server behind NAT

Windows does not automatically support IPsec/L2TP servers behind NAT. See Configure a L2TP/IPsec server behind a NAT-T device to enable support.

RRAS Error 835: The L2TP connection attempt failed because the security layer could not authenticate the remote computer…

The subjectAltName of the server certificate MUST match the server name being connected to. (When connecting by IP address, Windows skips this check).

Mac OS X

MacOS X client require several steps:

1. The CA and client certificates must be imported into the System keychain, not the Login keychain.
2. In the Keychain app, the new CA is untrusted by default, so it must be marked trusted
3. Also note that if corrected after the VPN connection is created, it is necessary to re-select the certificate under Authentication Settings to clear the error.

The «Account Name» should be the PPP username.

Note that Mac OS also checks the subjectAltName vs DNS, if it does not match, it will refuse to connect.

Android

As of Android 12, Android no longer supports IPsec/L2TP. Like Windows, Android won’t offer anything stronger than modp1024, so strongSwan config has an added proposal of aes128-sha1-modp1024. This works even on very old version of Android (at least 4.2). If there are no Android client or other legacy clients (see Windows above), the proposal=aes128-sha1-modp1024 may be removed or adjusted.

iOS

iOS does not support certificate-based authentication for IPSec/L2TP, only pre-shared keys (PSK). (It does support certificate for IPSec/XAuth, however).

External resources

• Using a Linux L2TP/IPsec VPN server from Jacco de Leeuw