Windows server l2tp server ipsec

In this article, we will learn the steps on How to Setup L2TP/IPsec VPN with a Pre-Shared key on Windows Server 2019.

What is a VPN?

A Virtual Private Network (VPN) is a secure network tunnel that allows you to connect to your private network from internet locations. So, you can access and use your internal resources based on assign permission.

Layer 2 Tunneling Protocol (L2TP):

L2TP is the industry standard when setting up secure VPN tunnels. L2TP supports either computer certificates or a Pre-shared key as the authentication method for IPsec. L2TP/IPsec VPN connections provide data confidentiality, data integrity, and data authentication.

Understanding the SSTP Test Lab:

• WS2K19-DC01: Domain Controller and DNS.
• WS2K19-VPN01: Member Server.
• WS10-CLI01: Windows 10 Client Machine.

Step:1 Install Remote Access Server role on Windows Server 2019:

1. The first step is the installation of the Remote Access Server role. Open Server Manager Console and start role and feature installation wizard. Select the Remote Access Server role.

2. On select role services, select DirectAccess and VPN (RAS) role service. Click Next and finish the installation.

3. When the installation finished, click on close.

Step:2 Configure L2TP/IPsec VPN on Windows Server 2019:

4. On Member Server, Open Server Manager. Click on Tools and select Routing and Remote Access Console.

5. Right-click on the Server name and select Configure and Enable Routing and Remote Access.

6. On Welcome screen, click Next.

7. On the Configuration page, select the Custom configuration radio button. Click Next.

8. On select the service page, select VPN Access. Click Next.

9. After clicking on the Finish, it will ask you to start the service. Click on Start service.

10. Now you will see a green up arrow beside your server name.

Step:3 Configure Pre-Shared Key for IPsec Authentication.

To configure the Pre-shared Key for L2TP/IPsec VPN, we need to set up specific settings in the VPN server’s properties section.

11. Right-click on the server name and click on Properties.

12. On the Security tab, select the checkbox Allow Custom IPsec Policy for L2TP/IKEv2 Connection. Specify a strong Pre-Shared Key for L2TP/IPsec VPN connection.

13. Click on IPv4 Tab. Select the Static Address Pool radio button. Click on Add button.

14. Specify the IP address range. Click on OK.

15. Click on Apply to save the changes to the VPN server. It will ask to restart the Routing and Remote Access service. Click on yes to do so.

Step:4 Create AD User and allow dial-in access:

16. On Domain Controller, Open Active Directory Users and Computers snap-ins. Create AD users name Test User1 and Test User2.

17. Enable dial-in access for selected VPN users by opening the user properties and selecting Allow access on the tab Dial-in.

Note: If you want, you can configure Network Policy Server to allow VPN users to connect to the VPN server running on Windows Server 2019.

Step:5 Setup a VPN Connection for L2TP/IPsec VPN:

On Windows 10 client machine, we need to create a new VPN connection.

18. Right-click on the Start button and select Network Connections.

19. On left-pane, click on VPN.

20. Click on add a new VPN connection.

21. Specify the required information for the VPN connection.

• VPN Provider: Windows (Built-in)
• Connection Name: Name of your choice
• Server Name or IP Address: Public IP Address of VPN server
• VPN Type: L2TP/IPsec with Pre-shared key
• Pre-Shared Key: Specify the key which we had assign on VPN Server.

22. Click on Save.

Step:6 Test L2TP/IPsec VPN Connection:

23. Click on VPN connection and select Connect.

24. Specify a username and password to connect the VPN server. Click OK to connect.

25. Verify the VPN connection is successfully connected with the VPN server using the L2TP/IPsec protocol.

Step:7 Monitor L2TP/IPsec VPN Connection:

On Windows 10 Client Machine:

26. Press Windows Key and R key together. At Run menu type ncpa.cpl and press enter to open Network Connection console.

27. Right-click on VPN connection and click on the Status button.

28. Click on details to see information about VPN connection like Authentication Method, Encryption Mod, etc.

On VPN Server:

29. Press Windows Key and R key together. At Run menu type wf.msc and press enter to open Windows Defender Firewall and Advanced Security console.

30. Expand Monitoring, Expand Security Associations. Expand and Click on Main Mode.

You can verify the authentication method and Encryption Standard for IPsec main mode connection.

• Authentication Method: Pre-Shared Key.
• Encryption Standard: AES-CBC 256 Bit
• Integrity Algorithm: SHA-1
• Key-Exchange Mode: Elliptic Curve Diffie-Hellman P-384.

31. Also, check Quick Mode Tunnel Information.

• Local Address: Local IP Address of VPN Server.
• Remote Address: VPN Client IP Address.
• Local Port: UDP 1701
• Remote Port: UDP 1701
• ESP Integrity Mode: SHA-1
• ESP Encryption Mode: AES -CBC 256 Bit

In this post, we have learned the steps to setup L2TP/IPsec VPN with a Pre-shared key on Windows Server 2019 and Windows 10.

Thank you for reading. Have a nice day.

Post Views: 4,895

How to Setup L2TP VPN on Windows Server 2019

• View Larger Image
  

Introduction

In this blog article we are going to discuss about How to setup L2TP VPN over IPSec on Windows Server 2019 using Routing and Remote Access Service server role. A VPN is short form of virtual private network, which gives us a privacy, anonymity and security over public internet. A VPN service masks our ISP IP so your online actions are virtually untraceable. A VPN can also be used to connect computers to isolated remote computer networks that is usually inaccessible, by using the Internet or another intermediate network.

Microsoft servers provided with RRAS server roles for implementing such remote access services. The full form of RRAS is Routing and Remote Access Service. It is a suite of network services in the Windows Server family that enables a server to perform the services of a conventional router.It is also a Windows proprietary server role, that supports remote user or site to site connectivity by using virtual private network or dial-up connections. So using RRAS we can convert a regular Windows Server as VPN server. Microsoft RRAS server and VPN client supports PPTP, L2TP, IPSec, SSTP and IKEv2 based VPN connections. Using RRAS as VPN remote users can connect to their company organisation networks internally and securely over public internet.

L2TP ( Layer 2 Tunneling Protocol )

L2TP or Layer 2 Tunnelling Protocol is a tunnelling protocol which originated by the merger of Microsoft (PPTP) and Cisco L2F. By default L2TP does not provide strong encryption or authentication by itself. So we use another protocol called IPsec in conjunction with L2TP. IPsec stands for Internet Protocol security. The IPsec protocol provides very strong encryption to data exchanged between the VPN server and with the VPN client machine.

When setting up a more secure VPN tunnels we commonly use L2TP along with IPsec. L2TP/IPsec together supports either computer certificates or a Pre-shared key as the authentication method. The Ports need to Open is UDP ports 500, 4500, 50 and 1701.

System Configuration We Used.

Used Windows server 2019 which is covert as a VPN SSTP server.

Used Windows 10 client PC for connecting to Windows VPN server 2019.

Another thing is we are settings up this L2TP VPN on windows server 2019 which only have one Network interface. So this blog article can be implemented on Most of VPS ( Virtual Private Server) provided by Hosting Providers or with the Cloud Windows VMs.

Additionally we are using the Pre-shared key as the authentication method when enabling L2TP/IPsec.

Here I have divided the whole steps in to different parts. Lets get started. Even though we are performing the install on Windows server 2019, you can refer this article for Windows server 2016 and windows server 2012.

Part:1 Install Remote Access Server role on Windows Server 2019

Log into the Windows Server 2019 > Click Windows Start Icon >> Click Server Manager.

Click Add Roles And Features

Click Next

Choose the Installation Type as ” Role based or feature based installation and click Next.

From Server selection, choose “select a server from the server pool” and click Next.

From Server Role choose ” Remote Access” and click Next.

Leave Features section as it is and click Next.

Click Next on Remote Access section.

Under Role Services choose “Direct Access and  VPN (RAS) and Routing and click Next. A popup window will appear for confirming the features that need to be installed for Direct Access and VPN. Confirm it by clicking “Add Features”.

Under Web Server Role (IIS) Section click Next.

Under IIS Role services section leave the default one and Click Next.

Under Final Confirmation section click Install.

The Remote Access server role install will start automatically and normally it will get completed with in few Minutes. Once the installation succeeded click close.

Part:2 Create Additional Loopback Network Adaptor On Windows Server 2019

Its for skipping the error while running Configuring Remote Access Wizard and the error  will be like below.

Less than two network interfaces were detected on this machine. For standard VPN server configuration at least two network interfaces need to be installed. Please use custom configuration path instead.

Under Server Manager  click Tools >> Computer Management.

From Computer Management window Click  Device Manager >> Click VM name from Right side.

Under Actions tab >> Click “Add legacy Hardware”

A add Hardware wizard will open and click Next.

Choose option ” Install the hardware that I manually select from a list ” and click Next.

Choose “Network Adaptors” and click Next.

Choose “Microsoft” as Manufacturer  and ” Microsoft KM-TEST Loopback Adaptor ” as Model. Click Next.

Confirm the Install by clicking Next.

Once the install got completed close the install wizard by clicking Finish.

Now, we can confirm the new network adaptor install from the Computer Management panel itself. For that click Device Manager >> Click VM name >> Expand Network Adaptors, there we can see the newly added LoopBack Network adaptor available.

Part:3 Configuring Remote Access Service VPN on Windows Server 2019

From Server Manager Choose Remote Access >> Right click the Server name >> Choose Remote Access Management.

Under “Direct Access And VPN” Click “Run the Remote Access Setup Wizard”

The Configure remote Access wizard will open Click “Deploy VPN only”

In the Routing and Remote Access Console , right click server name and choose ” configure and Enable routing and remote access ” option.

Click Next on Routing and Remote access server  setup wizard.

Choose Virtual private network( VPN) access and NAT option. Click Next.

In the select Network Interface section, choose the network adaptor where our public IP configured and click Next.

In the IP address Assigned section, choose ” from a specified range of address” and Click Next. Here we are trying to define the private IP address that server give to remote VPN click PC after successful connection.

Click New button.

Give the starting and ending private IP range in the corresponding fields. Click Ok. We are giving IPs starting from 192.168.3.150 to 192.168.3.160.

Now we will see the assigned range and click Next.

In the Do you want to setup this server to work with a radius server question section, select “No, use Routing and Remote Access to authenticate connection requests” and Click next.

Click Finish on Completing the Routing and Remote Access server setup wizard.

Click Ok.

This completes the configuration of Routing and Remote Access Server. Now we can see a green up arrow next to server hostname and which shows the Routing and Remote access server service started successfully.

Part:4 Enabling L2TP/IPsec VPN on Windows Server 2019

Here as we said earlier we enable L2TP/IPsec using Pre-Shared Key through Routing and Remote Access Properties.

In Routing and Remote Access Manager >> right click Server name and choose Properties.

Under Security Tab , Enable “Allow custom IPsec policy for L2TP/IKEv2 Connection”. In the preshared key box give any key. Make sure a its complex one.  Click Apply and OK.

Also note down this key because we need to share this key with the vpn client users. Then only the VPN remote client connections over L2TP/IPsec will be successful. 

Confirm the restart of routing and remote access service by clicking Yes.

Part:5 Allow Remote Access to our VPN server through Public Network Adaptor.

For maintain the access to the VPN server over remote desktop we need to allow the remote access port over our public network adaptor itself through routing and remote access properties section. Otherwise we will loss the access to the server through remote desktop because we only have one Network interface available on server for both VPN traffic and for the remote access.

In the Routing and Remote Access Manager , Expand Server name >> Expand IPv4 >> Choose NAT >> Right Click Our Public Network Adaptor and choose Properties.

Select ” Remote Access” , A pop up window will appear, in the Private Address filed give our server public IP address and click OK.  After that click Apply and OK.

If you have different RDP port, you need to create a new allow rule by clicking add option.

Part:6 Allow VPN remote access for the Users.

In this part we are giving a existing user on VPN server for remote access. Then only if we give the logins of these server users to remote VPN clients, they can successfully connect to server through VPN.

Go to the Computer Management Section >> Expand Local users and Groups >> Choose Users >> Right click a user where we wish to give VPN access and choose properties.

Under “Dial- In” tab >> Choose “Allow Access”. Click Apply and Ok.

Part:7 Allow VPN ports on Windows Firewall.

In this part we are allowing the ports used by the VPN server for communication on windows firewall. Otherwise the remote VPN clients won’t be able to communicate with the VPN server.

Now issue below power shell commands to allow ports in windows firewall.

Now if we look at  the windows firewall inbound section , we can see the ports are allowed.

This Completes the L2TP/IPsec VPN server setup on Windows server 2019. Now Lets Proceed with the Remote VPN Client Windows 10 PC setup and Try to Establish a VPN server connection.

Step:8 Test L2TP/IPsec VPN configuration.

For that , lets add VPN connection. For that open Network and Internet settings.

Under VPN >> Click Add a VPN connection.

Choose VPN Provider as Windows built in

In Connection Name field , give any Name

In Server name or Address field give VPN Server IP

Select VPN type as L2TP/IPsec with Preshared Key

In the Preshared Key box give our same Preshared key used  in the server at the Part:4

Type of sign in info as Username and Password

Gave our VPN username and password. Click Save.

Click connect for our saved VPN client settings.

Now we will see the VPN status as connected.

Two other ways to confirm the VPN connection is successful is go back to VPN server 2019 and Open Routing and Remote Access Manager >> From there Expand our server name >> Choose Remote Access client, and in the right side we can see a active connection.

Another option to confirm the successful VPN connection is , open a browser in Windows 10 PC and search the what is my IP and it will show the public ISP IP as VPN server IP. Which means all the internet traffic from client side is routing through our VPN server.

This Concludes the settings up L2TP/IPsec VPN  on Windows server 2019. I hope this blog article is informative. Leave your thoughts in the comment box.

Share This Story, Choose Your Platform!

By admin|2021-12-16T09:36:22+00:00September 26th, 2021|Windows|

Related Posts

Платформа Windows Server остается одной из наиболее популярных серверных платформ, в том числе и для реализации решений удаленного доступа. Служба маршрутизации и удаленного доступа (RRAS) позволяет быстро и достаточно просто развернуть VPN-сервер практически для любых нужд. Сегодня мы еще раз вернемся к этому вопросу и рассмотрим, как создать на базе Windows Server PPTP или L2TP сервер для удаленного доступа, как наиболее востребованный сценарий на сегодняшний день.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Почему именно эти типы подключения? Потому что они наиболее просты в реализации и поддерживаются широким спектром клиентов что называется «из коробки». Однако следует помнить, что PPTP не является на сегодняшний день безопасным и имеет слабые алгоритмы шифрования, но при этом он наиболее производительный из VPN-протоколов и имеет минимальные накладные расходы. Кроме того, его поддержка исключена из операционных систем Apple.

Оптимальным вариантом будет использование L2TP/IPsec подключения, которое сочетает в себе простоту, поддержку практически любыми клиентскими ОС и устройствами вместе с неплохим уровнем безопасности, обеспечиваемым IPsec. А так как настройка сервера для этих видов подключений практически идентична, то мы решили объединить их в одну статью.

Установка и настройка службы маршрутизации и удаленного доступа

Для начала работы с VPN в среде Windows Server вам потребуется установить роль Удаленный доступ, это делается стандартными средствами и не должно вызвать затруднений.

В Службах ролей выбираем Маршрутизация, роль DirectAccess и VPN (RAS) будет добавлена автоматически.

После установки роли Удаленный доступ ее следует настроить, проще всего это сделать, нажав на значок с желтым треугольником в Диспетчере серверов и выбрать в появившемся списке пункт Запуск мастера начальной настройки.

В появившемся окне выбираем пункт Развернуть только VPN.

Затем в оснастке Маршрутизация и удаленный доступ щелкаем правой кнопкой мыши по строке с сервером и выбираем в выпадающем меню Настроить и включить маршрутизацию и удаленный доступ.

После чего появится хорошо знакомое окно мастера настройки, предлагающее сразу несколько типовых конфигураций, однако у него есть свои особенности, например, если у вашего сервера всего один сетевой интерфейс, то настроить вариант Удаленный доступ (VPN или модем) мастер вам не даст. Поэтому выбираем самый нижний пункт — Особая конфигурация.

В следующем окне достаточно поставить галочку Доступ к виртуальной частной сети (VPN) и завершить работу мастера.

После завершения работы мастера служба Маршрутизации и удаленного доступа будет запущена и можно приступить к настройке сервера удаленного доступа. Если же данная служба у вас уже установлена и настроена в иной конфигурации, то щелкните правой кнопкой по строке сервера и выберите Свойства, в открывшемся окне на закладке Общие установите опции: IPv4-маршрутизатор локальной сети и вызова по требованию и IPv4-сервер удаленного доступа.

Настройка PPTP и/или L2TP сервера удаленного доступа

Откроем оснастку Маршрутизация и удаленный доступ и перейдем к свойствам сервера через одноименный пункт в меню правой кнопки мыши, прежде всего убедимся, что настройки на закладке Общие соответствуют приведенным на скриншоте выше. Затем переключимся на закладку Безопасность и убедимся, что в качестве Поставщика службы проверки подлинности стоит Windows — проверка подлинности, а Поставщик учета — Windows-учет, еще ниже установим флаг Разрешить пользовательские политики IPsec для L2TP- и IKEv2-подключения и в поле Общий ключ укажите парольную фразу для предварительного ключа.

Нажав на кнопку Методы проверки подлинности откроем окно, в котором выберем только Протокол EAP и Шифрованная проверка (Microsoft, версия 2, MS-CHAP v2), остальные протоколы не являются безопасными и должны быть отключены.

На закладке IPv4 укажем опцию Назначение IPv4-адресов — Статический пул адресов и добавим новый пул для выдачи адресов из него удаленным клиентам. Количество адресов должно быть не менее количества клиентов плюс один адрес, так как первый адрес из пула присваивается серверу. Что касается самого диапазона адресов, то его выбор зависит от конфигурации сети, если вы будете использовать маршрутизацию, то он не должен пересекаться с локальной сетью, если же хотите использовать ProxyARP, то наоборот, должны выделить принадлежащий локальной сети диапазон. В нашем случае используется второй вариант.

На этом настройка сервера может считаться законченной, следующим шагом следует разрешить подключения нужным пользователям, для этого в свойствах пользователя перейдем на закладку Входящие звонки и в блоке Права доступа к сети укажем Разрешить доступ. Теперь указанный пользователь может подключаться к нашему серверу используя свои учетные данные.

Также не забудьте проверить настройки брандмауэра, чтобы убедиться, что правила Маршрутизация и удаленный доступ GRE-входящий, PPTP-входящий (для PPTP) и L2TP-входящий (для L2TP) включены.

Proxy ARP

Сетевое взаимодействие в пределах одной IP-сети осуществляется на канальном (L2) уровне, в сетях Ethernet для этого используются MAC-адреса устройств. Для того, чтобы выяснить MAC-адрес узла по его IP применяется протокол ARP (Address Resolution Protocol), использующий широковещательные запросы, на которые отвечает только обладатель указанного IP-адреса. Выдавая удаленным клиентам адреса из диапазона основной сети мы как бы помещаем их в общую IP-сеть, но так как VPN — это соединение точка-точка, ARP-запросы от удаленных клиентов в сеть попадать не будут, единственный узел который их получит — сам VPN-сервер.

Для решения данной проблемы используется технология Proxy ARP, которая, как понятно из названия, представляет прокси-сервер для ARP-запросов, позволяя удаленным клиентам работать так, как будто бы они действительно находились в одной сети, без каких-либо дополнительных настроек. При использовании RRAS никаких дополнительных действий делать не нужно, Proxy ARP работает по умолчанию.

VPN-сервер за NAT

Так как мы используем Windows Server, то с большой долей вероятности он будет находиться внутри сетевого периметра и нам понадобится настроить проброс портов на маршрутизаторе. Для этого нужно четко понимать, как работает VPN-соединение и какие порты и протоколы следует передавать.

Начнем с PPTP, прежде всего клиент устанавливает управляющее TCP-соединение на порт 1723, затем, после успешной аутентификации создается соединение для передачи данных с использованием протокола GRE.

Таким образом для работы PPTP-сервера за NAT нужно:

• пробросить порт 1723 TCP
• разрешить прохождение GRE-трафика

С первым понятно, а вот с GRE могут возникнуть затруднения. Если вы используете маршрутизатор на базе Linux, то обратитесь к следующей нашей статье, если оборудование Mikrotik, настроенное по нашей инструкции, то достаточно пробросить только 1723 TCP, прохождение GRE будет разрешено конфигурацией брандмауэра, в остальных случаях следует обратиться к документации на свою модель маршрутизатора.

С L2TP сложнее, точнее не с ним самим, а с IPsec, который не поддерживает NAT. Для обхода этих ограничений используется протокол NAT-T, который инкапсулирует пакеты IPsec в UDP, позволяя успешно проходить через NAT. Поддержка данного протокола включена по умолчанию практически во всех ОС, кроме Windows. Для включения поддержки NAT-T следует внести изменения в реестр, найдите ветку:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent

И создайте в ней параметр DWORD c именем AssumeUDPEncapsulationContextOnSendRule и значением 2.

Это можно быстро сделать при помощи PowerShell:

Set-ItemProperty -Path "HKLM:SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -Type DWORD -Value 2 -Force

После чего систему следует перезагрузить. Данные изменения нужно внести как на сервере, так и на клиенте.

При установлении L2TP/IPsec соединения между узлами прежде всего создается зашифрованный IPsec-канал, для этого используется протокол обмена ключами IKE (порт 500 UDP) и протокол NAT-T (порт 4500 UDP), затем уже внутри безопасного IPsec-соединения поднимается L2TP-туннель на порт 1701 UDP и происходит аутентификация пользователя.

Обратите внимание, аутентификация пользователя в L2TP, в отличии от PPTP, происходит внутри защищенного IPsec-канала, что делает данный тип соединения более безопасным.

Таким образом для работы L2TP/IPsec сервера за NAT нужно:

• пробросить порт 500 UDP
• пробросить порт 4500 UDP
• внести изменения в реестр для включения NAT-T как на сервере, так и на клиенте (только для Windows)

Вопреки распространенному заблуждению порт 1701 UDP пробрасывать не нужно.

Настройка VPN-подключения в Windows

С одной стороны это простой вопрос, с другой — имеются определенные тонкости, на которые мы как раз и обратим внимание. В Windows 10 для первичной настройки VPN-подключения служит современное приложение, которое предельно простое и не охватывает дополнительных настроек.

Поэтому после того, как вы создадите в нем подключение, следует перейти к его свойствам и на закладке Параметры — Параметры PPP установить в открывшемся окне все флажки. Это позволит использовать все возможности протокола PPP и получить оптимальное качество связи. Обратите внимание, что данные опции должны также поддерживаться со стороны сервера, в противном случае их использование в одностороннем порядке может привести к ошибкам при установлении связи.

Затем на закладке Безопасность установите в Шифрование данных — обязательное, а в пункте Проверка подлинности выберите Протокол расширенной проверки подлинности (EAP).

И наконец на закладке Сеть перейдите в свойства протокола IP версии 4 (TCP/IP 4) и нажмите Дополнительно, в открывшемся окне снимите флаг Использовать основной шлюз в удаленной сети, в противном случае весь исходящий трафик будет направлен в туннель.

После чего можем подключаться и пробовать получить доступ к ресурсам удаленной сети, если вы все сделали правильно, то проблем возникнуть не должно.

Настройка VPN-подключения в Linux

В данной части нашего материала мы будем рассматривать настройку клиентских Linux-систем при помощи графического окружения и Network Manager, настройка серверных систем выходит за рамки текущей статьи. В качестве примера мы будем использовать Ubuntu, но все сказанное будет справедливо для любых основанных на Debian систем, а с некоторыми уточнениями — для любых дистрибутивов.

Поддержка PPTP присутствует практически в любом дистрибутиве по умолчанию. Достаточно перейти в Настройки — Сеть и добавить новое VPN-подключение.

Заполняем основные настройки: адрес сервера, имя и пароль пользователя.

Затем нажимаем кнопку Дополнительно и в открывшемся окне в разделе Аутентификация оставляем только MSCHAPv2, обязательно включаем Использовать шифрование MPPE и выбираем ниже 128 бит (наиболее защищенное), также устанавливаем флаг Включить Stateful Encryption для уменьшения накладных расходов на шифрование. Флаги сжатия оставляем включенными.

Закрываем данное окно с сохранением данных и переходим на закладку IPv4, где в разделе Маршрутизация устанавливаем флаг Использовать это подключение только для ресурсов этой сети, в противном случае в туннель пойдет весь трафик узла.

На этом настройка подключения завершена, можно подключаться.

Для работы с L2TP потребуется установить дополнительные пакеты:

apt install network-manager-l2tp-gnome

После чего в доступных типах подключения появится L2TP. Основные настройки ничем не отличаются от PPTP, также адрес сервера, имя и пароль пользователя.

Затем откроем Настройки PPP, в разделе Аутентификация также выберем только MSCHAPv2, а вот опции шифрования оставляем выключенными, так как чистый L2TP шифрования не использует, для защиты канала здесь применяется IPsec. Флаги сжатия также оставляем установленными по умолчанию.

Затем переходим в Настройки IPsec, это наиболее сложная и ответственная часть настроек, так как от них напрямую зависит безопасность соединения. В поле Pre-shared key введите Общий ключ, а ниже потребуется указать используемые шифры. Большинство материалов в сети интернет копируют друг у друга откровенно старые и слабые наборы шифров, что не соответствует реалиям сегодняшнего дня, хотя соединение с такими значениями будет работать. Мы же будем использовать максимально безопасные значения, для этого в поле Phase1 Algorithms укажите aes256-sha1-ecp384, а в поле Phase2 Algorithms — aes256-sha1.

Также имеет смысл установка флага Enforce UDP Encapsulation, который принудительно включает NAT-T, в случае если вы точно знаете, что ваш сервер находится за NAT, без этой опции протокол включается автоматически при обнаружении первого устройства с NAT.

Сохраняем настройки и переходим на вкладку IPv4, где также в разделе Маршрутизация ставим флаг Использовать это подключение только для ресурсов этой сети, чтобы направить в туннель только трафик для сети офиса.

На этом настройка закончена, можно подключаться.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

В этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя

Среда исполнения

В рассматриваемом примере будет создан Windows NLB кластер из двух виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 R2 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2012 R2 Standard EN.

Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее.

Серверам присвоены имена – KOM-AD01-VPN01 и KOM-AD01-VPN02.

Создаваемый в процессе описания NLB-кластер будет использовать имя KOM-AD01-VPNCL.

В качестве поставщика аутентификации будут использоваться два отдельных сервера внутри локальной сети с заранее установленной и настроенной ролью Network Policy and Access Services (RADIUS) с именами KOM-AD01-NPS01 и KOM-AD01-NPS02.

Аутентификация для протокола L2TP/IPsec с использованием сертификатов потребует наличия Доменного или Автономного Центра сертификации (ЦС) для создания цифровых сертификатов для VPN-клиентов. В рассматриваемой конфигурации а качестве Автономного ЦС будет использоваться отдельный сервер внутри локальной сети с именем KOM-AD01-CA01  

Упрощённая схема взаимодействия компонент конфигурации будет выглядеть следующим образом:

Данная конфигурация построена по принципу избыточности основных функциональных компонент. Если потребности в наличии такой избыточности нет, то описанную ниже конфигурацию вполне можно реализовать в рамках одного виртуального сервера, совместив соответствующие серверные роли на нём.

Так как планируемая конфигурация получается многокомпонентной, то во избежание лишних сложностей, мы не будем пытаться настроить весь функционал сразу. Вместо этого мы сначала настроим базовый функционал PPTP VPN и протестируем его. Если на этом этапе проблем выявлено не будет, следующим этапом приступим к связке сервера VPN c RADIUS, и снова проверим результат. В случае успешной проверки авторизации через RADIUS перейдём к настройке VPN-сервера и VPN-клиентов для поддержки протокола L2TP/IPsec. Снова проверим результат, и в случае успеха перейдём к окончательному этапу – созданию второго VPN-сервера аналогичной конфигурации и построению NLB-кластера из двух VPN-серверов. Таким образом, план развёртывания конфигурации будет следующим:

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)
1.1. Настройка виртуальной машины
1.2. Установка роли Remote Access
1.3. Настройка службы Routing and Remote Access
1.4. Настройка правил Windows Firewall
2. Проверка подключения по протоколу PPTP
3. Создание доменных групп доступа
4. Работа с серверами NPS/RADIUS
4.1. Создание основной сетевой политики на сервере NPS
4.2. Создание дополнительной сетевой политики NPS для PPTP-подключений
4.3. Добавление информации о VPN-сервере на сервер RADIUS
5. Привязка VPN-сервера к серверам RADIUS
6. Проверка подключения по протоколу PPTP с использованием RADIUS
7. Работа с сертификатами
7.1. Установка корневого сертификата ЦС на VPN-сервере и клиенте.
7.2. Создание сертификата VPN-сервера
7.3. Создание сертификата VPN-клиента
8. Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec
9. Настройка второго VPN-сервера (KOM-AD01-VPN02)
10. Создание NLB-кластера из двух VPN-серверов
11. Проверка работы NLB-кластера
12. Разработка инструкций для пользователей.

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)

1.1 Настройка виртуальной машины

Устанавливаем на виртуальный сервер ОС Windows Server 2012 R2 Standard EN и все последние обновления Windows Update.

Виртуальный сервер имеет два сетевых контроллера. В ОС условно назовём относящиеся к этим контроллерам сетевые интерфейсы — LAN и WAN. Интерфейс LAN будет смотреть в локальную сеть (либо в DMZ) и настроен следующим образом:

Шлюз по умолчанию на интерфейсе LAN не указываем.

Интерфейс WAN будет направлен в Интернет. В свойствах интерфейса желательно выключить все компоненты кроме TCP/IPv4. Шлюз по умолчанию задан. 

Чтобы при такой конфигурации сетевых интерфейсов сервер был доступен из локальной сети, создадим в системе постоянный маршрут в локальную сеть через интерфейс LAN:

route -p ADD 10.0.0.0 MASK 255.0.0.0 10.160.20.1
route PRINT

1.2. Установка роли Remote Access

Открываем оснастку Server Manager, выбираем область настроек Local Server, в верхнем меню выбираем Manage > Add Roles and Features. В мастере добавления ролей выбираем тип установки на основе ролей — Role-based or feature-based installation

Далее выбираем сервер из пула серверов…

На шаге выбора ролей включаем роль Remote Access

Шаг Features пропускаем без внесения изменений.
На шаге выбора служб включаемой роли выберем службу DirectAccess and VPN (RAS)

При этом откроется окно добавления дополнительных компонент связанных с выбранной службой. Согласимся с их установкой нажав Add Features

Роль Web Server Role (IIS) будет при этом добавлена в мастер добавления ролей. Соответствующий появившийся шаг мастера  Web Server Role (IIS) и зависимые опции Role Services пропускаем с предложенными по умолчанию настройками и запускаем процесс установки, по окончании которого будет доступна ссылка на мастер первоначальной настройки служб Remote Access – Open the Getting Started Wizard

Можно вызвать мастер настройки RAS щёлкнув по соответствующей ссылке здесь, либо позже из оснастки Server Manager:

Так как настройка DirectAccess в контексте нашей задачи не нужна, в окне мастера выбираем вариант конфигурирования только VPN – Deploy VPN only

1.3. Настройка службы Routing and Remote Access

Из Панели управления открываем оснастку Administrative Tools \ Routing and Remote Access, выбираем в дереве навигации имя сервера и открываем контекстное меню. Выбираем пункт Configure and Enable Routing and Remote Access

Откроется окно мастера Routing and Remote Access Server Setup Wizard, в котором мы выбираем пункт Custom configuration 

На следующем экране мастера включаем службу VPN access.

На следующем экране нажимаем кнопку Finish и соглашаемся с предложением запуска службы – нажимаем кнопку Start service

После этого в консоли Routing and Remote Access снова выбираем наш сервер и, открыв контекстное меню, выбираем пункт Properties

В открывшемся окне свойств на закладке General убеждаемся в том, что включена маршрутизация IPv4 Router – LAN and demand-dial routing, а также активен функционал сервера удалённого доступа – IPv4 Remote access server  

Переключимся на закладку Security и посмотрим настройки аутентификации по умолчанию. Не будем их пока менять (вернёмся к ним позже). Использование провайдера аутентификации Windows Authentication в доменной среде подразумевает то, что к серверу удалённого доступа смогут подключиться любые доменные пользователи, у которых в свойствах учетной записи включено право удалённого доступа (проверить это можно в оснастке Active Directory — Users and Computers для учетной записи доменного пользователя на закладке Dial-In параметр Network Access Permission должен быть определён как Allow access)

Далее переключимся на закладку IPv4 и включим опцию пересылки трафика – Enable IPv4 Forwarding, чтобы наш VPN-сервер смог пересылать трафик VPN-клиентов в локальную сеть и обратно.

В свойстве назначения IP адресов подключающимся VPN-клиентам выберем использование статического пула — Static address pool (это рекомендуемая конфигурация в случае если мы планируем использовать несколько VPN-серверов в кластере NLB). Выделим для VPN-клиентов отдельную подсеть класса “C”, например 10.160.50.0/24. Так как мы планируем использовать два VPN-сервера, разделим эту подсеть на две непересекающихся части. Первую половину сети пропишем на этом VPN-сервере, вторую в дальнейшем на втором VPN-сервере.

Отключим опцию Enable broadcast name resolution, чтобы отбросить широковещательные запросы VPN-клиентов. В нижнем параметре Adapter (сетевой интерфейс, с которого клиентам будут выдаваться настройки DNS) выберем интерфейс LAN.

При этом также не стоит забывать и о том, что для успешной маршрутизации трафика из указанного диапазона сети VPN-клиентов в локальную сеть и обратно, на маршрутизирующем сетевом оборудовании в локальной сети необходимо создать статический маршрут, типа:

Весть трафик предназначенный для сети 10.160.50.0/25 отправлять на хост 10.160.20.11

Как уже сказано, если VPN-серверов планируется несколько, то назначаемые статические сегменты для VPN-клиентов не должны пересекаться друг с другом на разных VPN-серверах. И для каждого из выделенных диапазонов IP адресов на маршрутизирующем оборудовании локальной сети нужно будет аналогичным образом создать соответствующие маршруты.

Сохраним сделанные настройки. При сохранении получим предупреждение о том, что для вступления новых настроек в силу, потребуется выполнить перезапуск служб маршрутизации и удаленного доступа…

Вернёмся в консоль, выберем узел Ports и в контекстном меню выберем Properties. Здесь мы сможем выполнить настройку допустимого количества портов, на которые смогут подключаться VPN-клиенты для каждого отдельно взятого протокола.

Как видим, в конфигурации по умолчанию создано множество портов для разных VPN-протоколов. В нашем примере будет использоваться только 2 протокола – PPTP и L2TP. Основным протоколом для VPN-соединений будет L2TP с количеством портов не более, чем количество ранее выделенных в статическом пуле IP адресов. Вспомогательным протоколом будет PPTP с ограниченным количеством портов, например от 1 до 3. Протокол PPTP будет использоваться исключительно для разовых кратковременных соединений, необходимых VPN-клиентам для подключения к серверу Центра сертификации и получения сертификата компьютера, необходимого для дальнейшей настройки L2TP/Ipsec подключения. Для начала настроим протокол PPTP, выбрав его из списка и нажав кнопку Configure   

В открывшемся окне в параметре Maximum ports введём ограниченное количество портов.

По аналогии настроим порты для протокола L2TP указав максимально возможное количество  клиентских подключений, например 125, исходя из того, что на данный сервер ранее нами выделена половина сети класса “C”. Для всех других протоколов, которые мы не планируем настраивать и использовать, например SSTP или IKEv2, лучше вообще обнулить значение количества портов.

В конечном итоге мы получим примерно такую настройку портов:

Сохраняем настройки и убеждаемся в том, что в консоли в разделе Ports информация обновилась, и теперь там отображается именно то количество портов, которое мы назначили.

1.4. Настройка правил Windows Firewall

Так как в нашем случае сервер имеет прямое подключение к сети Интернет, очень важно выполнить максимально строгую настройку правил Windows Firewall. Выключаем бОльшую массу правил включённых по умолчанию. Оставляем включёнными лишь правила относящиеся к службам RAS по портам, которые будут нами использоваться. Правила удалённого доступа к серверу по таким протоколам как WinRM и RDP ограничиваем профилем Domain и диапазоном локальной сети, из которого разрешается удалённый доступ к серверу.

Описание правил фаервола необходимых для работы того или иного VPN-трафика можно найти в документе Configure a Firewall for VPN Traffic, а также в блоге  Routing and Remote Access Blog —  Which ports to unblock for VPN traffic to pass-through?. Согласно этим документам, к представленным по умолчанию в системе правилам, которые появляются после установки роли Remote Access, нам нужно ещё дополнительно открыть порты UDP 500 и 4500. Добавим два разрешающих правила для фаервола с помощью PowerShell:

New-NetFirewallRule -DisplayName "Routing and Remote Access (Allows IKE traffic to the VPN server)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "500"

New-NetFirewallRule -DisplayName "Routing and Remote Access (Allows IPsec NAT-T traffic from the VPN client to the VPN server.)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "4500"

2. Проверка подключения VPN-клиента по протоколу PPTP

На данном этапе первоначальная настройка первого VPN-сервера выполнена и он уже готов принимать клиентские подключения. Поэтому теперь можно проверить подключение по протоколу PPTP. Согласно описанной нами конфигурации, сделать это можно в том числе и с клиентского компьютера внутри локальной сети. Пошаговое описание процесса создания VPN-подключения на клиенте под управлением Windows можно найти в п.12 данной статьи. После того как на клиентском компьютере VPN-подключение создано, откроем его свойства и на закладке “Безопасность” выберем тип VPN – PPTP 

На закладке “Сеть” выберем протокол TCP/IPv4 и откроем его “Свойства”

В окне свойств нажмём кнопку “Дополнительно” и отключим опцию “Использовать основной шлюз в удалённой сети”. Это нужно сделать для того, чтобы при подключении с клиента локальной сети у нас не возникло проблем с уже работающими сетевыми приложениями на клиентском компьютере во время проведения теста подключения.

Сохраним изменения и попробуем выполнить подключение к VPN-серверу.

Если проверка подключения из локальной сети прошла успешно, можно протестировать подключение с внешнего VPN-клиента из Интернет также по протоколу PPTP. Таким образом мы убедимся в том, что правила Windows Firewall на VPN-сервере настроены правильно и служба RAS успешно выполняет подключение VPN-клиентов, выдаёт им при этом правильные настройки IP, и корректно маршрутизирует трафик от VPN-клиента в локальную сеть и обратно. Если все указанные проверки прошли успешно, можно продолжить работу по плану и перейти к настройке интеграции VPN-сервера с сервером RADIUS.

3. Создание доменных групп доступа

Для дальнейшей настройки аутентификации VPN-клиентов через RADIUS нам потребуется создать в домене Active Directory (AD) группу безопасности, в которую будут включены учетные записи пользователей, которым мы хотим предоставить доступ к VPN. В нашем примере это будет доменная локальная группа безопасности KOM-AD01-SRV-NPS-VPN-Users 

В дальнейшем, для предоставления какому-либо пользователю домена доступа к VPN, его учетную запись будет достаточно включить в эту группу безопасности. При этом мы настроим сервер RADIUS таким образом, что пользователь сможет подключаться к VPN вне зависимости от того, каким образом выставлены ранее упомянутые настройки в свойствах его учетной записи в AD на закладке Dial-In.

4. Работа с серверами NPS/RADIUS

Как уже отмечалось в самом начале, мы будем использовать возможности служб Network Policy Server (NPS) для того, чтобы более гибко управлять параметрами подключения VPN-клиентов. Для этой цели на каждом RADIUS-сервере мы создадим по две сетевые политики (Network Policy). Первая политика будет использоваться как основная для всех клиентов. Вторая политика будет применяться к клиентам в том случае, если они используют подключение по протоколу PPTP и будет иметь ряд настроек, которые будут жёстко ограничивать VPN-сессии такого рода. Далее мы рассмотрим соответствующую настройку RADUS сервера на примере сервера KOM-AD01-NPS01. На втором сервере KOM-AD01-NPS02 вся настройка должна быть выполнена абсолютно также как и на первом.

4.1. Создание основной сетевой политики на сервере NPS

На сервере KOM-AD01-NPS01 открываем оснастку Administrative Tools \ Network Policy Server. В дереве навигации оснастки выбираем пункты NPS >  Policies > Network Policies. Открываем контекстное меню (либо меню действий Action в главном меню) и выбираем пункт New.

Откроется мастер создания новой сетевой политики New Network Policy

Вводим имя политики, например KOM-AD01-SRV-NPS-VPN-Users Policy, и выбираем тип соединения Type of network access server — Remote Access Server (VPN-Dial up)

На следующем шаге мастера Specify Conditions нажимаем Add, чтобы добавить новое условие для применения политики. В открывшемся окне выбора условий найдём User Groups и нажмём Add.

Затем нажмём Add Groups и введём имя доменной группы безопасности, которую мы создали ранее в п.3 (KOM\KOM-AD01-SRV-NPS-VPN-Users).

Перейдём к следующему шагу мастера Specify Access Permission где определим, что данная политика является разрешающей доступ, выбрав пункт Access granted

Параметр Access is determined by User Dial-in properties (which override NPS policy) оставим без изменений, так как работает он в этом мастере как-то не совсем вменяемо. Заметил это не только я один, но есть тому и другие свидетельства, например NPS new Network Policy wizard incorrectly sets «Ignore User Dial-In Properties». После создания политики мы вернёмся в её свойства и выполним дополнительную соответствующую настройку.

На следующем шаге Configure Authentication Methods обозначим методы аутентификации доступные для подключающихся VPN-клиентов, подпадающих под правила обозначенные ранее (в нашем случае это пока только членство в доменной группе безопасности).

Убедимся в том, что включён метод MS-CHAP-v2 и отключим прочие устаревшие и менее безопасные методы аутентификации, такие как MS-CHAP

На следующем шаге мастера Configure Constraints при необходимости можно настроить ограничения для подключений, такие как например ограничение простоя сессии или общий таймаут сессии. В данном случае эти ограничения нам не нужны и поэтому настройки на этом шаге мы оставляем без изменений.

На следующем шаге мастера Configure Settings в разделе настроек Encryption оставим включенным шифрование MPPE 128-bit и MPPE 56-bit (при необходимости). В большинстве случаев рекомендуется оставлять включённым только шифрование максимально возможной силы (MPPE 128-bit), но если будут проблемы с подключением каких-то устаревших клиентов, то возможно потребуется включить и менее слабые методы шифрования. Например, если планируется подключение клиентов на базе Windows XP, то при использовании протокола L2TP/Ipsec возможно потребуется включение поддержки 56-битного шифрования. Практические эксперименты с VPN-клиентом на базе Windows XP, настроенным в конфигурации по умолчанию подтвердили это.

На финальном шаге Completing New Network Policy ещё раз проверим все настройки, которые будут включены в создаваемую политику, и нажмём Finish

Открываем свойства только что созданной политики и на первой закладке Overview включим опцию Ignore user account dial-in properties

Таким образом, возможность удалённого подключения будет регулироваться условиями данной политики NPS, даже несмотря на то, как настроены параметры удалённого входа в свойствах учётной записи пользователя в AD на закладке Dial-in

То есть, в данном примере, пользователь Петя Резинкин сможет подключиться в VPN, даже не смотря на то, что в свойствах его доменной учетной записи выбрана опция Deny access, при условии, что эта учетная запись включена в ранее указанную в политике доменную группу безопасности KOM\KOM-AD01-SRV-NPS-VPN-Users.

***

Если у нас более одного сервера RADIUS, дублируем созданную политику с идентичными настройками на дополнительных серверах.

4.2. Создание дополнительной сетевой политики NPS для PPTP-подключений

Созданная ранее сетевая политика будет использоваться как основная политика “по умолчанию” для всех подключающихся VPN клиентов. Как уже было сказано ранее, наша конфигурация подразумевает то, что VPN-клиенты в качестве основного протокола будут использовать L2TP/Ipsec, а для его первоначальной настройки каждому клиенту хотя бы один раз потребуется кратковременная PPTP-сессия. PPTP-сессия в нашем случае нужна для того, чтобы подключиться клиенту к одному единственному ресурсу локальной сети – Центру сертификации для получения сертификата для клиентского компьютера. Так как протокол PPTP является более устаревшим и менее защищённым чем L2TP/Ipsec, нам нужно на сервере NPS (RADIUS) создать ещё одну сетевую политику, с помощью которой будут заданы жёсткие ограничения для PPTP соединений. То есть, в рамках нашей задачи, любая PPTP-сессия будет разрешать трафик исключительно до нескольких хостов локальной сети (Сервер ЦС и DNS-серверы) и будет при этом ограничена по времени, которого достаточно для того, чтобы сформировать запрос на получение сертификата в ЦС и получение автоматически выданного цифрового сертификата клиентского компьютера.

Итак, создадим дополнительную сетевую политику и присвоим ей имя, например KOM-AD01-SRV-NPS-VPN-Users Policy (PPTP). При создании политики в качестве дополнительного условия на шаге мастера Specify Conditions добавим условие по типу туннеля Tunnel Type равное значению Point-to-Point Tunneling Protocol (PPTP).

На шаге мастера Configure Constraints в разделе Session Timeout включим признак разрыва сессии по истечении определённого времени — Disconnect after the following maximum time. Укажем значение, например, в 30 минут. Этого времени более чем достаточно для получения сертификата из ЦС.

Далее, на следующем шаге мастера Configure Settings в разделе настроек IP Filters нажмём кнопку Input Filters, чтобы настроить фильтрацию трафика поступающего от VPN-клиента в сторону локальной сети

В открывшемся окне создадим правила, согласно которых мы разрешаем доступ VPN-клиента по всем портам к серверу ЦС (для запроса и получения сертификата), а также трафик по протоколу UDP и порту 53 к DNS-серверам локальной сети (для работы механизма разрешения имён хостов локальной сети).

После того, как политика создана, настроим приоритет обработки политик таким образом, чтобы только что созданная политика для PPTP соединений (KOM-AD01-SRV-NPS-VPN-Users Policy (PPTP)) имела более высокий приоритет, то есть обрабатывалась бы RADIUS-сервером раньше, чем основная политика для VPN-клиентов по умолчанию (KOM-AD01-SRV-NPS-VPN-Users Policy).

Таким образом, если любой VPN-клиент подключится по протоколу PPTP, то его сессия будет иметь выше-обозначенные ограничения и будет пригодна только для процедуры получения цифрового сертификата, необходимого для последующих полноценных L2TP/Ipsec подключений.

4.3. Добавление информации о VPN-сервере на сервер RADIUS

Политики сетевого доступа для VPN-клиентов на сервере NPS созданы, но для того, чтобы VPN-серверы могли обращаться к серверам RADIUS как поставщику аутентификации и обрабатываться созданными политиками, нам необходимо прописать эти VPN-серверы в качестве клиентов RADUIS. Для этого в консоли Network Policy Server в дереве навигации откроем узел NPS >  RADIUS Clients and Servers > RADIUS Clients. В меню действий выберем New.

В окне добавления нового клиента RADIUS на закладке Settings укажем полное доменное имя нашего VPN-сервера (тут же проверим, что оно успешно разрешается в IP с помощью кнопки Verify) и в ручную укажем пароль Shared secret для установления безопасного соединения между клиентом и сервером RADIUS. Запомним этот пароль, так как он понадобиться нам на следующем этапе настройки VPN-сервера.

На закладке Advanced оставим настройки предложенные по умолчанию.

Аналогичный образом создадим на RADIUS сервере запись о втором VPN-сервере…

Если у нас более одного сервера RADIUS, дублируем информацию о клиентах RADIUS (VPN-серверах) с идентичными настройками на дополнительных серверах.

5. Привязка VPN-сервера к серверам RADIUS

Теперь нам нужно выполнить настройку наших VPN-серверов для использования RADIUS аутентификации выполнив привязку к ранее настроенным RADIUS-серверам. Возвращаемся на VPN-сервер в консоль Routing and Remote Access, снова выбираем наш сервер и, открыв контекстное меню, выбираем пункт Properties. На закладке Security меняем поставщиков Authentication provider и Accounting provider на RADIUS Authentication и RADIUS Accounting соответственно. Чтобы задать параметры соединения с серверами RADIUS нажимаем кнопку Configure

Добавляем информацию о серверах RADIUS. Как минимум, указываем для каждого из них имя Server name и Shared secret заданным нами ранее в п.4.3

Закрываем все окна сохранив изменения.

6. Проверка подключения по протоколу PPTP с использованием RADIUS

На данном этапе можно проверить подключение VPN-клиента по протоколу PPTP, но теперь уже с  использованием аутентификации и авторизации на сервере RADIUS. Информацию о событиях подключения VPN-клиентов теперь можно будет увидеть в event-log серверов RADIUS. Если подключение и аутентификация VPN-клиента проходит успешно, переходим к следующему этапу.

7. Работа с сертификатами

Следующим этапом настройки мы приступим к подготовке нашего VPN-сервера и VPN-клиентов к использованию протокола L2TP/IPSec. Создадим цифровые сертификаты, которые будут использоваться для установления безопасного шифрованного соединения между клиентом и сервером. Как на VPN-сервер, так и на VPN-клиента нам нужно будет установить сертификат компьютера, выпущенный одним и тем же доверенным Центром сертификации. В нашем случае будет использоваться автономный (Standalone) Центр сертификации.

7.1. Установка корневого сертификата ЦС на VPN-сервере и VPN-клиенте

Если это ещё не сделано ранее, например для доменных компьютеров с помощью групповой политики, то сделаем это сейчас. Все описываемые в дальнейшем манипуляции с сертификатами можно выполнять как через инструменты графической оболочки, так и с помощью утилит командной строки. Для упрощения и ускорения основные примеры будем выполнять с использованием утилит командной строки, дополнительно учитывая то обстоятельство, что это будет нам полезно в последующем для разных процедур автоматизации. 

Скачиваем файл корневого сертификата ЦС во временный каталог на текущий компьютер (VPN-клиент или VPN-сервер):

certutil -f -config "kom-ad01-ca01.holding.com\KOMI Root CA" -ca.cert "C:\Temp\CertificateRootCA.cer"

В ответ мы должны получить содержимое сертификата примерно в следующем виде:

Сертификат ЦС[1]: 3 -- Действителен
Сертификат ЦС[1]:
-----BEGIN CERTIFICATE-----
MIIERzCCAy+gAwIBAgQEy0HgbIqB4Z5XG5qXCjlcDANBgkqhkiG9w0BAQUFADBh
...
jxwM6bUY8kB3SvzBxQX1FZiPb+n219qJwq3gWeu6MysXrfShENeqFpgfyCaSpFy
UdGgqkXUdNZ1R/rc3g8KowOYfWFn8928QuQo2Up7KneEIsZZne6k5Mqjg==
-----END CERTIFICATE-----

CertUtil: -ca.cert — команда успешно выполнена.

Устанавливаем загруженный файл корневого сертификата в хранилище Доверенные корневые центра сертификации (Trusted Root Certification Authorities) хранилища Локальный компьютер (эту операцию нужно выполнять с правами администратора):

certutil -addstore Root  "C:\Temp\CertificateRootCA.cer"

В ответ мы должны получить информацию об успешной установке сертификата ЦС

Root "Доверенные корневые центры сертификации"
Подпись соответствует открытому ключу
Сертификат "KOMI Root CA" добавлен в хранилище.
CertUtil: -addstore — команда успешно выполнена.

Запускаем консоль mmc.exe, и загружаем оснастку управления сертификатами. Для этого выбираем в меню File > Add/Remove Snap-In. В списке оснасток выбираем Certificates > нажимаем Add > выбираем Computer account > выбираем Local computer

Убеждаемся в том, что в контейнере Trusted Root Certification Authorities\Certificates отображается корневой сертификат нашего ЦС.

7.2. Создание сертификата VPN-сервера

Сертификат, который мы будем создавать для каждого VPN-сервера, должен содержать в расширениях «Улучшенный ключ» цели «Проверка подлинности сервера» (OID — 1.3.6.1.5.5.7.3.1) и «Проверка подлинности клиента» (OID — 1.3.6.1.5.5.7.3.2)

Нижеописанные манипуляции нужно проводить непосредственно с сервера VPN.

Для генерации запроса на получение сертификата от ЦС, создаём во временном каталоге, например C:\Temp, конфигурационный файл RequestConfigVPNServer.inf со следующим содержимым:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-VPNCL.holding.com"
Exportable = TRUE; Private key is exportable
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xf0; Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
OID=1.3.6.1.5.5.8.2.2 ; IP Security IKE intermediate
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-VPNCL.holding.com&" 
_continue_ = "dns=KOM-AD01-VPN01.holding.com&" 
_continue_ = "dns=KOM-AD01-VPN02.holding.com&"  

Параметр Exportable = TRUE определяет то, что для генерируемого сертификата возможен будет экспорт закрытого ключа. В таком виде этот параметр стоит использовать лишь в том случае, если вы хотите использовать один сертификат на нескольких VPN-серверах, во всех остальных случаях желательно использовать значение вида Exportable = FALSE. 

Генерируем файл запроса на основе конфигурационного файла:

certreq -new -f "C:\Temp\RequestConfigVPNServer.inf" "C:\Temp\RequestBinaryVPNServer.req"

Получаем ответ, что запрос создан и сразу отправляем этот запрос в ЦС. В зависимости от того, как настроен ЦС на автоматическое одобрение, можно использовать один из описанных далее вариантов отправки в ЦС запроса и получения сертификата…

***

Вариант А (в случае если автоматическая выдача сертификатов в ЦС выключена)

Выполняем отправку запроса сертификата в ЦС:

certreq –submit –f -config "kom-ad01-ca01.holding.com\KOMI Root CA" "C:\Temp\RequestBinaryVPNServer.req"

В ответ мы получим примерно следующее:

Код запроса (RequestId): 31
Код запроса: "31"
Запрос сертификата в ожидании: Taken Under Submission (0)

Как видим, RequestId выведен нам на консоль с сообщением, означающим то, что наш запрос переведён в ожидание одобрения администратором ЦС. Запомним номер RequestId.
На этом этапе администратор ЦС выполняет одобрение на генерацию сертификата по полученному запросу. После этого мы можем выполнить загрузку сертификата из ЦС (31 в данном примере это и есть RequestID):

certreq -retrieve -f -config "kom-ad01-ca01.holding.com\KOMI Root CA" 31 "C:\Temp\CertificateVPNServer.cer"

В ответ мы должны получить сообщение об успешной загрузке сертификата:

Код запроса (RequestId): 31
Код запроса: "31"
Получен сертификат(Выдан) Issued  Resubmitted by KOM\adm-artur

***

Вариант Б (в случае если автоматическая выдача сертификатов в ЦС включена)

Выполняем отправку запроса сертификата в ЦС и сразу указываем куда будет сохранён автоматически полученный готовый сертификат:

certreq –submit –f -config "kom-ad01-ca01.holding.com\KOMI Root CA" "C:\Temp\RequestBinaryVPNServer.req" "C:\Temp\CertificateVPNServer.cer"

В ответ мы получим примерно следующее сообщение говорящее об успешной автоматической выдаче сертификата:

Код запроса (RequestId): 31
Код запроса: "31"
Получен сертификат(Выдан) Issued

Как видим, с включённым механизмом автоматической выдачи сертификатов в ЦС процесс намного проще.

***

После того, как сертификат загружен (любым из перечисленных выше способов) выполняем его установку:

certreq -accept "C:\Temp\CertificateVPNServer.cer"

После успешной установки сертификата не забываем удалить из временного каталога все файлы, которые были созданы в процессе запроса, получения и установки сертификата. Дополнительно проверить наличие установленного сертификата можно в оснастке управления сертификатами в хранилище Локальный компьютер

7.3. Создание сертификата VPN-клиента

Сертификат компьютера, который мы будем создавать для каждого VPN-клиента, как минимум, должен содержать в расширениях «Улучшенный ключ» цель «Проверка подлинности клиента» (OID — 1.3.6.1.5.5.7.3.2)

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-WS001.holding.com" ; 
Exportable = FALSE; Private key is not exportable 
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xf0; Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment 
MachineKeySet = TRUE 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

Параметр определяющий возможность экспорта закрытого ключа для всех VPN-клиентов — выключаем. Этим самым мы ограничим возможность “утечки” сертификата с закрытым ключом с клиентского компьютера. Команды запроса и установки сертификата на VPN-клиенте в ручном режиме аналогичны п.7.2. В результате подобного запроса к ЦС, будет выдан соответствующий сертификат клиента, который после установки на клиентский компьютер должен говорить нам о наличии закрытого ключа.

Учитывая то обстоятельство, что в качестве VPN-клиентов чаще всего выступают домашние компьютеры пользователей, а настройку подключения эти пользователи делают самостоятельно, нам нужно постараться максимально автоматизировать вышеописанные процедуры связанные с запросом, получением и установкой сертификата компьютера. Поэтому, весьма желательно, чтобы у пользователя на руках была пошаговая инструкция по настройке VPN-подключения (п.12), а все манипуляции связанные с установкой сертификата выполнялись в пакетном режиме. Для этого создадим командный файл, в котором будет выполняться генерация запроса к ЦС, получение сертификата (ЦС должен быть настроен на автоматически ответ) и установка этого сертификата на клиентский компьютер.

Пример командного файла Install Certificate.cmd:

set vSubject=%COMPUTERNAME%
set vCAPath="kom-ad01-ca01.holding.com\KOMI Root CA"

set vTempPath=%SystemDrive%\TempVPNCertFiles
set vRequestInf=%vTempPath%\RequestConfigVPNClient.inf
set vRequestBin=%vTempPath%\RequestBinaryVPNClient.req
set vCert=%vTempPath%\CertificateVPNClient.cer

mkdir %vTempPath%

rem Get the CA's cert
certutil -f -config %vCAPath% -ca.cert %vTempPath%\CertificateRootCA.cer

rem Move the CA's cert to the "Trusted Root Authorities" store
certutil -f -addstore Root  %vTempPath%\CertificateRootCA.cer

rem Create an INF request file
del %vRequestInf%
echo [Version]                    > %vRequestInf%
echo Signature="$Windows NT$"    >> %vRequestInf%
echo [NewRequest]                >> %vRequestInf% 
echo Subject="CN=%vSubject%"     >> %vRequestInf% 
echo Exportable=FALSE            >> %vRequestInf%
echo KeyLength=2048              >> %vRequestInf%
echo KeySpec=1                   >> %vRequestInf%
echo KeyUsage=0xf0               >> %vRequestInf%
echo MachineKeySet=TRUE          >> %vRequestInf%
echo ProviderName="Microsoft RSA SChannel Cryptographic Provider" >> %vRequestInf%
echo RequestType=PKCS10          >> %vRequestInf%
echo [EnhancedKeyUsageExtension] >> %vRequestInf% 
echo OID=1.3.6.1.5.5.7.3.2       >> %vRequestInf%

rem Create a binary request file from the INF
del %vRequestBin%
certreq -new -f %vRequestInf% %vRequestBin%

rem Submit the request to our CA and save the certificate
certreq -submit -f -config %vCAPath% %vRequestBin% %vCert%

rem This step needed to import the private key.  Also puts the certificate in the local computer personal store.
certreq -accept %vCert%

rem Clear files
rmdir /s /q %vTempPath%

В качестве предварительных условий для работы командного файла должно быть соблюдено, как минимум, два условия:
1) Перед запуском командного файла пользователь должен установить VPN-соединение по протоколу PPTP (для доступности ЦС из локальной сети);
2) Командный файл нужно выполнять на клиентском компьютере с правами администратора (для возможности добавления сертификата в хранилище “Локальный компьютер”)

Работа приведённого примера командного файла без дополнительных условий может использоваться (была проверена) на Windows 8/8.1, Windows 7 SP1, Windows Vista SP2.

Для клиентов же Windows XP, как всегда, всё несколько сложнее. В частности, для Windows XP SP3, согласно статьи KB934576 — Auto-enrollment is not triggered when you try to use Certutil.exe on a Windows XP-based computer, для успешной работы командного файла потребуется наличие трёх дополнительных файлов из состава Windows Server 2003 Administration Pack: certutil.exe, certreq.exe и certadm.dll , так как этих файлов нет в базовом составе ОС.

Помимо этого, на сервере выполняющем роль ЦС, если он работает под управлением Windows Server 2012/2012 R2, согласно документа, потребуется понизить уровень безопасности для обработки процедуры запросов на выдачу для клиентов на Windows XP. Описание того, как это можно сделать, можно найти в одной из прошлых заметок.

Дополнительно для Windows XP потребуется убрать из командного файла строчку

echo ProviderName="Microsoft RSA SChannel Cryptographic Provider" >> %vRequestInf%

В конечном итоге, можно либо дальше расширять логику командного файла для разного алгоритма работы на различных версиях Windows, либо попросту создать готовые командные файлы под каждую версию клиентской ОС Windows. Например, для пользователей, у которых на домашнем компьютере установлена Windows XP должен поставляться  следующий набор файлов:

А, например, для пользователей, у которых на домашнем компьютере установлена Windows 8/8.1 будет другой набор файлов, состоящий фактически только из соответствующего командного файла и пошаговой инструкции для пользователя по настройке VPN подключения:

8. Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec

Меняем настройки VPN-подключения на клиентском компьютере на использование протокола L2TP/Ipsec и проверяем подключение из Интернет.

В случае проблем с подключением, изучаем event-логи на VPN-сервере, а также на сервере RADIUS, так как теперь все события связанные с процедурами аутентификации и авторизации фиксируются именно там.

Если подключение к первому настроенному VPN-серверу по протоколу l2TP/Ipsec прошло успешно, то можно приступить к следующему этапу расширения конфигурации. 

9. Настройка второго VPN-сервера (KOM-AD01-VPN02)

Настройку второго VPN-сервера с именем KOM-AD01-VPN02 выполняем по аналогии с первым VPN-сервером.

При желании использовать на втором VPN-сервере тот же сертификат, который был создан для первого VPN-сервера, экспортируем сертификат сервера с закрытым ключом с первого сервера и импортируем на второй сервер.

Не забываем прописать данные второго VPN-сервера на серверах RADIUS и отдельно протестировать возможность подключения к этому VPN-серверу сначала по протоколу PPTP, затем по протоколу L2TP/Ipsec. Если в итоге мы смогли убедиться в том, что VPN-подключения успешно работают для обоих VPN-серверов по отдельности, то настало время собрать их в кластер.

10. Создание NLB-кластера из двух VPN-серверов

Отправной документ для построения кластера здесь: Deploy Remote Access in a Cluster
Планирование описано в документе Plan a Remote Access Cluster Deployment
Конфигурирование кластера описано в документе Configure a Remote Access Cluster

***

Первым делом обратим внимание на то, что в свойствах виртуальных машин Hyper-V, в которых работают наши VPN-серверы, которые мы хотим сделать членами NLB кластера, для сетевого адаптера WAN необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses). Именно этот сетевой адаптер мы будем делать членом NLB-кластера.

***

Затем создаём во внешней зоне DNS статическую А-запись для будущего NLB кластера:

<

p align=»center»>***
Далее, с помощью PowerShell установим на оба VPN-сервера исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

<

p align=»center»>***

После добавления роли NLB в Windows Firewall добавляется ряд правил связанных с этой ролью. Нам нужно будет откорректировать эти правила, в частности свести к минимуму возможность контакта к интерфейсам управления NLB из Интернет, отключить правила для IPv6, если этот протокол не используется, ограничить правила меж-узлового обмена и т.п. В конечном итоге, из включённых и настроенных правил, касающихся NLB, у меня получилась такая картина на первом VPN-сервере:

На втором VPN-сервере:

<

p align=»center»>***

Теперь приступим к процессу создания NLB-кластера.

На первом сервере RAS (KOM-AD01-VPN01) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот, который хотим сделать участником кластера:

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее зарегистрировали А-запись во внешней зоне DNS.

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. В нашем примере выбран режим одноадресной рассылки – Unicast.

На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

Отдельное замечание по допустимым режимам фильтрации (Filtering Mode), касающееся построения NLB для VPN можно найти в документе Create a new Network Load Balancing Port Rule:

When using NLB to load balance virtual private network (VPN) traffic (such as PPTP/GRE and IPSEC/L2TP), you must configure the port rules that govern the ports handling the VPN traffic (TCP port 1723 for PPTP and UDP port 500 for IPSEC) to use either Single or Network affinity.

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 1723 – Routing and Remote Access (PPTP-In);
UDP 1701 – Routing and Remote Access (L2TP-In);
UDP 500 – Routing and Remote Access (Allows IKE traffic to the VPN server);
UDP 4500 – Routing and Remote Access (Allows IPsec NAT-T traffic from the VPN client to the VPN server.);

Все необходимые параметры кластера заданы, создаем его по нажатию кнопки Finish и после первоначальной инициализации, если в конфигурации не допущены ошибки, NLB кластер запуститься в конфигурации с одним узлом

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго сервера в кластер.

Вводим имя второго VPN-сервера, подключаемся к нему кнопкой Connect и после появления информации о сетевых интерфейсах сервера выбираем WAN-интерфейс, который хотим включить в NLB кластер.

Все прочие настройки при добавлении узла кластера можно оставить по умолчанию.

После добавления второго узла мы получим работоспособный Windows NLB кластер

11. Проверка работы NLB-кластера

После того как NLB-кластер настроен, с помощью VPN-клиента проверяем из Интернет доступность кластерного интерфейса предварительно по очереди выключая узлы кластера, чтобы убедиться в том, что VPN-подключения к кластерному интерфейсу устанавливаются успешно в случае неполной работоспособности узлов кластера.

12. Инструкции для пользователей

Как уже отмечалось ранее, для пользователей выполняющих подключение к корпоративным VPN-серверам из Интернет необходимо разработать чёткие пошаговые инструкции. Мне удалось протестировать (и параллельно разработать пошаговые инструкции для пользователей) VPN-подключения в составе следующих операционных систем:

• Windows XP 32-bit RU SP3
• Windows Vista Business 32-bit RU SP2
• Windows 7 Pro 32-bit RU SP1
• Windows 8.1 Pro 64-bit RU
• Ubuntu Desktop Linux 14.04.1 64-bit

Архив с инструкциями (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке.

Если потребуется заниматься настройкой VPN-подключения по протоколу L2TP/Ipsec на других дистрибутивах Linux, возможно, будет полезен документ L2TP over IPsec VPN Manager User Guide

С настройкой подключения на Android у меня, к сожалению так ничего и не вышло. Задачи такой в общем-то и не стояло, просто было интересно попробовать. Перепробовал несколько разных бесплатных приложений доступных на Google Play, все довольно сносно работали по PPTP, но ничего не получалось при этом с L2TP/Ipsec. Встречались интересные приложения, но все они были либо платные, либо заточены под старые версии Android, например тот же OneVpn. Параллельно познакомился с таким “зверем”, как эмулятор Android — Android-x86. Пару полезных ссылок на тему того, как это дело завести в среде Hyper-V:

• STH — Installing Android-x86 on Hyper-V with Windows 8.1 in under 5 minutes
• Luisrato Blog — How to Install Android x86 4.4 RC2 on Hyper-V – Part 1: Install
• Luisrato Blog — How to Install Android x86 4.4 RC2 on Hyper-V – Part 2: Configuration, Screen resolution and Network

Дополнительные источники информации

• TechNet Library — Step-by-Step Guide for Setting Up VPN-based Remote Access in a Test Lab
• TechNet Library — Configure a Remote Access Network Policy
• TechNet Library — IPsec Algorithms and Methods Supported in Windows
• TechNet Library — Certificate Requirements for PEAP and EAP
• TechNet Library — Certreq.exe Syntax
• Windows PKI blog — Firewall Rules for Active Directory Certificate Services
• MSDN Library — Сертификаты и проверка подлинности доступа к сети
• TechNet Library — Troubleshooting Network Load Balancing Clusters
• KB926179 — How to configure an L2TP/IPsec server behind a NAT-T device in Windows Vista and in Windows Server 2008 
• KB885407 — The default behavior of IPsec NAT traversal (NAT-T) is changed in Windows XP SP2      
  
• Routing and Remote Access Blog — Remote Access Design Guidelines – Part 3: Tunnel selection, Authentication, Authorization and Accounting
• Routing and Remote Access Blog —  Remote Access Deployment – Part 3: Configuring RADIUS Server for remote access
• Routing and Remote Access Blog — Troubleshooting common VPN related errors
• Routing and Remote Access Blog — What type of certificate to install on the VPN server

Following tutorial shows how to setup Windows Server 2016 (single NIC, behind NAT/Firewall) as a L2TP / IPSec VPN Server.

Install Remote Access Role

• Open Server Manager > Manage > Add Roles and Features and add Remote Access role.
• On Role Services screen choose only DirectAccess and VPN (RAS).
  

Enable and Configure Routing and Remote Access

• Open Server Manager > Tools > Routing and Remote Access
• Right click on server name and choose Configure Routing and Remote Access.
  • Follow the wizard and choose options Custom Configuration and VPN Access.
• Right click on server name and choose Properties.

Create Active Directory VPN Group

• Open Active Directory Users and Computers.
• Create a new security group and add all users that will have permission to connect via VPN.
  

Create and Configure Remote Access Policy

• Open  Server Manager > Tools > Network Policy Server
• Open Policies, right click on Network Policies and click on New
  
• Configure as follows:

Make registry changes to allow L2TP behind NAT

This registry change needs to be done on the VPN server and all Windows VPN clients:

• Open regedit.exe
• Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
• Create a new DWORD 32 type value:
  • Name: AssumeUDPEncapsulationContextOnSendRule
  • Data: 2
    0 — No connection to servers behind NAT (Default).
    1 — Connection where VPN server is behind NAT.
    2 — Connection where VPN server and client are behind NAT.
•  Reboot computer for changes to take effect.
  

April 2018
Windows Server Standard 2016