Deploy a Local Broker

Enable a Local Broker

Reach out to your Netskope account team to get this feature enabled. Please note that this feature has a tenant wide flag.

Best Practices

Using at least a pair of Local Brokers per site/DC is recommended so they can provide high-availability access.
With new enhancements to Dynamic Steering, it is easier to select specific private apps when on-premises to steer via Local Broker.
DNS resolution for Local Broker Hostname needs to be carefully planned. Local Broker is not qualified to be internet facing and the hostname should not be resolvable by public DNS or VPN DNS.
A separate set of Publishers are required for Local Broker and Public Stitcher.
Use Advanced High Availability & scalability based on dynamic DNS/GSLB
GSLB provides dynamic DNS response based on:
- Resource Availability
- Geolocation
- Latency

Install a Local Broker

Install a Local Broker OVA in ESXI or Virtual Box

Go to Settings > Security Cloud Platform > Local Broker and download the OVA Local Broker.
Create a new VM based on the Prerequisites.
The default user is ubuntu and password is ubuntu. You will be prompted to reset the password upon first login.
In the event of a password change, the new password must meet the following minimum requirements:
- Minimum password length must be 14 characters.
- Must contain one upper case letter.
- Must contain one lower case letter.
- Must contain one digit (number).
- Must contain one non-alphanumeric character.
- Cannot be a palindrome.

Execute this curl command to install a local broker:

cd ~
pwd
#(Ensure you are in /home/ubuntu)
sudo apt-get -y update
curl https://s3.us-west-2.amazonaws.com/localbroker.netskope.com/latest/local-broker-install.sh | sudo bash; sudo su - $USER;exit

Confirm services are running using this command:

sudo microk8s kubectl get svc -n npa-dp-localbroker

Network Settings

We recommend that you disable DHCP, as it is currently not a supported configuration with Local Broker. This can be done with these configuration settings.
The config should look similar to what’s shown below, and execute sudo netplan apply followed by a reboot for changes to take effect:

ubuntu@npa-local-broker:~$ cd /etc/netplan
ubuntu@npa-local-broker:/etc/netplan$ cat 00-installer-config.yaml 
# This is the network config written by 'subiquity'
network:
  ethernets:
    ens33:
      dhcp4: no
      addresses: [192.168.1.173/24]
      gateway4: 192.168.1.1
      nameservers:
          addresses: [8.8.8.8, 8.8.4.4]
  version: 2
ubuntu@npa-local-broker:/etc/netplan$ 
ubuntu@npa-local-broker:/etc/netplan$ sudo netplan apply
ubuntu@npa-local-broker:/etc/netplan$ sudo reboot

Install a Local Broker VHDX in Hyper-V

Go to Settings > Security Cloud Platform > Local Broker and download the VHDX Local Broker.
Create a new VM in Hyper-V based on the Prerequisites.

Note

Choose Generation 1 for the generation of a VM.
The default user is ubuntu and password is ubuntu. You will be prompted to reset the password upon first login. In the event of a password change, the new password must meet the following minimum requirements:
- Minimum password length must be 14 characters.
- Must contain one upper case letter.
- Must contain one lower case letter.
- Must contain one digit (number).
- Must contain one non-alphanumeric character.
- Cannot be a palindrome.

Execute this curl command to install a local broker.

cd ~
pwd
#(Ensure you are in /home/ubuntu)
sudo apt-get -y update
curl https://s3.us-west-2.amazonaws.com/localbroker.netskope.com/latest/local-broker-install.sh | sudo bash; sudo su - $USER;exit

Confirm services are running.

sudo microk8s kubectl get svc -n npa-dp-localbroker

Follow the recommended Network Settings similar to OVA.

Install a Local Broker on Ubuntu VM in AWS

Bring up an Ubuntu VM running 20.04 LTS (c5.2xlarge) with the default (single NIC) configuration.

Execute these commands in an SSH session to install a Local Broker.

cd ~
pwd
#(Ensure you are in /home/ubuntu)
sudo apt-get -y update
sudo apt-get -y install docker.io
curl https://s3.us-west-2.amazonaws.com/localbroker.netskope.com/latest/local-broker-install.sh | sudo bash; sudo su - $USER;exit

Confirm services are running.

sudo microk8s kubectl get svc -n npa-dp-localbroker

UI Changes

Local Broker

A new Local Brokers page is available when the feature is enabled.

On this page you can create a new Local Broker instance and generate a token similar to Publishers. This token will be used to enroll your Local Broker and connect it to Netskope services.
You can also view the status of Local Brokers, versions, and CN.
There is an option to edit or delete the Local Broker if needed.
There is a required field to enter a DNS hostname for the Local Broker.

Publisher

You need to deploy a dedicated Publisher (or Publishers) for Local Broker(s).
When the DNS hostname is configured under the Local Broker section, and the feature (Local Broker) is enabled, a new option to enable “Local Broker Connection” within the Publisher configuration becomes available.
Enabling this will cause the Publisher to initiate a connection to the Local Broker instead of the Cloud Broker.
Further validation can be done from the Publisher CLI to check Local Broker connectivity.

Register a Local Broker

Generate a token for the Local Broker by going to Settings > Security Cloud Platform > Local Broker.
Click Copy to get the registration token.
Click Done.
SSH into the Local Broker, and when prompted for a menu choice, select Register.
When requested, enter the Netskope registration token, and then click Enter. You can also enter the token with this command:
```
sudo ./npa_localbroker_wizard -token <TOKEN> --local-broker
```
Go to Settings > Security Cloud Platform > Local Broker in your Netskope tenant and confirm your Local Broker has a Connected status.

Configure a DNS Hostname

The Local Broker hostname configured in the UI is fetched by both the Client and the Publisher.

The Client connects to the configured DNS hostname on TCP 443, and the Publisher connects to the configured DNS hostname on TCP 1443.

Let’s say the DNS Hostname configured is lbr.acme.com. The Client will attempt to connect to lbr.acme.com on TCP 443, and the Publisher will attempt to connect to lbr.acme.com on TCP 1443. It is important that these ports are allowed within the network.

The DNS hostname will need to be resolvable locally on the Client and Publisher, and can resolve to multiple IP addresses so connectivity will be load balanced to one of the IP addresses.

If testing in AWS, you can leverage Route 53 DNS zones. Example config below:

In the example above, DNS Hostname is configured as lbr.acme.com. Here, A records for three local broker instances – 172.31.25.83, 172.31.2.185 and 172.31.34.120 have been defined:

Go to Route 53 > DNS hosted zones and create a private hosted zone for lbr.acme.com, and add A records for lbr.acme.com to point to Local Broker IP address(es).

DNS Considerations

Here are some DNS considerations to take into account.

The Client and Publisher will attempt to resolve the Local Broker hostname using internal DNS in your environment.
It is expected that the internal DNS is set up correctly.
It is also expected that the hostname is resolvable internally (on-premises) and not from off-premises to avoid resolution when the user is not on-premises.
DNS for the hostname can be setup to resolve to multiple IPs (multiple A record entries).

Expected Behavior for Fallback

Client

The Client always attempts to connect to the Local Broker first. If there are multiple Local Brokers resolvable/reachable from the Client, the Client is expected to fall back to the next Local Broker if the active Local Broker were to fail.

A Client would fall back to a Cloud Broker if no Local Broker is available.

Note that it is expected/recommended to have a minimum of two Local Broker instances deployed. If there is only one Local Broker deployed, and it were to fail, the fallback would be to a Cloud Broker. However, when the Local Broker is backed up, the Client will not fall back to the Local Broker until the client tunnel is re-established.

Publisher

It is expected that there is a dedicated Publisher (or Publishers) deployed for a Local Broker. If there are multiple Local Brokers resolvable/reachable from the Publisher, it is expected that the Publisher will fall back to the next Local Broker if the active Local Broker were to fail.

Unlike Clients, Publishers will not fall back to Cloud Brokers if no other Local Broker is available.

Deploy a Local Broker