Vmware tunnel что это
The VMware Workspace ONE Tunnel app supports two methods of virtual private networking: per-device or per-app. When the Tunnel app is operating in per-device mode the VPN connects the operating system and every application and service on the device back to the corporate network. Per-device VPN is what most VPN apps have been doing since the technology was invented. The risk with per-device VPN is that if a bad actor gains access to the laptop they have full access to the corporate network. Per-app VPN’s allow individual applications to VPN without requiring the entire device to connect back to the corporate network. The purpose of this blog is to demonstrate how to configure per-app VPN to allow Windows Active Directory joined machines to continue to function as expected when using Per-App VPN Mode.
Cascade mode
Cascade mode is a method of deployment. You deploy two layers of Unified Access Gateways – one can be in DMZ the other one can be in internal network zone, or one can be in external DMZ and the other one in internal DMZ.
To quote the official documentation:
The front-end server facilitates authentication of devices by connecting to AWCM when requests are made to the VMware Tunnel. When a device makes a request to the VMware Tunnel, the front-end server determines if the device is authorized to access the service. Once authenticated, the request is forwarded securely using TLS over a single port to the back-end server.
The back-end server connects to the internal DNS or IP requested by the device.
Cascade mode communicates using TLS connection (or optional DTLS connection). You can host as many front-end and back-end servers as you like. Each front-end server acts independently when searching for an active back-end server to connect devices to the internal network. You can set up multiple DNS entries in a DNS lookup table to allow load balancing.
Both the front-end and back-end servers communicate with the Workspace ONE UEM API server and AWCM. The API server delivers the VMware Tunnel configuration and the AWCM delivers device authentication, device access control list, and traffic rules. The front-end and back-end server communicates with API/AWCM through direct TLS connections unless you enable outbound proxy calls. Use this connection if the front-end server cannot reach the API/AWCM servers. If enabled, front-end servers connect through the back-end server to the API/AWCM servers. This traffic, and the back-end traffic, route using server-side traffic rules.
Key Concepts
When configuring and deploying the VMware Tunnel , you must learn the VMware Tunnel terminology. Understanding the functionality that these components reference will aid your comprehension of this product. For more information, see Key Concepts.
Proxy (SDK/Browser) Architecture
1. Deploy front-end and back-end UAG
It’s obvious that those two appliance will have different networking configuration and most likely the front-end UAG will not have access to the internal DNS, which is fine.
3. Create a VPN configuration profile for devices
I will show this for iOS, but similar step will be needed for Android.
You need to create new profile with a VPN payload. Select the “Workspace ONE Tunnel” connection type. Server field should be automatically filled for you.
You can have multiple device traffic rules, but at this point the “Default – Default” is OK.
Speciality for iOS are native Apple apps like Safari or Mail. For those you can specify the domain, which should go through the Tunnel. This is the internal domain (in my lab it’s minarik.cloud).
Managing VMware Tunnel Certificates
VMware Tunnel uses certificates to authenticate communication among the Workspace ONE UEM console, VMware Tunnel , and end-user devices. The following workflows show the initial setup process and certificate integration cycle.
Complete the following steps for initial setup workflow:
The VMware Tunnel configuration trusts only messages signed from the Workspace ONE UEM environment. This trust is unique per group.
Any additional VMware Tunnel servers set up in the same Workspace ONE UEM group as part of a highly available (HA) load-balanced configuration are issued the same unique VMware Tunnel certificate.
For more information about high availability, refer to the VMware Workspace ONE UEM Recommended Architecture Guide .
Complete the following steps for certificate integration cycle:
-
Workspace ONE UEM generates Device Root Certificates that are unique to every instance during the installation process.
For Proxy: The Device Root Certificate is used to generate client certificates for each of the applications and devices.
For Per-App Tunnel: The VMware Tunnel Device Root Certificate is used to generate client certificates for each device.
For Per-App Tunnel: The certificate is generated at the time of profile delivery.
X.509 (version 3) digitally signed client certificates are used for authentication.
Сегодня мы посмотрим на возможности настройки VPN, которые предлагает нам NSX Edge.
В целом мы можем разделить VPN-технологии на два ключевых вида:
- Site-to-site VPN. Чаще всего используется IPSec для создания защищенного туннеля, например, между сетью главного офиса и сетью на удаленной площадке или в облаке.
- Remote Access VPN. Используется для подключения отдельных пользователей к частным сетям организаций с помощью ПО VPN-клиента.
5. Create device traffic rules
Now we need to set the rules which application should have access to which servers/domains in the datacenter.
In the Configuration > Tunnel page navigate to Device Traffic Rules and Edit it.
Modify the Default rule set.
Create the rules to your liking. Action TUNNEL means that per-app VPN will be used. BYPASS means direct connection to internet. You can use wildcards as well e.g. *.minarik.cloud.
L2 VPN
L2VPN понадобится в том случае, когда нужно объединить несколько географически
распределенных сетей в один broadcast-домен.
Это может быть полезно, например, при миграции виртуальной машины: при переезде ВМ на другую географическую площадку машина сохранит настройки IP-адресации и не потеряет связность с другими машинами, находящимися в одном L2-домене с ней.
В нашей тестовой среде соединим друг с другом две площадки, назовем их, соответственно, A и B. У нас есть два NSX и две одинаково созданные маршрутизируемые сети, привязанные к разным Edge. Машина A имеет адрес 10.10.10.250/24, машина B – 10.10.10.2/24.
-
В vCloud Director переходим на вкладку Administration, заходим в нужный нам VDC, переходим на вкладку Org VDC Networks и добавляем две новые сети.
Возвращаемся в интерфейс NSx Edge/ Переходим на вкладку VPN —> L2VPN. Включаем L2VPN, выбираем режим работы Server, в настройках Server Global указываем внешний IP-адрес NSX, на котором будет слушаться порт для туннеля. По умолчанию, сокет откроется на 443 порту, но его можно поменять. Не забываем выбрать настройки шифрования для будущего туннеля.
В Egress Optimization Gateway Address задаем адрес шлюза. Это нужно для того, чтобы не происходил конфликт IP-адресов, ведь шлюз у наших сетей имеет один и тот же адрес. После чего нажимаем на кнопку SELECT SUB-INTERFACES.
Заходим на NSX стороны B, переходим в VPN —> L2VPN, включаем L2VPN, устанавливаем L2VPN mode в клиентский режим работы. На вкладке Client Global задаем адрес и порт NSX A, который мы указывали ранее как Listening IP и Port на серверной стороне. Также необходимо выставить одинаковые настройки шифрования, чтобы они согласовались при поднятии туннеля.
Проматываем ниже, выбираем сабинтерфейс, через который будет строиться туннель для L2VPN.
В Egress Optimization Gateway Address задаем адрес шлюза. Задаем user-id и пароль. Выбираем сабинтерфейс и не забываем сохранить настройки.
На этом про VPN на NSX Edge у меня все. Спрашивайте, если что-то осталось непонятным. Также это последняя часть из серии статей по работе с NSX Edge. Надеемся, они были полезны :)
Workspace ONE Tunnel is a per-app VPN technology, which is pretty easy to deploy and work on all major platforms today (iOS, Android, macOS and Windows 10). In order for this to work you need to deploy a Unified Access Gateway in a DMZ and configure a few things in Workspace ONE UEM console.
Deploying such virtual appliance can be really simple – one machine with one NIC. This is what I typically deploy for testing or PoC. But what if you require something little bit more secure?
Part 2: Configure the Tunnel in the UEM Console
With the Public DNS name from Part 1 now available for use the next step is to configure the Tunnel using the Workspace ONE UEM Console.
4. Now that the apps are created, from the Device Traffic Rules page choose Add Rule and add each of the apps to tunnel as illustrated below:
6. Choose Save and Publish
2. Configure Tunnel in Workspace ONE UEM
Nothing difficult over here. In the section Configuration > Tunnel create new config. Select the “Cascade” deployment mode. You will need to enter the front-end/back-end hostname and ports.
Front-end hostname is the public FQDN, which is accessible from devices no matter where they are located.
Back-end hostname is internal FQDN (name from you internal DNS).
Ports are fully customisable, the default port is 8443, but you can put there what ever you want. In my case I do run Tunnel on port 5443. Those two ports does not need to match, but in my eyes it’s easier to use a single port for both.
You can keep everything else (certificates, logging level, server traffic rules…) is default.
Deploy VMware Tunnel on a Linux Server
For customers who do not want to use the Unified Access Gateway deployment, Workspace ONE UEM offers the Linux installer so you can configure, download, and install VMware Tunnel onto a server. The Linux installer has different prerequisites than the Unified Access Gateway method. To run the Linux installer, you must meet specific hardware, software, and general requirements before you can begin installation.
VMware Tunnel Pre-Deployment Configuration
Preparing for your VMware Tunnel installation ensures a smooth installation process. Installation includes performing preliminary steps in the Workspace ONE UEM console, and setting up a server that meets the listed hardware, software, and network requirements. For more information, see Pre-Deployment Configuration.
VMware Tunnel offers two architecture models for deployment, that is single-tier and multi-tier. For more information on deployment models and components, see Deployment Model.
Part 3: Enable Unified Access Gateway Tunnel
The next step is to link the UAG to the UEM Tunnel configuration. This is done using the UAG Admin portal:
tail -f /var/log/vmware/appliance-agent/appliance-agent.log
6. Enable REST API
Unified Access Gateway is downloading the Tunnel configuration using a REST API on the Workspace ONE UEM. Make sure that the REST API is enabled.
Part 1: Set up a public/external facing DNS name for UAG
Disclaimer: I am not a networking guru. There are dozens of different ways to configure DNS so treat this as one example.
In my lab I use a pair of Microsoft AD integrated DNS Servers. I have configured two forward lookup zones:
The previous steps allow your internal devices to find the UAG via DNS but you now need a method for the Internet to find your UAG via DNS. My public DNS provider hosts the DNS records that redirect the Internet to my network. Preferably this process involves a static public IP address, maybe a proxy server, or load balancer, or some other network magic. In my lab I use a Ubiquiti UDM Pro (UDMP) at the edge. When I deployed the UDMP, the device did not support more than one public IP address but software updates from Ubiquiti now allow this, I have just not gone back and changed it, so at the moment I’m using port forwarding. For port forwarding to function I need to create a public DNS name and an A record that points the Internet to the UDMP’s WAN interface.
With the public A record created, head over to your routers configuration page for port forwarding and setup port forwarding. By default VMware Tunnel uses Port 8443 for Per-App VPN and Port 2020 for Proxy so I have 2 port forward rules. The destination IPs would be the internal IP address you previously defined in your internal DNS for the UAG.
Note: VMware announced end of support for the Proxy functionality of Tunnel, so Port 2020 is not something I would recommend moving forward with.
Deploy VMware Tunnel with Unified Access Gateway
VMware offers a hardened virtual appliance (Unified Access Gateway) that hosts Workspace ONE services like Per-app Tunnel, and is the preferred method for deployment. Deploying Tunnel on Unified Access Gateway can be done from either vSphere or Hyper-V and can be automated using PowerShell. The Tunnel service on Unified Access Gateway is same as what the Linux installer provides.
Final Steps
Congratulations on completing the configuration. With this configuration in place Windows devices will be able to:
Workspace ONE provides you with the VMware Tunnel solution that provides secure access for connecting to corporate resources. VMware Tunnel is part of the Anywhere Workspace solution set for enabling remote work and enforcing endpoint compliance. Depending on the operating system, VMware Tunnel can serve to replace both per-app and full device VPNs with a modern Zero Trust architecture.
IPsec
- В интерфейсе vCloud Director переходим в раздел Administration и выделяем vDC. На вкладке Edge Gateways выбираем нужный нам Edge, кликаем правой кнопкой и выбираем Edge Gateway Services.
- В интерфейсе NSX Edge переходим во вкладку VPN-IPsec VPN, далее – в раздел IPsec VPN Sites и жмем +, чтобы добавить новую площадку.
- Enabled – активирует удаленную площадку.
- PFS – гарантирует, что каждый новый криптографический ключ не связан с любым предыдущим ключом.
- Local ID и Local Endpoint – внешний адрес NSX Edge.
- Local Subnets – локальные сети, которые будут использовать IPsec VPN.
- Peer ID и Peer Endpoint – адрес удаленной площадки.
- Peer Subnets – сети, которые будут использовать IPsec VPN на удаленной стороне.
- Encryption Algorithm – алгоритм шифрования туннеля.
- Authentication – как мы будем аутентифицировать пир. Можно использовать Pre-Shared Key либо сертификат.
- Pre-Shared Key – указываем ключ, который будет использоваться для аутентификации и должен совпадать с обеих сторон.
- Diffie-Hellman Group – алгоритм обмена ключами.
В этом примере мы использовали PSK для аутентификации пира, но возможен также вариант с аутентификацией по сертификатам. Для этого нужно перейти во вкладку Global Configuration, включить аутентификацию по сертификатам и выбрать сам сертификат.
Кроме того, в настройках сайта необходимо будет поменять метод аутентификации.
Отмечу, что количество IPsec-туннелей зависит от размера развернутого Edge Gateway (об этом читайте в нашей первой статье).
Per-App Tunnel Architecture
VMware Tunnel provides granular access control to applications and services both in your network and in the cloud. The VMware Tunnel client provides per-app management, permitting explicit trust of individual applications you want to manage, and domain-based filtering for the easy definition of access control and split-tunneling policies.
VMware Tunnel is built on native frameworks provided across all major platforms. When an application is launched or creates a network request, that request is forwarded to the Tunnel client for routing. In this way, Tunnel provides local filtering for determining what traffic must be tunneled into your network, sent to the Internet or another proxy, or blocked from leaving the device.
VMware Tunnel uses SSL pinning to ensure that the server identity is correct.
VMware Tunnel gateway validates that the client certificate is on a allowlist of trusted certificates within the Workspace ONE UEM Console, and performs a device compliance check to ensure the integrity of the user’s device.
For internal routing of traffic, it is required that the Tunnel gateway has properly configured DNS, as routing policies for Tunnel are defined on hostnames and not IP address. If internal DNS is not exposed in the DMZ, then it is recommended to deploy VMware Tunnel in a cascade mode to make use of the internal DNS controllers.
Troubleshooting tips
First of all enable the SSH access during the Powershell deployment. Once everything is tuned and working you can redeploy the UAG without the SSH.
Other Tunnel related logs are written into this file:
In general when a Tunnel is configured – meaning UAG downloaded the configuration from API server – you should see files in the following folder, specifically you can check the server.conf.
It’s better to check the host entries directly in the /etc/hosts file, because sometimes it’s not shown in the UAG admin console. Keep in mind that you should not edit this file manually, but always do the changes in the admin console.
Other stuff which can help is the:
Which will show you the currently used DNS server. The /etc/resolve.conf will not give you the correct data.
For a multi-NIC deployment it might be beneficial to know about this command to trace the path:
Additional network tools (like tcpdump) are hidden and available after running this command.
VMware Tunnel Troubleshooting
The VMware Tunnel supports troubleshooting logs to aid in diagnosing issues in your deployment. For more information, see VMware Tunnel Troubleshooting and Support.
The VMware Tunnel is a product you can install on physical or virtual servers that reside in either the DMZ or a secured internal network zone. VMware Tunnel comprises two separate components, Proxy and Per-App tunneling, each with their own features.
Consider using the Per-App Tunnel component as it provides the most functionality with easier installation and maintenance. Per-App Tunnel uses the native platform (Apple, Google, Microsoft) APIs to provide a seamless experience for users.
The Proxy component provides most of the same functionality of Per-App Tunnel with the need for additional configuration. This component can be leveraged only by the applications having the Workspace ONE (AirWatch) SDK implemented or using the App Wrapping. This includes most of the VMware productivity applications.
VMware Tunnel offers single-tier and multi-tier deployment models. Both the configurations support load-balancing for faster availability. The Proxy component supports SSL offloading , while Per-App tunneling cannot be SSL-offloaded .
7. Enable Tunnel on back-end UAG
Fill in the details in the UAG administration (listening on port 9443).
Pre-requisistes required:
- Microsoft Active Directory Domain Controller (AD)
- Access to edit internal and external DNS records
- Workspace ONE UEM Console version 2102 or higher (UEM)
- VMware Unified Access Gateway Appliance (UAG)
- VMware Tunnel for Windows client
VMware Tunnel Management
Consider configuring additional functionality to enhance your VMware Tunnel deployment. These features allow you more control over device access and networking support. For more information, see Managing VMware Tunnel .
8. Enable Tunnel on front-end UAG
Fill in the details in the UAG administration (listening on port 9443). Here comes the two little things to pay attention to.
The front-end appliance must be able to resolve the back-end appliance hostname. Typically you have a different/no DNS in the DMZ, which means that you need to put the name into the host entries.
Note: If the certificate is not trusted the Tunnel service will be shown as green (in the UAG console), but the VPN will not be established and stuck in “Connecting…” state on the device. Same applies if the front-end cannot resolve the back-end FQDN.
That’s it. You can test it from the device.
Architecture and Deployment Model
The VMware Tunnel is a product you can install on physical or virtual servers that reside in either the DMZ or a secured internal network zone. VMware Tunnel comprises two separate components, proxy and Per-App Tunneling, each with their own architecture and security features. For more information, see Architecture and Security.
How to set it up?
It is easy with 2 little things that can stop you if you don’t pay attention to them and that’s why I am writing this post.
The process is as follows:
Part 4: Deploy the Windows Tunnel client app from UEM
Beginning with VMware Tunnel for Windows version 2.1 the tunnel client can now be used as a full device tunnel as long as the UEM console has been updated to 2102 or higher. The instructions below have been updated for Tunnel 2.1.1 but in the configuration below the Tunnel will continue to be used as a Per-App Tunnel. Consult VMware’s production documentation if you will be leveraging the full device based tunnel configuration for any configuration changes that might be required.
Note: VMware continues to release updates to the Tunnel client application with the most recent releases being bug fixes. Adjust the meta-data below to match the latest version of the client you download.
SSL VPN
SSL VPN-Plus – один из вариантов Remote Access VPN. Он позволяет отдельным удаленным пользователям безопасно подключаться к частным сетям, находящимся за шлюзом NSX Edge. Зашифрованный туннель в случае SSL VPN-plus устанавливается между клиентом (Windows, Linux, Mac) и NSX Edge.
-
Приступим к настройке. В панели управления сервисами Edge Gateway переходим во вкладку SSL VPN-Plus, затем к Server Settings. Выбираем адрес и порт, на котором сервер будет слушать входящие соединения, включаем логирование и выбираем необходимые алгоритмы шифрования.
Здесь же можно изменить сертификат, который будет использовать сервер.
Переходим во вкладку IP Pools и жмем +.
- Network — локальная сеть, к которой будет доступ у удаленных пользователей.
- Send traffic, у него два варианта:
— over tunnel – отправлять трафик к сети через туннель,
— bypass tunnel – отправлять трафик к сети напрямую в обход туннеля. - Enable TCP Optimization – отмечаем, если выбрали вариант over tunnel. Когда оптимизация включена, можно указать номера портов, для которых необходимо оптимизировать трафик. Трафик для оставшихся портов этой конкретной сети не будет оптимизирован. Если номера портов не указаны, трафик для всех портов оптимизируется. Подробнее об этой функции читайте здесь.
Ниже в этом окне можно указать параметры клиента для Windows. Выбираем:
- start client on logon – VPN-клиент будет добавлен в автозагрузку на удаленной машине;
- create desktop icon – создаст иконку VPN-клиента на рабочем столе;
- server security certificate validation – будет валидировать сертификат сервера при подключении.
Настройка сервера завершена.
В окне авторизации необходимо ввести учетные данные пользователя, которого мы создали ранее.
Part 5: Create UEM Console Profile for VPN
- In the UEM Console choose Devices > Profiles & Resources > Profiles
- Choose Add > Add Profiles > Windows > Windows Desktop > Device Profile
- Under General give the profile a name and assign it a SmartGroup
- Choose the VPN payload and fill out the following:
- Connection Name: It now defaults to “Default VPN”
- Connection Type: Workspace ONE Tunnel
- Device Traffic Rule Sets: Default – Default
- Under Custom Configuration XML add the following XML which is how the Tunnel is configured to launch before the Windows 10 Login screen appears:
5. Configure the Trusted Network Detection to be the name of your domain. What this setting does is to ensure that when your device is on the trusted network, the Tunnel will not be established.
6. Under DNS Resolution via Tunnel Gateway you must define how DNS will be resolved. The end goal is to make Tunnel aware of when it will use the internal DNS servers. This area of the product has been enhanced in the latest UEM Console release so you now have two options to choose from: Enable Enhanced Domain Resolution, or Disable Enhanced Domain Resolution and define the Domains.
The end result of your profile should look similar to this (taken from Workspace ONE UEM Console 2102):
4. Push a managed application with Tunnel config
Application must be managed by Workspace ONE in order for it to leverage the Tunnel.
Simply add a new managed application – like for example Workspace ONE Web.
And assign a Tunnel profile, there should be only one. The name will correspond with the VPN device profile you’ve created in the previous step.
For iOS this is all in terms in application. For Android you need to deploy Workspace ONE Tunnel app to every device.
Читайте также: