Horizon 8 on Oracle Cloud VMware Solution Configuration

This chapter is one of a series that make up the Omnissa Workspace ONE and Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Omnissa Workspace ONE and Omnissa Horizon solutions. This chapter provides information about common configuration and deployment tasks for Omnissa Horizon 8 on Oracle Cloud VMware Solution (referred to as OCVS throughout this document).

A companion chapter, Horizon 8 on Oracle Cloud VMware Solution Architecture, provides design guidance.

Prerequisites

Before you begin, you must install and configure the following components:

• OCVS resources assigned to you
• Oracle Cloud login
• Omnissa Horizon Universal Licensing with access to myvmare.com is required to set up licensing on the Horizon Cloud Connector

Review the following documentation:

• OCVS Platform Documentation
• OCVS Getting Started Documentation
• NSX Documentation

Oracle Cloud Platform Configuration

This section covers configuration of the Oracle Cloud Infrastructure (OCI) to prepare for Horizon installation. This information is provided as a reference and the official Oracle documentation should be used for your actual configuration.

Following are the steps we went through when creating the Reference Architecture Environment. Your configuration might vary, this information is provided as reference.

For an illustrative description of the OCVS deployment process, see Deploy the SDDC diagram.

Preparatory Steps

The following steps describe the requirements to prepare the test environment and are not considered part of the required action that a customer would need to carry out. The details of these are specific to our validation, and although customers would most likely require similar steps, those would be specific to their environment and are therefore considered out of scope for this document.

Review the following Oracle documentation:

• Understand Deployment Architecture
• Prepare Your Deployment
• Bastion Overview
• Bastion Hosts: Protected Access for Virtual Cloud Networks
• Contains details about the vSAN, NSX, or vCenter component versions installed - you can change this software version after provisioning
• Internet access from the software-defined data center (SDDC)

Creating OCVS SDDC

See Setting Up an Oracle Cloud VMware Solution SDDC in the Oracle documentation for details.

• Provisioning takes approximately two and a half hours to complete.
• Check the status of provisioning by viewing its work request item from the SDDC’s details page, under Resources.
• If errors occur, click Retry Provisioning. Clicking Cancel Provisioning cancels the provisioning process and deletes all resources created for the SDDC.
• Once complete, collect the vCenter and NSX-T login information from the OCI portal.

Creating the UAG-Outer VLAN in OCI and Attaching it to ESXi

As part of the SDDC build, we will need an additional “VLAN”-backed portgroup for the OCI side of the Unified Access Gateways. In this step, we will create the VLAN in the OCI console, and in the next section, we will attach it to the ESXi hosts and present it as a portgroup.

Preparatory Steps

Before we can create the VLAN, just as we saw with our Subnet creation, there are a few dependencies we need to build first.

• Select the virtual cloud network (VCN) created for your SDDC.

Route Table

• See create a route table in the Oracle documentation.
• In the Resources list on the left, select Route Tables.
  We must control the routing from the UAG VLAN independently; we will create a separate Route Table to allow the addition of specific routes later.

Network Security Group

• See creating a Network Security Group in the Oracle documentation.
• VLANs use Network Security Groups (NSG). The NSG policy is assigned to the vNICs of devices connected to the VLAN to which the NSG is attached.
• Create a Network Security Group for UAG External VLAN.

• Create each of the rules in the following table:

 Create the VLAN

See Create a VLAN for an SDDC in the Oracle documentation.

• VLANs are only available to customers who are subscribed to OCVS. If you see a warning to this effect, your user account may not have the required privileges to carry out this step.
• Create a VLAN for “UAG-External”:

Adding the UAG-Outer VLAN to ESXi/vSphere

In this section, add the VLAN to the ESXi hosts and then connect the VLAN to the vSphere dvSwitch.

Connect the VLAN to the ESXi hosts

See create a VNIC in the Oracle documentation.

In Oracle Cloud, VLANs are presented to the OCI bare-metal hosts as (OCI not vSphere) vNICs. Each host has two physical NICs connected to the same converged dvSwitch. We need to create a vNIC on each of the physical NICs, on each of the hosts, and connect our UAG-External VLAN to each one.

• Create VNICs:

Note: The vNIC list is paginated and your new vNIC may be on page 2 and not immediately visible.

Connect the VLAN to the vSphere dvSwitch

• Create a new dvPortGroup backed by our UAG-External VLAN’s ID.
• See vSphere documentation to create a dvPortgroup.

Updating Oracle Cloud Interface Network Routing and Security

This section discusses the configuration required for OCI network routing and security.

Routing Updates

Routing within OCI is, for the most part, automatically configured. This applies to elements of a solution that Oracle Cloud knows about. Subnets, VLANs (with external access virtual IPs), and OCIs inter- and intra-region routing will all populate the relevant route tables as new networks or devices are configured. The networks within the OCVS SDDC are opaque to OCI, so it cannot dynamically learn/populate routes to the SDDC IP address space. In this section, we will add the required static routes to allow components within OCI to route to/from those in the SDDC.

If we deploy multiple new subnets within our VCN and create a new Route Table for each one, we will also need to add routes to the SDDC to each of them, but in this section, we will ensure the control plane devices on the vSphere VLAN can reach the SDDC. The process is essentially the same for VLANs and subnets irrespective of the number we have.

We will add “Private IP” Target Type Route Rules. We must have the SDDC complete before adding these rules as the OCI console will validate the External Access virtual IP (VIP) for the T0; this is required for routing to the SDDC.

 Find the T0 Virtual IP

The T0 VIP is assigned at build time from the IP address subnet together with other assignments on that VLAN. To confirm the assigned address, we will check the External Access configuration for the T0’s parent VLAN.

• Select your Virtual Cloud Network.
• Select VLANs.
• From the list of VLANs, select “VLAN-<PrefixForEsxiHosts>-NSX Edge Uplink 1”.
• Note the nsx-edge-up1-vip’s Private IP Address.

Update the vSphere VLAN Routing Table

See Oracle documentation to create a route table.

From the list of Route Tables, select “Route Table for VLAN-<PrefixForEsxiHosts>-vSphere”.

Note: If the T0 VIP is correct, OCI will display part of the Oracle Cloud ID (OCID) associated with the External Access VIP.

Security Updates

With the routing all in place, traffic will be able to find destinations within the solution. We need to set permissions to enter (or leave) the subnets and VLANs in the OCI half of the solution and NSX-T segments in the OCVS part. We’ll need to update the Security Rules in Security Lists for the Subnets and Network Security Groups for the VLANs. By default, the NSX-T firewalls are open but can be changed based on your security posture.

Update the vSphere VLAN Network Security Group

At a minimum, the Horizon components must connect to vCenter or the other management appliances so they will need Ingress rules to permit their traffic flows into the VLAN. You can customize the NSG rules based on your security posture.

• See creating a Network Security Group in the Oracle documentation.
• Create the ingress rule for Horizon Management network.
• Select “NSG for VLAN-<PrefixForEsxiHosts>-vSphere”:

Update the Uplink VLANs Network Security Group

Although the Uplink 2 VLAN is currently unused, it and the Uplink 1 VLAN share the Network Security Group. This group controls traffic leaving the SDDC through the T0. At build time it already has open egress permissions to all destinations. It also has open ingress permissions from the SDDC infrastructure VLANs’ IP subnets. If the other, native, OCI components are to be able to connect to workload components they will need Ingress rules to permit their traffic flows into the VLAN and through the T0.

For more detail, see OCVS – Networking Reference Architecture.

• See Network Security Groups in the Oracle documentation.
• Add the Network Security Group rules.
• Select “NSG for NSX Edge Uplink VLANs in <PrefixForEsxiHosts>”.

Note: The OCI management subnet is a customer-defined network in OCI.

OCI DNS Integration

OCI automatically adds DNS records to a "Private View". OCI components will use the private view via a DNS "server" on 169.254.169.254. Devices without an Oracle Cloud ID (OCID) cannot use the DNS Private View directly, as the DNS server/resolver has no way to route back across the underlay SDN to the client. Conversely, when we create an independent DNS environment on, for example, a domain controller with the DNS role, OCI components will not be able to resolve hosts from that DNS zone.

We can resolve both issues with the addition of OCI DNS Endpoints; a “Listener” Endpoint to respond to requests from our AD DNS, and a “Forwarder” Endpoint to forward queries from OCI devices to our AD DNS.

Create the DNS Endpoints

Although the Oracle Cloud console has an area within the Network section dedicated to the management of DNS records, the infrastructure parts of each VCN’s Private Resolver are accessed through the VCN Details screen.

See Private DNS resolvers in the Oracle documentation.

DNS Listener Endpoint

• Deploy the DNS Listener Endpoint to allow SDDC DNS servers to query OCI DNS FQDNs such as those of vCenter and so on.

DNS Forwarder Endpoint

• Deploy the DNS Forwarder Endpoint to allow OCI devices through the DNS Resolver to query FQDNs in the SDDC Domain/DNS servers.

Forwarding Rules

Although the Forwarder Endpoint gives us the ability to forward DNS queries for zones which the OCI Resolver is not authoritative for, it cannot do this without being told which domains to forward and where to forward their requests to.

Add a Rule to forward the Active Directory Domain name used in the SDDC, and a second to forward reverse (pointer) lookups for the IP subnets in the SDDC. This presupposes that PTR records are created with the forward lookups on the SDDC DNS server.

The Endpoints can take a couple of minutes to provision, and a Rule cannot be created until there is at least one Forwarding Endpoint available. If you try to complete this step too soon after the last one, you will see a warning panel on the Manage Rules dialog.

Updating the SDDC NSX Routing and Security

In this section, configure a route on NSX for external access to the Internet.

Creating NSX segments for Horizon Management, Desktops, internal UAG

• Access the Horizon SDDC (as listed earlier in this tutorial) to obtain the login information for the NSX-T and VCenter.
  • From the Oracle Cloud, select Hybrid, then select VMware Solution – Software-Defined-Data Centers (SDDC).
  • Select the SDDC and view the SDDC Information section for the VCenter and NSX Manager login credentials.
  • In this section, you can find the IP address and login credentials for VCenter and NSX. Use the login credentials to log in using a web browser that has access to SDDC.
• Log in to the NSX Manager dashboard.
• From the NSX Manager, select Networking, click Segments, and then click ADD SEGMENT.

Enable SDDC Internet Access

For SDDC workloads to access the Internet, the Uplink VLAN must have its Routing Table’s default route point towards an Internet or NAT gateway. In this example, we will only require outbound Internet access so will use a NAT Gateway.

Review the Oracle documentation on Create a NAT Gateway.

Add SNAT and NO_SNAT rules in NSX

The NAT Gateway configured in the previous section will Source-NAT all traffic sent to the Internet through it. This works with no additional configuration for native OCI devices whose network connections have OCIDs assigned. Unfortunately, this is not the case with the SDDC workloads which do not have OCIDs.

The T0 Uplink Interface (well, VIP) does have an OCID through its External Access IP on the Uplink 1 VLAN. For outbound SDDC traffic to make use of the NAT Gateway, we need to Source NAT it on egress from the T0 to the VIP address of the T0. This is carried out through the addition of a T0 SNAT rule in NSX, which translates the source address of all SDDC traffic heading for the Internet to that of the T0 VIP.

For the SNAT rule to match all possible Internet destinations, the Destination field of the SNAT rule must be set to 0.0.0.0/0 or “Any”. Unfortunately, this will also match all Private Network traffic heading for the VCN or the customer’s on-prem networks. To prevent this, we must add a NO_SNAT rule with a higher priority that matches the customer’s private networks. The easiest way to do this is to add NO_SNAT rules which match all three Private Address ranges defined in RFC1918.

• Log in to NSX Manager, navigate to the Networking tab and select NAT under Network Services. Select T0 for the logical router.
• If there are no NAT rules defined in the Policy UI, use the manager UI. If there are NAT rules in the Policy UI add these through the Policy UI.
• Create the NAT rules in the following table assigning them to both Uplink Interfaces on the T0.
• If no other NAT rules use Priority 1000 and 1100 (higher value = lower priority).
• If other NAT rules exist care should be taken to ensure these rules sit at the end, and that earlier rules do not clash with the intent of these rules.

External Access Networking

This section discusses networking configuration for Unified Access Gateway external access.

Unified Access Gateway External Access Configuration

As the connections in OCI VLANs are opaque to the underlying SDN, for devices outside the VLAN to connect to workloads inside it, we have to tag those workloads to help locate them within the VLAN. This is carried out by assigning “External Access IP” addresses to the VLAN. These are the same IP addresses assigned to the workload devices on the VLAN but allow the attachment of OCIDs to them. We will need an External Access IP address for each Unified Access Gateway.

Because the OCI Load Balancing service cannot maintain session persistence between the authentication (over TCP) and the protocol (over UDP) phases, we need to ensure each Unified Access Gateway is accessible directly from the Internet. We do this by assigning Public IP addresses to the External Access VIPs and pointing the VLAN’s Route Table default route to an Internet Gateway.

Assign Public IPs to External Access VIPs on Unified Access Gateways

Review the following Oracle documents:

• Reserved Public IPs
• Add external access to a VLAN

• Repeat steps for each of the Unified Access Gateways.

Note any assigned Public IP Addresses as these will be required for Unified Access Gateway or Public DNS configuration later.

Enable Internet Access to the UAG external VLAN

For VLAN workloads to access the Internet, the UAG External VLAN must have its Routing Table’s default route point towards an Internet or NAT gateway. As we require outbound and inbound Internet access, we must use an Internet Gateway.

• Add Route Rules for Internet Access

Load-Balancing

Customers can choose to use their own Load Balancer or Oracle Cloud Load Balancer as a Service. The Oracle Cloud Network Load Balancer will not work in this solution.

See the following topics in the Oracle documentation:

• Overview of Load Balancing
• Load Balancer Types

Load Balancer Service Configuration

See the following topics in the Oracle documentation:

• Creating a Load Balancer
• Step 3 – Configure Listener in creating a Load Balancer
• Creating a Load Balancer Log
• Editing a Load Balancer Backend Set or Adding a Load Balancer Backend Server
• Create the Load Balancer with the following settings:

Note: You must enable HTTP Health Status Checks in Unified Access Gateways.

• Initial HTTPS connection can be offloaded to the LB or passed through to the Unified Access Gateways.
  • Offload, select the HTTPS type option and configure accordingly.
  • Passthrough, select the TCP and Port 443 then configure accordingly.
• Subsequent connections will be direct to the Unified Access Gateway, certificates will be required for each UAG with appropriate FQDN/SAN details.
  • Edit the Load Balancer Backend Set
  • Add each Unified Access Gateway to the Backend set

Summary and Additional Resources

Now that you have come to the end of this design chapter on Omnissa Horizon 8 on OCVS, you can return to the reference architecture landing page and use the tabs, search, or scroll to select further chapter in one of the following sections:

• Overview chapters provide understanding of business drivers, use cases, and service definitions.
• Architecture chapters give design guidance on the Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
• Integration chapters cover the integration of products, components, and services you need to create the environment capable of delivering the services that you want to deliver to your users.
• Configuration chapters provide reference for specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.

Additional Resources

For more information about Omnissa Horizon 8 on OCVS, you can explore the following resources:

• OCVS product page
• Deploying Horizon 8 on OCVS

• Knowledge Base

Changelog

The following updates were made to this guide:

Author and Contributors

This chapter was written by:

• Hilko Lantinga is a Staff Engineer 2, Omnissa.

Contributors:

• Daniel Berkowitz, Senior Staff Architect, Omnissa.

Feedback

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.