After you configure RADIUS two-factor authentication settings in a Horizon Cloud pod's gateway configuration, you must also configure your RADIUS server's configuration to allow client requests from specific gateway-related IP addresses. The gateway's Unified Access Gateway instances will attempt to communicate with the RADIUS server from specific IP addresses. Your network administrator determines the RADIUS server's network visibility to the pod's Azure Virtual Network (VNet) and subnets. The combination of that network visbility and the pod gateway type, external or internal, determines the specific gateway-related IP addresses that you must configure as allowed clients in your RADIUS server configuration.

Important:

Follow the documentation that is appropriate for your RADIUS two-factor authentication system to see the syntax for the specific configuration file used in your RADIUS system in which you must configure this client information. As an example, as described in the FreeRADIUS wiki for FreeRADIUS client configuration, the /etc/raddb/clients.conf file contains the definitions of RADIUS clients as:

client NAME {
  ipaddr = IPADDRESS
  secret = SECRET
}

This topic describes the information from your Horizon Cloud pod that you must use in your RADIUS server to enable communication between the pod's gateway and also to maintain resiliency of that communication after each pod update. To accept connections from client machines that attempt to reach it, RADIUS servers need to register the IPs of those client machines as allowed clients. In this case of a Horizon Cloud pod gateway configured with RADIUS two-factor authentication settings, those client machines are that gateway's Unified Access Gateway instances. Usually your network administrator determines what network access the RADIUS server has to the VNet and the subnets that are connected to the deployed pod. The specific source IPs that the Unified Access Gateway instances use when contacting the RADIUS server depend on:

  • Whether the gateway configuration is internal or external
  • Whether your network administrator has configured the RADIUS server as accessible from inside the pod's VNet, or is located outside the VNet
  • If the RADIUS server is accessible within the pod's VNet, from which of the pod's subnets in that VNet has your network administrator configured access to the RADIUS server
Internal gateway configuration
The Unified Access Gateway instances deployed for an internal gateway configuration use their NICs' private IP addresses to contact that RADIUS server. The RADIUS server sees the requests coming from source IP addresses that are the NICs' private IP addresses. Your network administrator has configured whether the RADIUS server is accessible to the pod's management or tenant subnet's IP address range. The internal gateway's resource group in Microsoft Azure has four (4) NICs that correspond to that subnet: two that are currently active for the two Unified Access Gateway instances and two NICs that are idle and will become the active ones after the pod goes through an update. To support the communication connectivity between the gateway and the RADIUS server both for ongoing pod operations and after each pod update, you must configure the RADIUS server to allow client connections from the IP addresses of the four NICs in the internal gateway's resource group in Microsoft Azure that correspond to the subnet that has visibility to the RADIUS server. See How to Add Pod Gateway NICs' IP Addresses as Allowed Clients for Requests.
External gateway configuration and the RADIUS server is accessible inside the pod's VNet
When your network administrator has configured the RADIUS server to be accessible on the same VNet as the pod, the Unified Access Gateway instances use their NICs' private IP addresses to contact that RADIUS server. The RADIUS server sees the requests coming from source IP addresses that are the NICs' private IP addresses. Your network administrator has configured whether the RADIUS server is accessible to the pod's management, tenant, or DMZ subnet's IP address range. The external gateway's resource group in Microsoft Azure has four (4) NICs that correspond to that subnet: two that are currently active for the two Unified Access Gateway instances and two that are idle and will become the active ones after the pod goes through an update. To support the communication connectivity between the gateway and the RADIUS server both for ongoing pod operations and after each pod update, you must configure the RADIUS server to allow client connections from the IP addresses of the four NICs in the external gateway's resource group in Microsoft Azure that correspond to the subnet that has visibility to the RADIUS server. See How to Add Pod Gateway NICs' IP Addresses as Allowed Clients for Requests.
External gateway configuration and the RADIUS server that is accessible outside the pod's VNet
When your network administrator has configured the RADIUS server outside of the pod's VNet, the external gateway configuration's Unified Access Gateway instances use the external gateway's Azure load balancer resource's IP address to contact that RADIUS server. You must configure the RADIUS server to allow client connections from the external gateway's load balancer resource's IP address. See How to Add the Pod External Gateway's Load Balancer IP Address as an Allowed Client for Requests.

How to Add Pod Gateway NICs' IP Addresses as Allowed Clients for Requests

When the pod is deployed, the pod deployer creates a set of NICs in the gateway's resource group in your Microsoft Azure subscription. The following screenshots are examples of the NICs for the internal gateway type and external gateway type. Even though the pod ID is pixelated out in these screenshots, you can see the pattern in which the deployer names the NICs, with -management, -tenant and -dmz in those names. For the names of the pod's resource groups, see Resource Groups Created For a Pod Deployed In Microsoft Azure.


Screenshot of the NICs and VMs that the pod deployer creates for an internal gateway configuration.


Screenshot of the NICs and VMs that the pod deployer creates for an external gateway configuration.

You need to obtain the IP addresses of the NICs for the gateway configuration on which you enabled RADIUS two-factor authentication which correspond to the subnet which has network visibility to the RADIUS server, and specify those IP addresses as allowed clients in your RADIUS server configuration.

Important: To avoid any disruption in connectivity between your RADIUS server and the pod after an update, for each gateway that you configured with RADIUS settings, ensure that the IP addresses of the four (4) NICs that are described below are specified as allowed clients in your RADIUS server's configuration. Even though only half of the NICs are active during ongoing pod operations, they switch when the pod is updated. After a pod update, the other half of the NICs become active and the pre-update NICs go idle until the next pod update, when they switch back again. If you have not added all of the NIC IP addresses, both the active and idle ones, to your RADIUS server configuration, the RADIUS server will refuse connection requests from the post-pod-update now-active set of NICs, and the login process for end users using that gateway will break.

To obtain the gateway's NIC IP addresses to add to the RADIUS server configuration:

  1. Obtain from your network administrator the information about which of the pod's subnets has network visbility to the RADIUS server (management, tenant, or dmz).
  2. Log in to the Microsoft Azure portal for your subscription and locate the gateway's resource group.
  3. For the NICs that correspond tp the subnet that your network administrator says has visibility to the RADIUS server, click on each NIC and copy its IP address.
  4. Add those NIC IP addresses to your RADIUS server client configuration file so that those NICs are allowed clients for the RADIUS server that you configured in the settings for that gateway.

    The following line is an illustration of a portion of the client configuration lines for the NICs with IP addresses on the pod's tenant subnet for an internal gateway where the network administrator configured the RADIUS server inside the same VNet as the pod and with accessibility from the pod's tenant subnet. The pod's tenant subnet was configured as 192.168.25.0/22 when this pod was deployed. When the pod is initially deployed, the NIC1 and NIC2 are active and NIC3 and NIC4 are idle. However, all four of those NICs are added to the RADIUS server configuration to ensure that after the pod updates, when NIC3 and NIC4 become active and NIC1 and NIC2 go idle, the RADIUS sever will continue to accept connections from this gateway. You must use the appropriate syntax for your own RADIUS server.

    client UAGTENANTNIC1 {
      ipaddr = 192.168.25.5
      secret = myradiussecret
    }
    client UAGTENANTNIC2 {
      ipaddr = 192.168.25.6
      secret = myradiussecret
    }
    client UAGTENANTNIC3 {
      ipaddr = 192.168.25.7
      secret = myradiussecret
    }
    client UAGTENANTNIC4 {
      ipaddr = 192.168.25.8
      secret = myradiussecret
    }

How to Add the Pod External Gateway's Load Balancer IP Address as an Allowed Client for Requests

When the RADIUS server is located outside of the pod's VNet, for the external gateway on which you specified that RADIUS server, you must add the external gateway's Azure load balancer resource's public IP address as an allowed client in that RADIUS sever configuration. You can obtain that load balancer IP address by using the Microsoft Azure portal and locating the load balancer resource in the gateway's resource group.

  1. Log in to the Microsoft Azure portal for your subscription and locate the gateway's resource group.
  2. In the gateway's resource group, click on the load balancer resource. It has a name in the pattern vmw-hcs-podID-uag-lb. Its IP address is listed in its overview information.
  3. Add the gateway's load balancer IP address to your RADIUS server client configuration file so that the gateway's load balancer is an allowed client for the RADIUS server that you configured in the settings for that gateway. The following line is an illustrating example. You must use the appropriate syntax for your own RADIUS server.
    client MYPODUAGEXTLBIP {
      ipaddr = 52.191.236.223
      secret = myradiussecret
    }