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.

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 Local Broker OVA.
Log in to your ESXi instance and click Virtual Machines.
Click Create/Register VM.
For Select Creation Type, select Deploy a virtual machine from an OVF or OVA file, and then click Next.
For Select OVA file, enter a name for the VM, drag and drop the OVA downloaded in step 1, and then click Next.
Select Storage, keep the default settings, and then click Next.
For Deployment Options, select your default network, and then click Next.
For Ready to Complete, review the settings to confirm, and then click Finish.
SSH into the local broker (default username: ubuntu, default password: ubuntu).
When prompted, change your password.
Note that 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.
After you change it, the system auto-disconnects your SSH session, so you will need to reconnect and log in with your new password before proceeding.
Register the local broker.

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:~$ sudo cat /etc/netplan/50-cloud-init.yaml 
network:
  ethernets:
    ens160:
# To interoperate with a Windows DHCP Server
#     dhcp-identifier: mac
      dhcp4: false
      addresses: [192.168.1.28/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8]
  version: 2
ubuntu@npa-local-broker:~$

Install a Local Broker on Ubuntu VM in AWS

Bring up an Ubuntu VM running 22.04 LTS (Minimum: c5.xlarge; Recommended: 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.
Select your Local Broker and click Generate Token.
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
```

After registration is successfully completed, all local broker pods, specifically npagw, npastitcher, and npa-stproxy should be active and operating in a running state.
Note that the pods calico-kube-controllers, calico-node, and coredns are default pods.

ubuntu@npa-local-broker:~$ sudo microk8s kubectl get pods -A
NAMESPACE            NAME                                       READY   STATUS    RESTARTS      AGE
kube-system          calico-kube-controllers-759cd8b574-wncl6   1/1     Running   2 (69m ago)   3d7h
kube-system          calico-node-649nt                          1/1     Running   0             68m
kube-system          coredns-7896dbf49-8xxf8                    1/1     Running   2 (69m ago)   3d7h
npa-dp-localbroker   local-npa-stproxy-fd8c4c976-zpqsv          1/1     Running   0             5m33s
npa-dp-localbroker   local-npagw-f47c986d8-k9x9t                1/1     Running   0             5m33s
npa-dp-localbroker   local-npastitcher-7869c5c5d8-jpvpk         1/1     Running   0             5m33s
ubuntu@npa-local-broker:~$ 
ubuntu@npa-local-broker:~$ sudo microk8s kubectl get svc -A
NAMESPACE            NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP    PORT(S)                  AGE
default              kubernetes            ClusterIP   10.152.183.1              443/TCP                  3d7h
kube-system          kube-dns              ClusterIP   10.152.183.10             53/UDP,53/TCP,9153/TCP   3d7h
npa-dp-localbroker   npa-stproxy-service   NodePort    10.152.183.125   10.136.10.25   5000:30128/TCP           11m
npa-dp-localbroker   npagw-service         NodePort    10.152.183.70    10.136.10.25   443:30443/TCP            11m
npa-dp-localbroker   npastitcher-service   NodePort    10.152.183.54    10.136.10.25   1443:30444/TCP           11m
ubuntu@npa-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).
If a Local Broker is intended to be internet facing, ensure that split DNS is configured so remote users can connect using a Public IP.

Upgrading a Local Broker

To upgrade your Local Broker, use the upgrade option within the Local Broker Wizard.

Through the wizard, you can apply both software and system updates. It will also indicate whether an upgrade is necessary.

Local Broker Selection and Fallback

Client

Clients will always attempt to connect to the Local Broker first.
If the DNS configured on the Client’s endpoint can resolve the Local Broker hostname to multiple IP addresses, the Client will validate connectivity to all these IPs and randomly select one for the connection.
If there are multiple Local Brokers resolvable/reachable from the Client, it is expected that the Client will fall back to the next Local Broker if the currently active one fails.
A Client would fall back to a Cloud Broker if no Local Broker is available.
It is important to note that deploying a minimum of two Local Broker instances is highly recommended. If only one Local Broker is deployed and it fails, the fallback will be to a Cloud Broker. However, once the Local Broker is operational, the Client will not automatically fall back to it until the client tunnel is re-established.

Publisher

A dedicated Publisher (or Publishers) is required to be deployed for a Local Broker.
If the DNS configured on the Publisher resolves the Local Broker Hostname to multiple IP addresses, the Publisher will validate connectivity to each IP address and randomly select one for establishing a connection.
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 currently active one fails.
It is important to note that, unlike Clients, Publishers will not fall back to Cloud Brokers if no other Local Broker is available.

Deploy a Local Broker