Horizon on Oracle Cloud VMware Solution Configuration

This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of VMware Workspace ONE® and VMware Horizon® solutions. This chapter provides information about common configuration and deployment tasks for VMware Horizon on Oracle Cloud VMware® Solution.

Prerequisites

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

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

Review the following 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 Oracle Cloud on VMware Solution 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 VMware 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:

Creating Oracle Cloud VMware Solution 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. For additional information, see Creating VLAN-Backed Portgroups in Oracle Cloud VMware Solution.

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

Name

Target Type

Destination CIDR Block

Compartment

Target Internet Gateway

Description

Route Table for UAG External VLAN

Internet Gateway

0.0.0.0/0

Select the compartment

Customer defined

Customer defined

  • 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:

Stateless

Direction

Source Type

Source CIDR

IP Protocol

Source Port Range

Destination Port Range

Description

Unset

Egress

CIDR

0.0.0.0/0

All Protocols

All

All

Allow all Outbound

Unset

Ingress

CIDR

0.0.0.0/0

TCP

All

443

Inbound public 443 to UAG

Unset

Ingress

CIDR

0.0.0.0/0

TCP

All

8443

Inbound BLAST TCP 8443 to UAG

Unset

Ingress

CIDR

0.0.0.0/0

UDP

All

8443

Inbound BLAST UDP 8443 to UAG

Unset

Ingress

CIDR

0.0.0.0/0

TCP

All

4172

Inbound PCoIP TCP 4172 to UAG

Unset

Ingress

CIDR

0.0.0.0/0

UDP

All

4172

Inbound PCoIP UDP 4172 to UAG

Create the VLAN

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

  • VLANs are only available to customers who are subscribed to Oracle Cloud VMware Solution. 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”:

Name

Create in Compartment

VLAN Type

IEEE802.1Q VLAN Tag

CIDR Block

Route Table

Network Security Group

UAG External

Customer defined

Default – Regional

Customer defined

Customer defined UAG outer VLAN IP range

Route Table created above

NSG created above

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

Name

VCN

Network Field

Advanced Setup: VLAN

Physical NIC

uag-external-vnic.nic0

Customer defined

Advanced Setup: VLAN

UAG external VLAN created above

NIC 0

uag-external-vnic.nic1

Customer defined

Advanced Setup: VLAN

UAG external VLAN created above

NIC 1

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”.

Target Type

Destination Type

Destination CIDR Block

Compartment

Target Selection

Description

Private IP

CIDR Block

Workload SDDC

Select the compartment

Nsx-edge-up1-vip

OCVS SDDC Workload Networks via T0

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”:

Stateless

Direction

Source Type

Source CIDR

IP Protocol

Source Port Range

Destination Port Range

Description

Unset

Ingress

CIDR

<Horizon Management>

All Protocols

All

All

Allow all from Horizon Management Subnet

 

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 Oracle Cloud VMware Solution – 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>”.

Stateless

Direction

Source Type

Source CIDR

IP Protocol

Source Port Range

Destination Port Range

Description

Unset

Ingress

CIDR

management subnet

All Protocols

All

All

Customer defined -Allow All from management subnet

  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-T Manager dashboard.
  • From the NSX-T Manager, select Networking, click Segments, and then click ADD SEGMENT.

Segment Name

Connected Gateway

Transport Zone

Subnets

DHCP

Horizon Management

Tier-1|Tier-1

Overlay-TZ

CIDR

Optional, not recommended

Horizon Desktops

Tier-1|Tier-1

Overlay-TZ

CIDR

Optional, recommended

Internal DMZ

Tier-1|Tier-1

Overlay-TZ

CIDR

Optional, not recommended

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 following:

Add SNAT and NO_SNAT rules in NSX-T

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.

Priority

Description

Source

Destination

Action

Translated IP

Lowest

No NAT 10/8

Workload CIDR

10.0.0.0/8

NO_SNAT

N/A

Lowest

No NAT 172.16/12

Workload CIDR

172.16.0.0/12

NO_SNAT

N/A

Lowest

No NAT 192.168/16

Workload CIDR

192.168.0.0/16

NO_SNAT

N/A

Lowest +100

SNAT Internet to T0 VIP

Workload CIDR

0.0.0.0/0

SNAT

T0 VIP

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:

External Access Type

Private IP Name

Private IP Address

Reserved Public IP

Public Access

UAG Name

External DMZ Private IP

Public IP

  • 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

Target Type

Destination CIDR

Target Internet Gateway

Description

Internet Gateway

0.0.0.0/0

Your Internet Gateway

UAG Internet Access via Internet Gateway

 

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:

Load Balancer Service Configuration

See the following topics in the Oracle documentation:

 

Load Balancer Name

Visibility Type

Public IP Address

Select Existing Reserved IP

Networking

Subnet

Load Balancing Policy

Backend Servers

<customer defined>

Public

Reserved IP Address

<customer defined>

Customer VCN

Public LB Subnet

Least Connections

Skip till after LB is created

 

Health Check Policy Protocol

Port

Interval

Timeout

Number of retries

Status Code

URL Path

HTTP

80

Default

Default

3

200

/favicon.ico

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

Backend Set

Add Backends

IP Address

Port

Default

IP Addresses

UAG IP Address

443

What’s Next?

Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:

  • Overview chapters provide understanding of business drivers, use cases, and service definitions.
  • Architecture chapters explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
  • Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more.

 


 

Filter Tags

Horizon Horizon Document Reference Architecture Advanced Deploy