.. _installing-network-sensor: Installing Genian ZTNA ======================== .. meta:: :description lang=en: Get started Network Access Control with 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: :doc:`/controlling/controlling-cloudaccess`. 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: :doc:`/deploying/sizing`. 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 #. The command below can be used to install the ZTNA Policy Server .. code-block:: bash #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 .. code-block:: bash #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: :doc:`/controlling/controlling-onpremaccess`. 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 .. code-block:: bash 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 .. code-block:: bash 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): .. code-block:: bash #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: .. code-block:: bash #ifconfig enp1s0: flags=4163 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 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 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 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. .. code-block:: bash #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: .. code-block:: bash #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: .. code-block:: bash #ifconfig enp0s31f6: flags=4163 mtu 1500 inet6 fe80::201:2eff:fe83:cad7 prefixlen 64 scopeid 0x20 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 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 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 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 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 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 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 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 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): .. code-block:: bash #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: .. code-block:: bash #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