Installing Genian ZTNA

Choose Deployment Option

Genians Cloud-Managed

By utilizing the Genians Cloud, a Genian ZTNA Cloud deployment option is available that does not require customers to manually install and manage a Policy Server. With this option, the Policy Server is deployed through the my.genians.com web portal and hosted in the Genians Cloud. Once a ZTNA Policy Server has been deployed in the Genians Cloud, a ZTNA Sensor can be deployed through the Policy Server UI:

See: Controlling Access to Cloud Resources.

Customer Cloud or On-Premises

Policy Server(s) may also be installed in any customer Cloud environment or On-Prem in the customer's physical or virtual infrastructure.

To ensure your physical or virtual infrastructure meets the required specifications:

See: Sizing Software and Hardware.

Installing the ZTNA Policy Server in Customer Cloud or On-Prem

Install Ubuntu(20.04 or later) based system on a physical or virtual machine

Note

It is recommended to disable the secure boot setting before installing Ubuntu OS on both virtualized and physical systems.
If secure boot is enabled, some modules may not load properly.
vmware secure boot configure

The command below can be used to install the ZTNA Policy Server

#curl -s https://docs.genians.com/install/ztna-server.sh | sudo bash -s

Note

If installing on a virtual machine, be sure that the network adapter is set to bridged mode instead of NAT mode. The ZTNA Policy Server requires a dedicated IP address in order to function properly.

Installing the ZTNA Sensor in Customer Cloud or On-Prem

Install Ubuntu(20.04 or later) based system on physical or virtual machine

The command below can be used to install the ZTNA Sensor

#curl -s https://docs.genians.com/install/ztna-sensor.sh | sudo BRANCH= bash -s - POLICYSERVER.DOMAIN.ORIP

Note

If installing on a virtual machine, be sure that the network adapter is set to bridged mode instead of NAT mode. The ZTNA Sensor requires a dedicated IP address in order to function properly.

Network Connection Requirements (Sensor in Gateway Mode):

For Gateway mode, the Genian ZTNA Sensor only requires a single interface. That interface will be used to receive and filter incoming packets based on Enforcement and Permissions policies. See the Untagged/Access switch port section below. To configure a Sensor as a ZTNA Gateway:

See: Controlling Access to Customer Cloud or On-Prem Resources through a ZTNA Gateway.

Network Connection Requirements (Sensor in ARP Enforcement Mode):

Note

ARP Enforcement mode is available for On-Prem networks only

For ARP Enforcement mode, Genian ZTNA needs to monitor network broadcast packets (ARP, DHCP, uPNP...), so it must be connected to all the segments (broadcast domains) that you want to manage.

If you have a switch configured with VLANs, you can set up a tagged/trunk/802.1Q port to monitor multiple networks with one physical interface.

If you are installing Genian ZTNA in a virtual environment, the VM (Sensor) must have direct communication to and from all segments you wish to monitor and control. This may be accomplished in a variety of ways depending on your available hardware, and the capabilities of your virtualization platform.

Preparing Network Connection (Switch Side)

Untagged/Access Port

No additional configuration is required to monitor a single network over a switch untagged/access port. As long as the interface has a routable IP address, the Sensor can be used to either monitor a single network for ARP Enforcement or can be configured as a ZTNA Gateway.

Tagged/Trunk/802.1Q Port

To monitor multiple VLANs on a single interface, your switch port must be set to trunk mode with 802.1Q encapsulation. Below are examples of how to configure 802.1Q trunk ports for VLANs on common switches. In these examples, we will show how to add VLANs 55 and 77 to port 48, configured with dot1q encapsulation.

Cisco Switch

Cisco(config)#interface gi1/0/48
Cisco(config-if)#switchport trunk encapsulation dot1q
Cisco(config-if)#switchport mode trunk
Cisco(config-if)#switchport trunk allowed vlan add 55,77

HP Switch

Procurve(config)#vlan 55
Procurve(config)#tagged 48
Procurve(config)#vlan 200
Procurve(config)#tagged 77

Preparing Network Connection (Server Side)

Ubuntu Netplan Overview

Ubuntu 20.04 or later utilizes Netplan for server interface configuration. The default Netplan configuration can be viewed by issuing the command below (modify command as required if default .yml file has been renamed):

#sudo /etc/netplan
#sudo cat 00-installer-config.yaml

#This is the network config written by 'subiquity'
network:
  ethernets:
    enp1s0:
      dhcp4: no
      addresses:
        - 192.168.50.107/24
      gateway4: 192.168.50.1
      nameservers:
          addresses: [8.8.8.8, 1.1.1.1]
  version: 2

Using the ifconfig command the interface can be verified:

#ifconfig

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.50.107  netmask 255.255.255.0  broadcast 192.168.50.255
    inet6 fe80::201:2eff:fe83:cad8  prefixlen 64  scopeid 0x20<link>
    ether 00:01:2e:83:ca:d8  txqueuelen 1000  (Ethernet)
    RX packets 1415401  bytes 130383626 (130.3 MB)
    RX errors 0  dropped 206776  overruns 0  frame 0
    TX packets 45040  bytes 2388558 (2.3 MB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    inet6 ::1  prefixlen 128  scopeid 0x10<host>
    loop  txqueuelen 1000  (Local Loopback)
    RX packets 264  bytes 23972 (23.9 KB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 264  bytes 23972 (23.9 KB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Single VLAN (Untagged/Access Port Configured on Switch)

In the example above, the system installed has a single static IP address defined for management purposes. With this configuration, only nodes present in the 192.168.50.0/24 subnet (VLAN 50) will be discovered. No additional configuration is required if monitoring and enforcement of only a single VLAN/subnet is desired.

Multiple VLANs (Tagged/Trunk/802.1Q Port Configured on Switch)

If monitoring and enforcement of multiple VLANs/subnets is desired, the Netplan configuration must be modified to define sub-interfaces. This is accomplished by adding a second ethernet interface to the configuration under the ethernets section as well as adding a vlans section. In the example below, VLANS 55 and 77, as well as the corresponding subnets have been added to the configuration file.

#sudo /etc/netplan
#sudo cat 00-installer-config.yaml

#This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s31f6:
      dhcp4: no
    enp1s0:
      dhcp4: no
      addresses:
        - 192.168.50.107/24
      gateway4: 192.168.50.1
      nameservers:
          addresses: [8.8.8.8, 1.1.1.1]
  vlans:
    enp0s31f6.55:
      id: 55
      link: enp0s31f6
      addresses:
        - 192.168.55.200/24
    enp0s31f6.77:
      id: 77
      link: enp0s31f6
      addresses:
        - 192.168.77.200/24
  version: 2

To validate and apply the configuration, utilize the Netplan command option below and press ENTER when prompted:

#sudo /etc/netplan
#sudo netplan try
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 118 seconds
Configuration accepted.

Using the ifconfig command the new interfaces can be verified:

#ifconfig

enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet6 fe80::201:2eff:fe83:cad7  prefixlen 64  scopeid 0x20<link>
    ether 00:01:2e:83:ca:d7  txqueuelen 1000  (Ethernet)
    RX packets 1364841  bytes 110772537 (110.7 MB)
    RX errors 0  dropped 207338  overruns 0  frame 0
    TX packets 5765  bytes 1895530 (1.8 MB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device interrupt 16  memory 0xdf300000-df320000

enp0s31f6dot55: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.55.200  netmask 255.255.255.255  broadcast 0.0.0.0
    inet6 fe80::201:2eff:fe83:cad7  prefixlen 64  scopeid 0x20<link>
    ether 00:01:2e:83:ca:d7  txqueuelen 1000  (Ethernet)
    RX packets 10  bytes 946 (946.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 32  bytes 2524 (2.5 KB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s31f6dot77: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.77.200  netmask 255.255.255.255  broadcast 0.0.0.0
    inet6 fe80::201:2eff:fe83:cad7  prefixlen 64  scopeid 0x20<link>
    ether 00:01:2e:83:ca:d7  txqueuelen 1000  (Ethernet)
    RX packets 11  bytes 992 (992.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 30  bytes 2364 (2.3 KB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.50.107  netmask 255.255.255.0  broadcast 192.168.50.255
    inet6 fe80::201:2eff:fe83:cad8  prefixlen 64  scopeid 0x20<link>
    ether 00:01:2e:83:ca:d8  txqueuelen 1000  (Ethernet)
    RX packets 1438120  bytes 132237018 (132.2 MB)
    RX errors 0  dropped 208877  overruns 0  frame 0
    TX packets 49505  bytes 3046038 (3.0 MB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    inet6 ::1  prefixlen 128  scopeid 0x10<host>
    loop  txqueuelen 1000  (Local Loopback)
    RX packets 342  bytes 31583 (31.5 KB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 342  bytes 31583 (31.5 KB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Use the ping command to verify access to the gateway IP configured on each subnet (in this case .2 and .254 are the gateways):

#ping 192.168.77.2
PING 192.168.77.2 (192.168.77.2) 56(84) bytes of data.
64 bytes from 192.168.77.2: icmp_seq=1 ttl=255 time=6.22 ms
64 bytes from 192.168.77.2: icmp_seq=2 ttl=255 time=1.75 ms

#ping 192.168.55.254
PING 192.168.55.254 (192.168.55.254) 56(84) bytes of data.
64 bytes from 192.168.55.254: icmp_seq=1 ttl=255 time=12.8 ms
64 bytes from 192.168.55.254: icmp_seq=2 ttl=255 time=2.07 ms

Use the arp -a command to verify the gateway IPs for each subnet are associated with the sub-interfaces:

#arp -a
(192.168.55.254) at 04:fe:7f:22:91:41 [ether] on enp0s31f6.55
gateway (192.168.50.1) at 00:18:0a:09:c2:58 [ether] on enp1s0
(192.168.77.2) at 04:fe:7f:22:91:43 [ether] on enp0s31f6.77