on
31-Mar-2023
10:36
- edited on
03-Apr-2023
11:05
by
Rebecca_Moloney
F5 BIG-IP Access Policy Manager (APM) feature Machine Tunnels is a powerful tool to address access needs without user interaction on the Microsoft Windows platform. Many use cases require such access. For example, in a recent interaction with a customer, it became evident that the end users needed to be able to access Active Directory for authentication and initial password changes, both for new employees or after a wipe and reprovision occurring for existing users. Others may want remote systems to boot up and connect over untrusted networks for command and control—devices such as remote signage, ATMs, vending systems, surveillance systems, etc.
The BIG-IP APM Machine Tunnel is separate from but partnered with the more traditional BIG-IP Edge Client or app access policies that end users use. But, this article will focus only on the Machine Tunnels component. Still, you can deploy a machine tunnel policy along with the other types, and the BIG-IP APM will pause and restart the machine tunnel automatically as required for your sessions.
Machine Tunnels behave, are configured, and managed differently than typical access policies. If you've configured, troubleshot, and managed Edge Client and Access Policies, you are familiar with the tools and the locations of data and logs for those purposes. Due to the nature of machine tunnels, the same information can't be and isn't stored in the same places. The logs and binaries are in different places. For example, Machine Tunnel logs are found in C:\Windows\Temp or the defined system temp folder.
In contrast, the Edge client stores its logs in a temporary folder within the %APPDATA% structure under the user logged into the service. Executable parts of the two clients are in different locations as well. Machine Tunnels binaries live in C:\Windows\sysWOW64, and the Edge VPN client uses C:\Program Files (x86)\F5 VPN.
Authentication for Machine Tunnels can be done with certificates only via On-Demand Certificate Auth (ODCA). There can be some confusion as other access policies allow you to use Machine Certificate Authentication (MCA). MCA isn't compatible with Machine Tunnels. Machine Tunnels authentication can consist of the following steps:
The user of the different authentication credentials is optional. Using both certificate and userid/password is the most secure method. We cover only the certificate authentication method in the example within this article. Machine Tunnel certificates can be stored in the Windows system default location or a Machine Tunnels specific location. The userID and Passwords are stored in encrypted hashes.
Machine Tunnels are automatic; the client can often be unattended in untrusted environments. With this in mind, thoughtfulness about access controls and available services to a machine tunnel profile must be a priority. It is recommended to assign very limited network access that achieves the requirements.
We can use one of the Device Wizard methods to bootstrap many items we will need to configure a Maching Tunnels profile and then discuss the additional things we'll need to configure.
The easiest way to get BIG-IP APM components set up and ready is to use the Wizard, which we will use in this example.
We will name our policy from here and uncheck "Enable Antivirus Check in Access Policy" to keep things simple. When building a complex policy, I encourage you to start with the most straightforward configuration and establish the essential work. Then build upon those successes.
For authentication, we are going to select "No Authentication." That doesn't sound good, but we will fix that soon.
Now we will configure a client address pool. If you want to keep the source IP available to your other systems for clients connected through the BIG-IP APM, please use a range that can be appropriately routed on your network.
Defining our Network Access is an area to give some consideration for sure. It's a good idea to isolate what networks you wish the client to talk to during the Machine Tunnels stage of connectivity. You may also want to force all traffic over the tunnel to avoid the client leaking network data on public networks. Alternatively, you may not want the excess traffic on your system.
The DNS server definition is essential for a lot of reasons. First, the client will try to reach services such as Active Directory by name, and a resolution is necessary.
We must define a Virtual Server to accept the inbound session requests. You should not need a redirect server, so you can uncheck that option to avoid configuration clutter.
Proceeding to click through "NEXT" twice we get a summary of our objects created.
We can open the Visual Policy Editor, add the Machine Tunnel client type, and set up the ODCA configuration. Then, head to Access ›› Profiles / Policies: Access Profiles (Per-Session Policies) and open the new profile created.
Click on the first "+" symbol before "Login Page." Then, in the Search bar, type "Client Type," select that and click "add item."
For now, we will select all client types and delete them except for the "Machine Tunnel" and "Edge Client" types. The latter is a placeholder for the future expansion of our access policy and won't be covered in this article. Now click "Save," and we should have a policy that looks like the following:
Click on the "+" symbol just to the right of the "Machine Tunnel" label. Then, in the search field, type "On-Demand," select "On-Demand Cert Auth," and click "Add Item."
Click on the On-Demand Cert Auth link that's been added to our policy and change the setting from "Request" to "Require," and click "Save."
The policy should appear as follows.
On the right, on the "Successful" branch from "On-Demand Cert Auth," click on "Deny" and change that to "Allow" and save, which should end our policy changes and appear as the following.
The root, intermediate, and signing certificates required to validate your client certificates must be concatenated and imported into your BIG-IP APM. This CA bundle will then need to be used to configure the client SSL profile of the VIP. You will also want a valid certificate installed in the SSL profile, one your clients can validate. You can see your configured CAs here Local Traffic ›› Profiles: SSL: Certificate Authority.
How you go about the delivery and installation of the client certificates is beyond the scope of this article. There are two places where the certificate can be stored, and the machine tunnels client can be set to use either location. We will cover configuring the location to use later in this article. It is assumed the client certificates have been issued and stored in the default location on your Windows clients.
The virtual server should have been built during the device configuration wizard steps above. Open that virtual server and configure it with the client ssl profile you've created. Make sure the policies for APM are applied and save those settings. This completes the APM portion of the configuration except for the client package and download of that package cover next.
In the Access ›› Connectivity / VPN: Connectivity: Profiles section, select our policy name and at the bottom, select Customize Package. Add the Machine Tunnel Service to the package and retrieve the installation package to deploy onto your clients.
You can use the installer to install the machine tunnel service on the user's machine. The installer will install the following components on the user's Machine under the C:\Windows\SysWow64 directory
There are primarily two ways to configure the Machine Tunnels service on the client side. Either through the F5MachineTunnelInfo.exe tool or via direct editing of the registry. The latter may simplify deployments where registry settings can be distributed with Active Directory policies.
As of the publishing of this article, the help for this tool is as follows:
To configure the certificate store to use the default Windows location for machine certificates, the command would look as follows:
From the command prompt that is run as an administrator. “cd C:\Windows\SysWow6.”
Type “F5MachineTunnelInfo.exe --set_client_certstore system my” to set the client certificate store to use.
You can also print the client’s current configuration:
You must create or set up the registry keys and configure authentication on the client through the above tool or directly in the registry.
Once you've completed all client-side configurations, you can restart the client.
Now that you've configured everything, you should see sessions for clients running the machine tunnel configuration.
You can move on to more advanced configurations, including adding webtop, client or application access profiles, etc.
Configure supported ciphers to those that are hardware-accelerated for the platform - https://my.f5.com/manage/s/article/K13213
Updating the client installer package - https://my.f5.com/manage/s/article/K52547540
Several possible things can go wrong with Machine Tunnel access that prevents it from establishing a tunnel. It has been seen that SSL errors are the primary culprit of issues. Setting "IgnoreSSLErrors" to "1" in the registry is one way to determine if an SSL issue is the cause of your problems. This option is not set in production, or certificate validation will be ignored. The other options are to review the BIG-IP APM logs on the F5 appliance and the client logs. The client logs should be in the system temp folder, and in the case of this example, they are found in the file "C:\Windows\Temp\F5MachineTunnelService".