Configuring Gateways

introduction docid\ afistx9svtxuira4shuc9workflow creating a gateway in vmware vsphere docid\ afistx9svtxuira4shuc9workflow creating a gateway in amazon web services docid\ afistx9svtxuira4shuc9workflow creating a gateway in microsoft azure docid\ afistx9svtxuira4shuc9workflow creating a gateway in kvm/openstack docid\ afistx9svtxuira4shuc9workflow creating a gateway in google cloud platform docid\ afistx9svtxuira4shuc9workflow creating a gateway in oracle cloud platform docid\ afistx9svtxuira4shuc9 introduction this guide describes how to configure a zta gateway for your secure applications and resources to learn more about configuring ivanti connect secure (ics) gateways, refer instead to the ics tenant admin guide available from the nzta documentation portal a gateway is a virtual machine instance that you use to control access to your applications you deploy gateway instances at each location your applications reside at a physical datacenter, a private or public cloud based service, or some hybrid combination each gateway communicates with the controller to ensure that application access requests received from end user devices are authenticated before you deploy a gateway instance, you register a new gateway record in the controller through the tenant admin portal this record contains all basic identification, type, and network details required to enable secure communication between the controller and the gateway instance the registration process produces a package of settings, known as a gateway definition, that you publish to the gateway virtual machine instance during deployment these settings enable the gateway to establish communication back to the controller make sure the gateway virtual machine instance does not exist prior to registration with the controller each zta gateway must be deployed from the controller directly the gateway definition file is designed to be published to a new virtual machine gateway instance during its initial deployment you deploy a gateway virtual machine instance from a supplied template each gateway template is pre configured to define the required virtual machine settings and network interfaces for the target platform during deployment, you specify the values for each defined interface according to the public and private subnets configured in your network infrastructure each zta gateway virtual machine uses a number of network interfaces external network interface configured with a public subnet ip address and used for external client access to the applications deployed in that datacenter use this ip address during the process of creating your gateway record on the controller internal network interface configured with a private subnet ip address and used for internal connections to the deployed applications, and for external communication with the controller (optional) management network interface configured with an ip address and port on a further, separate, network subnet for deployments where a specific management interface is required when the management interface is enabled, the gateway communicates with the controller through this interface instead in this scenario, the gateway still uses the internal network interface for dns resolution and ntp server communication as such, the gateway dns server should resolve the controller and ntp server fqdns through the internal interface (internet access is required) to ensure communication between your gateways, the controller, and your client users, make sure the following network connections are enabled configure the firewall rules for the public subnet in which your zta gateway external interface resides is configured to accept inbound client connections on tcp port 443 configure the network gateway serving your private subnet to allow outbound tcp traffic to the controller on port 443 configure the network gateway serving your private subnet to allow outbound udp traffic to the following network time protocol (ntp) services time windows com (port 123) time nist gov (port 123) if you are planning to use your zta gateway to serve saas (software as a service) applications, configure the application to restrict inbound connections to your network gateway ip address this ensures that your saas application can be reached only by clients connecting through the zta gateway if you maintain your own dns service at the datacenter, use these details during gateway record creation on the controller white listing required ip addresses for your services the controller service uses a series of ip addresses and ports to facilitate access to the admin and user web consoles, for user enrollment, and for connections to a zta gateway to ensure network access, make sure the following ip addresses and ports are white listed (or added to the allowed list ) in your network firewalls and routing infrastructure select the ip addresses and ports for your corresponding region only north america 52 186 44 249 (port 443) 52 188 33 186 (port 443) europe 51 138 111 17 (port 443) 20 50 150 82 (port 443) apj 20 44 238 229 (port 443) 20 44 237 67 (port 443) uae 20 233 40 108 (port 443) 20 233 41 69 (port 443) canada 20 220 157 85 (port 443) 20 220 157 158 (port 443) high availability nzta allows you to deploy multiple gateways at a single location to support high availability this arrangement can be used to provide scaling, redundancy, and load distribution for your application delivery high availability is implemented in the controller through gateway groups you add individual gateways to a group, and then associate the group with your secure access policy to learn more about high availability and using gateway groups, see the tenant admin guide configuring a default gateway nzta directs requests from each application towards the gateway defined in the secure access policy for the application a default zta gateway can be defined this gateway handles all requests from application that are not referenced by any secure access policy this enables packet analysis to be conducted on requests passing through the gateway to assess the validity of the requests two default gateway scenarios are supported any single gateway at v21 1 (or later) can be assigned to act as the default gateway this gateway is exclusively used as the default gateway alternatively, any gateway group whose gateways are all at v21 1 (or later) can be assigned to act as the default gateway in this scenario, the gateways are used exclusively as the default gateway the gateway group is typically fronted by a load balancer to enable the required distribution of requests across the gateways in the group to configure a default zta gateway, you must edit and update the built in application discovery secure access policy the default gateway (or gateway group) then handles all requests from applications on enrolled devices that are not referenced by any other secure access policy to learn more about using a default gateway, see the tenant admin guide gateway deployment workflows nzta supports gateway virtual machine instances deployed in the following environments vmware vsphere see workflow creating a gateway in vmware vsphere amazon web services (aws) see workflow creating a gateway in amazon web services microsoft azure see workflow creating a gateway in microsoft azure kvm/openstack see workflow creating a gateway in kvm/openstack google cloud platform see workflow creating a gateway in google cloud platform for 22 7r1 3 release, 22 7r2 2 zta gateway version is not supported with oracle, aws, and kvm platforms workflow creating a gateway in vmware vsphere this workflow leads you through the process for setting up a gateway in vmware vsphere it contains two main procedures, in sequence creating the gateway record in the controller creating the gateway virtual machine instance in vmware vsphere after these steps have been completed successfully, the controller and gateway establish communication with each other before you start, make sure you have the following information and files for the gateway an identifying name for the gateway the public ip address for the gateway this is the ip address at which clients can externally reach the gateway instance the gateway geographic location (optional) the name of the gateway group to which you want to add this new gateway record to learn more about gateway groups, see the tenant admin guide additionally, if you want to manually specify gateway network interface settings the internal/private subnet ip address, subnet mask, and network gateway ip address the primary (and optional secondary) dns server ip address, and search domain the external interface ip address, subnet mask, and network gateway ip address (optional) the management interface ip address, subnet mask, and network gateway ip address credentials for the vsphere console these credentials must include sufficient permissions to create a virtual machine from a template image to set up a zta gateway in vmware vsphere, perform the following steps log into the tenant admin portal using the credentials provided in your welcome email two outcomes are possible on unconfigured nzta systems, the secure access setup (onboarding) wizard appears in this case, click add gateway on configured nzta systems, the network overview page appears in this case from the nzta menu, click the secure access icon, then select gateways > gateway list the gateways list page appears, showing the full list of gateway groups and standalone gateways currently configured on the controller to add a new gateway, select create from the top right in the drop down menu, click create zta gateway in both cases, the gateway details dialog appears to learn more about the settings on this page, see the tenant admin guide (optional) to enter your vsphere gateway instance dns and network interface settings manually, select use manual settings to instead allow nzta to use dhcp derived settings for dns and network interfaces, leave use manual settings un selected enter a name for the gateway enter one or more public address or cname (public ip address or cname) for the gateway select add to add each entry to the list select a geographic location for the gateway for gateway platform , select "vmware vsphere" (optional) select a gateway group to which the new gateway is to be added (optional) select the use management port check box to use management network ports for nzta traffic rather than internal ports when the management port is enabled, the will controller still use the internal port for dns resolution if the internal dns cannot resolve the controller domain, the internal interface will require internet access (optional) select the use dynamic tunnel ip check box to configure a pool of ip addresses that are dynamically mapped to client sessions with this gateway, such that user traffic from the gateway to an application can be identified as originating from a specific client the custom ip pool dialog appears dynamic tunnel ip addresses are not supported in gateway groups use the assignable custom ipv4 address field to enter an ip address and subnet (in the range 8 28) in cidr notation, then click add repeat this step for each address/subnet you want to use (optional) select the use proxy server for communication check box to enable nzta to controller communication via proxy server proxy is supported on both internal and management interfaces of the gateway once enabled, enter host name and port optionally, if your proxy server requires further authentication, enter a username and password to log in to the proxy server admin can configure proxy for existing gateway after upgrading it to 22 4r3 version or later if you elected to use manual settings, the following panel appears enter the following details specify the internal ip address for the gateway specify the internal subnet mask for the gateway specify the internal network gateway ip address as the gateway setting enter the primary dns ip address for the gateway (optional) enter the secondary dns ip address for the gateway enter the dns search domain for the gateway specify the external ip address for the gateway specify the external subnet mask for the gateway specify the external network gateway ip address as the gateway setting management network settings are optional, unless the use management port check box is selected specify the management ip address for the gateway specify the management subnet mask for the gateway specify the management network gateway ip address as the gateway setting to add a gateway definition based on the settings you specified in this dialog, select create configuration after you complete this process, an unregistered gateway record is created on the controller you can view this gateway record on the gateways > gateways list page on the gateways list page, select your vsphere gateway and click the download icon to obtain a copy of the gateway definition file retain this file for a later step the gateway definition file is valid for 24 hours if this period expires, you must replace the gateway to generate a new gateway definition file (optional) if you have not yet downloaded the latest version of your gateway vm file, click the download icon and select download gateway vm image save the archive file and unpack to a local workstation make sure the resulting file set is accessible from the vsphere console access the vsphere management interface , either from a client or a web browser, and log in using your vsphere credentials in the vsphere console, start the deploy ovf template wizard to create a new virtual machine based on the nzta vsphere gateway template in the wizard choose to deploy from a local file locate and upload your zta gateway ovf/vmdk template files provide an identifying name and location for the new gateway virtual machine choose any required compute resource for reference, the recommended minimum requirements for a gateway virtual machine instance in vsphere are 4 vcpu's and 8 gb memory, or 8 vcpu's and 32 gb memory choose the required storage settings customize the vapp properties of your virtual machine and, in the va ive configuration parameter, paste the raw text of the gateway definition file downloaded earlier confirm all settings finish the wizard to create the gateway virtual machine locate the new gateway virtual machine in the hosts and clusters start the gateway virtual machine by powering it on wait until the boot up process is complete return to the gateways list page on the controller locate the new gateway record in the list and confirm that its connection status has updated to connected after you have registered a gateway, you can configure it (or the gateway group to which it belongs) as the default gateway if required see the tenant admin guide for details workflow creating a gateway in amazon web services for 22 7r1 3 release, 22 7r2 2 zta gateway version is not supported with oracle, aws, and kvm platforms this workflow leads you through the process for setting up a gateway in amazon web services (aws) it contains two main procedures, in sequence creating the gateway record in the controller creating the gateway virtual machine instance in aws after these steps have been completed successfully, the controller and gateway establish communication with each other before you start, make sure you have the following information and files an identifying name for the gateway the public ip address for the gateway this is the ip address at which clients can externally reach the gateway instance, typically an elastic ip address provided by aws the gateway geographic location (optional) the name of the gateway group to which you want to add this new gateway record to learn more about gateway groups, see the tenant admin guide the primary (and optional secondary) dns server ip address, and search domain the gateway ami identifier nzta gateway amis are available in all aws regions (except china) to obtain the ami applicable to your region, follow these steps log into the aws console navigate to ec2 > images > amis select "public images" search for the image corresponding to your selected hypervisor nitro "isa v nitro zta 22 7r2 2 607 1 img" make a note of the corresponding ami id credentials for the aws management console these credentials must include sufficient permissions to create a stack the ssh public key that you are using with the aws management console to set up a zta gateway in aws, perform the following steps log into the tenant admin portal using the credentials provided in your welcome email two outcomes are possible on nzta unconfigured systems, the secure access setup (onboarding) wizard appears in this case, click add gateway on nzta configured systems, the network overview page appears in this case from the nzta menu, click the secure access icon, then select gateways > gateway list the gateways list page appears, showing the full list of gateway groups and standalone gateways currently configured on the controller to add a new gateway, select create from the top right in the drop down menu, click create zta gateway in both cases, the gateway details dialog appears to learn more about the settings on this page, see the tenant admin guide enter a name for the gateway enter one or more public address or cname (public ip address or cname) for the gateway select add to add each entry to the list select a geographic location for the gateway for gateway platform , select "amazon web services" (optional) select a gateway group to which the new gateway is to be added (optional) select the use management port check box to use management network ports for nzta traffic rather than internal ports when the management port is enabled, the controller will still use the internal port for dns resolution if the internal dns cannot resolve the controller domain, the internal interface will require internet access (optional) select the use proxy server for communication check box to enable nzta to controller communication via proxy server proxy is supported on both internal and management interfaces of the gateway once enabled, enter host name and port optionally, if your proxy server requires further authentication, enter a username and password to log in to the proxy server admin can configure proxy for existing gateway after upgrading it to 22 4r3 version or later enter the primary dns ip address for the gateway (optional) enter the secondary dns ip address for the gateway enter the dns search domain for the gateway make sure the specified dns service can resolve the ip address of your controller issues here can cause registration of the gateway with the controller to fail to add a gateway definition based on the settings you specified in this dialog, select create configuration after you complete this process, an unregistered gateway record is created on the controller you can view this gateway record on the gateways > gateways list page on the gateways list page, select your new gateway and click the download icon to obtain a copy of the gateway definition file retain this file for a later step the gateway definition file is valid for 24 hours if this period expires, you must replace the gateway to generate a new gateway definition file (optional) if you have not yet downloaded the latest version of your gateway vm file, click the download icon and select download gateway vm image save the archive file and unpack to a local workstation make sure the resulting file set is accessible from the aws management console access the aws management console and log in using your aws credentials in the aws services menu, select cloudformation the cloudformation home page appears click create stack and then, from the sub menu, select with new resources (standard) the specify template step of the create stack wizard appears under prerequisite prepare template , select the template is ready option under specify template , select the upload a template file template source option under upload a template file , click choose file and select the gateway template file that you downloaded at the start of this process the file uploads, and the aws s3 url for the uploaded template file appears automatically click next the specify stack details step of the create stack wizard appears this page displays the details and parameters required by the gateway template enter a stack name specify the parameters as appropriate for your deployment if you are deploying the gateway instance into a new vpc, you can accept the default values used for all parameters if you are deploying the instance into an existing vpc, you must manually specify the details of your existing vpc into the parameters on the page for more information, contact technical support under nzta configuration , identify the required gateway ami using its nzta gateway ami id choose the designated ami for the region in which you are deploying the gateway instance for instance type , select the instance type that fits your hypervisor choice (nitro) and minimum requirements, based on the following recommended types for reference, the recommended minimum requirements for a gateway virtual machine instance in aws are for nitro hypervisor based instances, use m5 types m5 large (2 vcpu, 8 gb memory) (2nic min) m5 xlarge (4 vcpu, 16 gb memory) (3nic min) m5 2xlarge (8 vcpu, 32 gb memory) m5 4xlarge (16 vcpu, 64 gb memory) under nzta config data , paste in the raw text of the gateway definition file downloaded earlier for ssh key name , specify your existing ssh key pair name for load balancer configuration , if you plan to deploy multiple gateways inside a gateway group, select "yes" to deploy a new internet facing network load balancer instance alongside the gateway select "no" to launch only this gateway instance this option is applicable only for new vpc templates if you elect to launch a load balancer, the following pre configuration is applied an elastic ip address is assigned to the load balancer a tcp listener is configured on port 443 an ip based target group is created and the private ip address of the deployed gateway's external network interface is added as a target a health check is configured on tcp port 443 stickiness is enabled on the target group after you have deployed the gateway and load balancer, you must return to the tenant admin portal on the controller and update the gateway group load balancer ip address setting to be the load balancer's public ip address if you want to configure the load balancer to balance across further gateway instances from the gateway group, you must deploy each subsequent gateway into an existing vpc and then update the load balancer target group with new vpc templates, a nat gateway is deployed for routing outbound internet traffic from the gateway's internal network interface in order for the gateway to be able to reach the controller public ip addresses are not automatically assigned to any of your gateway's network interfaces if you are deploying a gateway into an existing vpc, in order for the gateway to be able to reach the controller from it's internal network interface, make sure you allow outbound internet traffic from the private subnet for the deployed gateway to learn more about high availability and gateway groups, see the tenant admin guide click next the configure stack options step of the create stack wizard appears all properties that were specified either in the template or in earlier steps are populated automatically no changes or new inputs are required click next the review step of the create stack wizard appears confirm all displayed details click create stack the stacks page appears the new stack is listed using the stack name you specified during the wizard the new stack has a status of create in progress wait for the status of the new stack to reach create complete (this step is required only if you have not deployed your gateway with a load balancer or nat at the front end) elastic ip addresses are not automatically assigned to any of the gateway's network interfaces therefore, before you can access the new gateway instance from the controller, you must associate a new public ip address with the external interface of the gateway then, return to the tenant admin portal and update the gateway public ip address setting to match this address in the tenant admin portal secure access > gateways > gateways list page, locate the new gateway record and confirm that its connection status has updated to connected you can directly access your aws instance over ssh using aws ec2 instance connect to configure aws ec2 instance connect , refer to the amazon web service documentation you can then connect to the instance directly as a serial console using ssh from inside the aws management console , refer to the amazon web service documentation after you have registered a gateway, you can configure it (or the gateway group to which it belongs) as the default gateway if required see the tenant admin guide for details workflow creating a gateway in microsoft azure this workflow leads you through the process for creating and registering a zta gateway in microsoft azure it contains two main procedures, to be completed in sequence create the gateway record in the controller create the gateway virtual machine instance in azure and register it with the controller azure offers two methods for launching a gateway virtual machine instance through the azure marketplace using the provided template and image files zta gateway instances in azure marketplace is limited to version 21 3r1 to use a gateway version later than 21 3r1, either launch the azure marketplace version and upgrade in place to the latest version, or use the alternate procedure described below to launch a gateway instance using the template and image files before you start, make sure you have the following information and files an identifying name for the gateway the gateway geographic location (optional) the name of the gateway group to which you want to add this new gateway record to learn more about gateway groups, see the tenant admin guide the primary (and optional secondary) dns server ip address, and search domain the ssh public key that you are using with the azure portal or management console ssh keys can be generated using sshkeygen on linux and macos, or puttygen on windows for further details about generating ssh key pairs, see for windows https //docs microsoft com/en us/azure/virtual machines/linux/ssh from windows https //docs microsoft com/en us/azure/virtual machines/linux/ssh from windows for macos and linux https //docs microsoft com/en us/azure/virtual machines/linux/mac create ssh keys https //docs microsoft com/en us/azure/virtual machines/linux/mac create ssh keys credentials for the azure portal or management console these credentials must include sufficient permissions to create a virtual machine a public ip address or cname for the gateway this is the ip address or cname at which client devices can externally reach the gateway instance to create a gateway record in the controller, perform the following steps log into the tenant admin portal using the credentials provided in your welcome email two outcomes are possible on nzta unconfigured systems, the secure access setup (onboarding) wizard appears in this case, click add gateway on nzta configured systems, the network overview page appears in this case from the nzta menu, click the secure access icon, then select gateways > gateway list the gateways list page appears, showing the full list of gateway groups and standalone gateways currently configured on the controller to add a new gateway, select create from the top right in the drop down menu, click create zta gateway in both cases, the gateway details dialog appears to learn more about the settings on this page, see the ics tenant admin guide enter a name for the gateway enter one or more public address or cname (public ip address or cname) for the gateway select add to add each entry to the list for azure marketplace deployments, a public ip address or cname is typically allocated at deployment time through the azure portal therefore, if you do not yet know the expected address/cname, enter a dummy value in this field now and update the setting after you have deployed and registered the gateway instance for more details on this process, see creating a gateway through azure marketplace select a geographic location for the gateway for gateway platform , select "azure" (optional) select a gateway group to which the new gateway is to be added (optional) select the use management port check box to use management network ports for nzta traffic rather than internal ports when the management port is enabled, the controller will still use the internal port for dns resolution if the internal dns cannot resolve the controller domain, the internal interface will require internet access (optional) select the use proxy server for communication check box to enable nzta to controller communication via proxy server proxy is supported on both internal and management interfaces of the gateway once enabled, enter host name and port optionally, if your proxy server requires further authentication, enter a username and password to log in to the proxy server admin can configure proxy for existing gateway after upgrading it to 22 4r3 version or later enter the primary dns ip address for the gateway (optional) enter the secondary dns ip address for the gateway enter the dns search domain for the gateway make sure the specified dns service can resolve the ip address of your controller issues here can cause registration of the gateway with the controller to fail to add a gateway definition based on the settings you specified in this dialog, select create configuration after you complete the first part of this workflow, an unregistered gateway record is created on the controller this gateway record can be seen on the gateways > gateways list page on the gateways list page, select your new gateway and click the download icon to obtain a copy of the gateway definition file retain this file for a later step the gateway definition file is valid for 24 hours if this period expires, you must replace the gateway to generate a new gateway definition file (optional) if you have not yet downloaded the latest version of your gateway vm file, click the download icon and select download gateway vm image save the archive file and unpack to a local workstation make sure the resulting file set is accessible from the microsoft azure console next, decide which azure deployment process you want to follow launching an instance through azure marketplace, or creating an instance using the supplied template and image files to launch an instance from azure marketplace, see creating a gateway through azure marketplace to create an instance using the nzta template and image files, see configuring gateways creating a gateway through azure marketplace zta gateway instances in azure marketplace are limited to version 21 3r1 at the present time to use a gateway version later than 21 3r1, either launch the azure marketplace version and upgrade in place to the latest version (for more details, see the tenant admin guide ) or use the alternate procedure described in configuring gateways to launch a gateway instance using the template and image files to launch a gateway virtual machine in microsoft azure from the azure marketplace, perform the following steps log into the microsoft azure portal ( http //portal azure com http //portal azure com ) navigate to the azure marketplace by clicking create a resource in the search the marketplace text box, enter "ivanti" azure marketplace presents the results relevant to your search term locate ivanti neurons zero trust access gateway and click create in the drop down list, choose the option that is applicable to your needs ivanti neurons zero trust access gateway byol 3 nic includes 3 network interfaces (internal, external, and management) ivanti neurons zero trust access gateway byol 2 nic includes 2 network interfaces (internal and external) to first learn more about ivanti neurons zero trust access gateway , click the product banner and view the associated information page you can launch a new gateway instance from this page the create ivanti neurons zero trust access gateway process appears on the basics tab, enter the following details subscription if you are using the "pzt dev" subscription, leave this field as the default value otherwise, enter your subscription name resource group specify the resource group in which the gateway needs to be deployed, or create a new resource group using the link provided an azure resource group is a container for a collection of connected assets that you assign to a virtual machine to learn more, see the azure documentation ( https //docs microsoft com/azure https //docs microsoft com/azure ) region specify the geographic region in which the gateway instance is deployed ivanti neurons zero trust access gateway vm name enter a suitable name for your gateway instance this name must be 1 9 characters long, using only lowercase letters or numbers ssh public key source select "use existing public key" ssh public key copy and paste an rsa public key in a single line format or the multi line pem format ssh keys can be generated using sshkeygen on linux and macos, or puttygen on windows for further details about generating ssh key pairs, see for windows https //docs microsoft com/en us/azure/virtual machines/linux/ssh from windows https //docs microsoft com/en us/azure/virtual machines/linux/ssh from windows for macos and linux https //docs microsoft com/en us/azure/virtual machines/linux/mac create ssh keys https //docs microsoft com/en us/azure/virtual machines/linux/mac create ssh keys to continue, click next network settings > on the network settings page, enter the following details virtual network a virtual network is a logical isolation of the azure cloud dedicated to your services the value you enter here affects the ip address and subnet allocations for all network interfaces shown on this page azure pre populates this field with a new virtual network name, although you can select your own predefined virtual network as necessary to create a new virtual network, perform the following steps click the create new link under the virtual network setting the create virtual network dialog appears enter a virtual network name enter an address space in cidr notation (for example, 192 0 2 0/24) for each interface subnet, use the automatically populated name and address values provided, or enter your own details each subnet must be contained by the address space entered in the previous setting to save your changes, click ok your new virtual network settings are populated into the corresponding interface settings in the main network settings page internal subnet the subnet identifier for the internal network, pre populated by either the selected virtual network or your newly entered virtual network settings external subnet the subnet identifier for the external network, pre populated by either the selected virtual network or your newly entered virtual network settings (for 3 nic instances only) management subnet the subnet for the management network, pre populated by either the selected virtual network or your newly entered virtual network settings public ip for ivanti neurons zero trust access gateway external interface lb the public ip address identifier at which clients can externally reach the gateway instance, typically provided by azure before you can connect to the new gateway instance from the controller, you must update the controller with the public ip address or cname assigned to the external interface of the gateway load balancer this process is described later dns prefix for external interface lb the unique dns name for the public ip address specified for the external interface load balancer public ip for nat gateway the public ip address identifier of a nat gateway for the virtual machine to communicate with the controller and other public resources dns prefix for nat gateway public ip the unique dns name for the public ip address specified for the internal interface nat gateway deploy ivanti neurons zero trust access gateway with load balancer to deploy this gateway with a load balancer, select "yes" from the drop down list the front end ip address of the load balancer is then used as the public ip address for your gateway if you select "no" to not deploy a load balancer, you must create and associate a public ip address to the external interface of your instance after deployment is complete in all cases, on completion of this process, you must update the controller gateway definition with the correct public ip address for your azure gateway instance to continue, click next instance configuration > on the instance configuration page, enter the following details ivanti neurons zero trust access gateway vm size this is the specification of the virtual machine choose from for 2nic instances, select "1 x standard ds2 v2" for 3nic instances, select "1 x standard ds4 v2" diagnostic storage account the storage account for the virtual machine diagnostics the default value is a new account based on your vm name ivanti neurons zero trust access gateway version specify the version applicable to the current nsa version, or the version you require ivanti recommends you select the latest available version ivanti neurons zero trust access gateway config data paste in the raw text of your gateway definition file to obtain the gateway definition file, see the process described earlier in this section to continue, click next review + create > on the review + create page, verify the proposed configuration is validated successfully, and then click create to create your new gateway instance after a short wait, your instance is created and deployed access the virtual machine settings for your new gateway instance, and click networking from the settings menu the networking dialog appears, showing your attached network interfaces (internal, external, and (optionally) management) click the tab that corresponds to the external network interface the settings for the external network interface appear locate the nic public ip field and make a note of the ip address shown there this is the public ip address you use to reconfigure the controller record for this gateway if no public ip address is shown, determine if a load balancer was deployed together with your gateway instance by selecting the load balancing tab if a load balancer was deployed, make a note of the frontend ip address displayed in this tab and use this as the gateway public ip address on the controller if a load balancer was not deployed, create a public ip address and associate it with the external interface then, use this ip address as the gateway public ip address on the controller to learn about configuring ip addresses in the azure portal, see the microsoft azure documentation return to the nzta tenant admin portal, and click secure access > gateways > gateways list the gateways list page appears make sure the new azure gateway instance is shown in the list of configured gateways and is connected (connection status is connected ) select the new gateway, then select secure access > gateways > configuration and locate gateway network settings enter the public ip address you noted from the azure virtual machine settings make sure you remove any previously entered dummy values to save your changes, click save changes this completes the azure gateway registration process your enrolled client devices should now be able to connect to the gateway workflow creating a gateway in kvm/openstack for 22 7r1 3 release, 22 7r2 2 zta gateway version is not supported with oracle, aws, and kvm platforms this workflow leads you through the process for setting up a kvm gateway in openstack it contains two main procedures, in sequence preparing to create a kvm gateway, see preparing to create a kvm gateway creating the gateway record in the controller, see adding a kvm gateway in nsa preparing metadata for openstack, see preparing metadata for openstack creating the kvm gateway virtual machine instance in openstack, see creating the kvm gateway virtual machine instance in openstack after these steps have been completed successfully, the controller and gateway establish communication with each other preparing to create a kvm gateway before you start, make sure you have the following information and files an identifying name for the gateway the public ip address for the gateway this is the ip address at which clients can externally reach the gateway instance the gateway geographic location (optional) the name of the gateway group to which you want to add this new gateway record to learn more about gateway groups, see the tenant admin guide additionally, to manually specify kvm gateway network interface settings the primary (and optional secondary) dns server ip address, and search domain the required internal/private subnetworks must already be defined on openstack please refer to the openstack documentation for details the required external subnetworks must already be defined on openstack please refer to the openstack documentation for details (optional) any required management subnetwork must already be defined on openstack please refer to the openstack documentation for details credentials for the openstack console these credentials must include sufficient permissions to create a virtual machine from a template image after you have all required information, you can set up a nzta kvm gateway, see adding a kvm gateway in nsa adding a kvm gateway in nsa to set up a nzta kvm gateway, perform the following steps log into the tenant admin portal using the credentials provided in your welcome email two outcomes are possible on nzta unconfigured systems, the secure access setup (onboarding) wizard appears in this case, click add gateway on nzta configured systems, the network overview page appears in this case from the nzta menu, click the secure access icon, then select gateways > gateway list the gateways list page appears, showing the full list of gateway groups and standalone gateways currently configured on the controller to add a new gateway, select create from the top right in the drop down menu, click create zta gateway in both cases, the gateway details dialog appears to learn more about the settings on this page, see the tenant admin guide enter a name for the gateway enter one or more public address or cname (public ip address or cname) for the gateway select add to add each entry to the list select a geographic location for the gateway for gateway platform , select "kvm" (optional) select a gateway group to which the new gateway is to be added (optional) select the use management port check box to use management network ports for nzta traffic rather than internal ports when the management port is enabled, the controller will still use the internal port for dns resolution if the internal dns cannot resolve the controller domain, the internal interface will require internet access (optional) select the use dynamic tunnel ip check box to configure a pool of ip addresses that are dynamically mapped to client sessions with this gateway, such that user traffic from the gateway to an application can be identified as originating from a specific client the custom ip pool dialog appears dynamic tunnel ip addresses are not supported in gateway groups use the assignable custom ipv4 address field to enter an ip address and subnet (in the range 8 28) in cidr notation, then click add repeat this step for each address/subnet you want to use (optional) select the use proxy server for communication check box to enable nzta to controller communication via proxy server proxy is supported on both internal and management interfaces of the gateway once enabled, enter host name and port optionally, if your proxy server requires further authentication, enter a username and password to log in to the proxy server admin can configure proxy for existing gateway after upgrading it to 22 4r3 version or later enter the primary dns ip address for the gateway (optional) enter the secondary dns ip address for the gateway enter the dns search domain for the gateway make sure the specified dns service can resolve the ip address of your controller issues here can cause registration of the gateway with the controller to fail to add a gateway definition based on the settings you specified in this dialog, select create configuration after you complete the first part of this workflow, an unregistered gateway record is created on the controller this gateway record can be seen on the gateways > gateways list page you can now prepare your metadata, see preparing metadata for openstack preparing metadata for openstack the preparation of metadata for use on openstack currently requires some manual steps log into and nzta access the gateways > gateways list page on the gateways list page, select your new gateway and click the download icon to obtain a copy of the gateway definition file specify a save location for your gateway definition file the gateway definition file is valid for 24 hours if this period expires, you must replace the gateway to generate a new gateway definition file (optional) if you have not yet downloaded the latest version of your gateway vm file, click the download icon and select download gateway vm image save the archive file and unpack to a local workstation make sure the resulting file set is accessible from the openstack management console view the gateway definition file in a text editor start a separate text editor file, and paste the following template text block into it \<pulse config> \<config download url> '\<insert vaconfigurl value here>' \</config download url> \<appliance id> \<insert vaapplianceid value here> \<secondary dns> \<insert vasecondarydns here> \</secondary dns> \<primary dns> \<insert vaprimarydns here> \</primary dns> \<dns domain> \<insert vadnssearchdomain here> \</dns domain> \</appliance id> \<cert common name> \<insert vacommonname value here> \</cert common name> \<accept license agreement> y \</accept license agreement> \<controller enrolled hostname> \<insert vacontrollerenrolledhostname value here> \</controller enrolled hostname> \<dns search domain> \<insert vadnssearchdomain value here> \</dns search domain> \<controller hostname> \<insert vacontrollerhostname value here> \</controller hostname> \</pulse config> for each parameter block in the template text block file locate the required metadata property for the line for example, in the following block you require the vaapplianceid value from the gateway definitions file \<appliance id> \<insert vaapplianceid value here> \</appliance id> locate the required value in the gateway definitions file for example, the vaapplianceid value is 99ce3aa3c9494cbabb51c085c9c3f6ad copy and paste this value from the gateway definitions file into the template text file for example, the \<appliance id> block will now read as follows \<appliance id> 99ce3aa3c9494cbabb51c085c9c3f6ad \</appliance id> you do not need to change the \<accept license agreement> block, and can retain its y setting after you have added all required text to the template text file, save that file for use in the next section you can now create a kvm gateway vm in openstack, see creating the kvm gateway virtual machine instance in openstack creating the kvm gateway virtual machine instance in openstack to create a kvm vm instance in openstack access the openstack management portal , either from a client or a web browser, and log in using your openstack credentials in the openstack console, the overview page appears in the left menu, click compute > images the images page appears this shows a list of images above the list of images, click create image the create image wizard appears in this wizard, you upload a kvm gateway image for use under image details enter an image name typically, this incorporates a version number for example, zta gwy 100 enter an image description for example zta kvm image under image source , click browse and select the unpacked kvm disc image file then, click format and select qcow2 qemu emulator under image requirements , set minimum disk (gb) to 40 and minimum ram (kb) to 2048 set visibility setting as required public will enable the image to be used in other projects private will not set image sharing as required use the default settings for all other properties click next the metadata page of the wizard appears no action is required on this page, all properties can use their default settings click create image the wizard closes, and the new kvm gateway image is added to the images page wait until the image has been uploaded and processed and shows as active the upload image process typically takes 15 20 minutes after the image has uploaded and is active , click its launch button the first page of the launch instance wizard appears in this wizard, you create a kvm gateway instance under details enter an instance name this will be the displayed name of the gateway in nzta enter a description for the kvm gateway for example zta kvm gateway use the default settings for all other properties click next the source page of the wizard appears this page lists the selected disk image and selected/default settings for the instance no action is required on this page, all properties can use their displayed settings click next the flavor page of the wizard appears this page lists the available types of gateway you can create locate the isa4000 v entry and click its "up arrow" button to select it click next the networks page of the wizard appears this page lists the available networks (and associated subnetworks) for the gateway it enables you to select the required subnetworks for your gateway in the available list, locate the required subnetworks for example, you may require a subnetwork for internal ports and a subnetwork for external ports, but not a subnetwork for management interfaces if the required subnetworks do not yet exist, you must define them please refer to the openstack documentation for details of this process click the "up arrow" button for each subnetwork to select it for each selected subnetwork, a fixed ip address is added automatically to the gateway these appear later in this process, so that they can be assigned to floating ip addresses click next the network ports page of the wizard appears no action is required on this page, all properties can use their displayed settings click next the security groups page of the wizard appears no action is required on this page, all properties can use their displayed settings click next the security groups page of the wizard appears no action is required on this page, all properties can use their displayed settings if there is no default security group defined, you must define one please refer to the openstack documentation for details of this process click next the key pair page of the wizard appears no action is required on this page, all properties can use their displayed settings click next the configuration page of the wizard appears this page enables you to configure the gateway instance using metadata you prepared earlier, see adding a kvm gateway in nsa open your template text file and copy the entire text block that starts with \<pulse config> and ends with \</pulse config> paste the text block into the customization script block you cannot directly paste metadata for your gateway from nzta you must prepare a suitable text block from the metadata, see adding a kvm gateway in nsa enable the configuration drive check box click launch instance the wizard closes, and the new kvm gateway instance is added access the instances page the new kvm gateway instance is listed on this page wait until the power state of the gateway instance is running this process may take several minutes after the instance state changes to running , make a note of the subnetworks and their automatically assigned fixed ip addresses in the ip address column for the instance for example in this example, floating ip addresses are listed after the fixed ip addresses, so all are unassociated the fixed ip address on the int port 2 subnetwork is 4 4 10 83 the fixed ip address on the ext port 2 subnetwork is 5 5 10 64 access the network > floating ips page the floating ips page shows the floating ip addresses associated with your account both associated and unassociated floating ip addresses are listed associated floating ips have a mapped fixed ip address listed identify an unassociated floating ip address that you want to associate with a fixed ip address click the associate button for the fixed ip address the manage floating ip associations dialog appears select a fixed port to be associated for the selected floating ip address click associate to conform the association repeat the association process until each of the fixed ip addresses for your gateway instance is associated with a floating ip address wait until the status of these floating ip addresses all show as active return to the compute > instances page this page now shows a fixed ip address associated with floating ip address for each port for example click the console tab a console monitor view shows the ongoing boot up process for the instance wait until the instance shows a screen similar to the following return to the gateways list page on the controller locate the new gateway record in the list and confirm that its status has updated to connected for example after you have registered a gateway, you can configure it (or the gateway group to which it belongs) as the default gateway if required see the ics tenant admin guide for details workflow creating a gateway in google cloud platform this workflow leads you through the processes for setting up a gateway on the google cloud platform (gcp) these processes must be performed in sequence preparing to create a gcp gateway, see preparing to create a gcp gateway creating the gateway record in the controller, see adding a gcp gateway in nsa downloading metadata for google cloud platform, see downloading metadata for google cloud platform uploading the gcp image onto the google cloud platform, see uploading the gcp virtual machine image onto the google cloud platform creating a vm instance of the gcp image either creating a vm instance of the uploaded gcp image manually, see creating a vm instance of the uploaded gcp image manually creating a vm instance of the uploaded gcp image using a script/template, see creating a vm instance of the uploaded gcp image using a script/template completing the configuration of the controller, see completing the configuration of the controller after these steps have been completed successfully, the controller and gateway establish communication with each other preparing to create a gcp gateway before you start, make sure you have the following information and files an identifying name for the gateway the public ip address for the gateway this is the ip address at which clients can externally reach the gateway instance, such as an lb/nat or datacenter network forward rules if you want google cloud platform to allocated a public ip address automatically, you can use a dummy ip address (for example, 1 1 1 1 ) when you create the gateway on nzta you must then update the with the controller allocated public ip address afterwards the gateway geographic location (optional) the name of the gateway group to which you want to add this new gateway record to learn more about gateway groups, see the tenant admin guide a gateway group may have a defined public ip address, which you can specify during the creation of the gateway additionally, to manually specify gcp gateway network interface settings the primary (and optional secondary) dns server ip address, and search domain the required internal/private subnetworks must already be defined on google cloud platform, including firewall settings all required firewall settings for this interface are shown below refer to the google cloud platform documentation for details the required external/public subnetworks must already be defined on google cloud platform, including firewall settings all required firewall settings for this interface are shown below refer to the google cloud platform documentation for details (optional) any required management subnetwork must already be defined on google cloud platform, including firewall settings all required firewall settings for this interface are shown below refer to the google cloud platform documentation for details credentials for the google cloud platform console these credentials must include sufficient permissions to create a virtual machine from a template image after you have all required information, you can set up a nzta gcp gateway, see adding a gcp gateway in nsa adding a gcp gateway in nsa to set up a nzta gcp gateway, perform the following steps log into the tenant admin portal using the credentials provided in your welcome email two outcomes are possible on nzta unconfigured systems, the secure access setup (onboarding) wizard appears in this case, click add gateway on nzta configured systems, the overview of network page appears in this case from the nzta menu, click the secure access icon, then select gateways > gateway list the gateways list page appears, showing the full list of gateway groups and standalone gateways currently configured on the controller to add a new gateway, select create from the top right in the drop down menu, click create zta gateway in both cases, the gateway details dialog appears to learn more about the settings on this page, see the ics tenant admin guide enter a name for the gateway enter one or more public address or cname (public ip address or cname) for the gateway select add to add each entry to the list if you want google cloud platform to allocate a public ip address automatically, you can use a dummy ip address (for example, 1 1 1 1) at this point you must then update the controller with the allocated public ip address after the gcp vm instance is created select a geographic location for the gateway for gateway platform , select "google cloud platform" (optional) select a gateway group to which the new gateway is to be added a gateway group may have a defined public ip address, which you can specify as the public address , see above (optional) select the use management port check box to use management network ports for nzta traffic rather than internal ports when the management port is enabled, the controller will still use the internal port for dns resolution if the internal dns cannot resolve the controller domain, the internal interface will require internet access (optional) select the use proxy server for communication check box to enable nzta to controller communication via proxy server proxy is supported on both internal and management interfaces of the gateway once enabled, enter host name and port optionally, if your proxy server requires further authentication, enter a username and password to log in to the proxy server admin can configure proxy for existing gateway after upgrading it to 22 4r3 version or later enter the primary dns ip address for the gateway (optional) enter the secondary dns ip address for the gateway enter the dns search domain for the gateway make sure the specified dns service can resolve the ip address of your controller issues here can cause registration of the gateway with the controller to fail to add a gateway definition based on the settings you specified in this dialog, select create configuration by completing the gateway details workflow, an unregistered gateway record is created on the controller you can view this gateway record on the gateways > gateways list page you can now download your metadata, see downloading metadata for google cloud platform downloading metadata for google cloud platform the preparation of metadata for use on google cloud platform currently requires some manual steps log into nzta and access the gateways > gateways list page select your gcp gateway and click the download icon to obtain a copy of the gateway definition file specify a save location for your gateway definition file the gateway definition file is valid for 24 hours if this period expires, you must replace the gateway to generate a new gateway definition file # (optional) if you have not yet downloaded the latest version of your gateway vm image and optional yaml templates, click the download icon and select download gateway vm image save the archive file and unpack to a local workstation make sure the resulting file set is accessible from the google cloud platform management portal you can now create a gcp gateway vm in google cloud platform, see uploading the gcp virtual machine image onto the google cloud platform uploading the gcp virtual machine image onto the google cloud platform to upload a gcp gateway virtual machine image into google cloud platform access the google cloud platform management portal , either from a client or a web browser, and log in using your google cloud platform credentials in the google cloud platform console, select your required project from the pull down list on the title bar for example click the navigation menu, and then select cloud storage > browser a list of gcp storage buckets appears select the bucket into which you wish to place the gcp image a page listing the current contents of the bucket appears (optional) navigate to the required folder within the bucket click upload files for example an upload dialog appears select the zta gateway gcp virtual machine image tar file from your local workstation (see preparing to create a gcp gateway docid\ afistx9svtxuira4shuc9 ), and click open if you want to use the provided yaml templates to automate the creation of your vm instance (see creating a vm instance of the uploaded gcp image using a script/template ), select these in addition to the image archive the image archive and any selected template files are added to the bucket wait until the upload completes this may take several minutes start a command line session from the title bar for example a command line session starts navigate to the project folder create an image from the zta gateway image archive using the following command gcloud compute images create \<instance name> source uri=gs\ //\<bucket name>/\<optional path>/\<image name> tar guest os features multi ip subnet you can now create a vm instance of the uploaded gcp image to do this, either perform the task manually, see creating a vm instance of the uploaded gcp image manually perform the task with a script/template, see creating a vm instance of the uploaded gcp image using a script/template creating a vm instance of the uploaded gcp image manually this section describes how to manually create a virtual machine instance of the zta gateway image inside google cloud platform you can also perform this process automatically using a script/template, see creating a vm instance of the uploaded gcp image using a script/template click the navigation menu, and then select compute engine > images the images page appears for example locate the new image in the list of images at the end of the image entry, click the action menu and select create instance the create instance page appears for example on the create instance page enter a name for the new instance select a region and zone under machine configuration for series , select n1 for machine type , select a minimum of n1 standard 2 for boot disk , confirm that the correct image is already selected for firewall , select the required http/https options expand the management, security, disks, networking, sole tenancy options select the management tab under metadata for key , enter pulse config for value , paste the text of the metadata file you downloaded earlier select the networking tab under network interfaces , click the edit icon to change the default network interface selection the network interface options appear under network interface , specify a private (internal) network interface for network , select the required private vpc for subnetwork , select the required subnetwork click done to confirm the settings for the private network interface under network interfaces , click add network interface the network interface options appear under network interface , specify a public (external) network interface for network , select the required public vpc for subnetwork , select the required subnetwork click done to confirm the settings for the public network interface (optional) click add network interface and specify a management network interface click create to confirm the settings and instantiate a vm instance of the image the vm instances page appears this page shows the new vm instance of the image for example on the vm instances page, wait until the creation of the vm instance completes this may take several minutes after the vm instance is created, click on it in the list of vm instances the vm instance details page appears for the instance confirm the details for the vm instance, including the number of network interfaces make a note of the public ip address of the ext interface (typically, this is nic1 this is required inside nzta under network interfaces , confirm that the firewall settings from your vpcs are present for your specified network interfaces click nic0 a summary page for this network interface appears under firewall and route details , click the firewall rules tab and confirm that the following firewall rules are defined click nic1 a summary page for this network interface appears under firewall and route details , click the firewall rules tab and confirm that the following firewall rules are defined (optional) click nic2 a summary page for this optional network interface appears under firewall and route details , click the firewall rules tab and confirm that the following firewall rules are defined the vm instance details page, click connect to serial console a console monitor view (in a separate browser tab) shows the ongoing boot up process for the instance wait until the instance boot up is complete, and shows a screen similar to the following you can then complete this process by updating the gateway details on the controller, see completing the configuration of the controller creating a vm instance of the uploaded gcp image using a script/template this section describes how to automatically create a virtual machine instance of the zta gateway image inside google cloud platform using a script/template you can also perform this process manually, see creating a vm instance of the uploaded gcp image manually ivanti provides yaml based templates to create an instance of the zta gateway image in the following configurations two network interfaces in an existing vpc download https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 2 nics existing vpc zip https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 2 nics existing vpc zip three network interfaces in an existing vpc download https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 3 nics existing vpc zip https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 3 nics existing vpc zip two network interfaces in a new vpc download https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 2 nics new vpc zip https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 2 nics new vpc zip three network interfaces in a new vpc download https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 3 nics new vpc zip https //pulsezta blob core windows net/gateway/templates/gcp/25 4 579/ivanti zta 3 nics new vpc zip you can obtain these templates through the links given here, or as part of the archive file set provided through the download link on the gateways overview page in the tenant admin portal after you have defined a gateway record to use a template download the required template archive file to your local workstation unpack the downloaded archive file to a location that is accessible from google cloud platform each archive contains three files for example, for the two interface (existing vpc) version of the archive pulsesecure zta 2nics existing vpc jinja pulsesecure zta 2nics existing vpc jinja scheme pulsesecure zta 2nics existing vpc yaml edit the yaml file properties section to reflect your project and instance requirements, including the user data property an example of an existing vpc yaml file is provided here imports \ path pulsesecure zta 2 nics existing vpc jinja resources \ name my vm properties project zta gw 263035 email admin\@example com region asia south1 zone asia south1 b image ztagcp123 machine type n1 standard 2 int network ext network int subnetwork ext subnetwork user data type pulsesecure zta 2 nics existing vpc jinja an example of a new vpc yaml file is provided here imports \ path pulsesecure zta 2 nics new vpc jinja resources \ name my vm properties deploy with lb yes project zta gw 263035 email admin\@example com region asia south1 zone asia south1 b image ztagcp123 machine type n1 standard 2 user data \<pulse config>\<primary dns>8 8 8 8<\primary dns> int cidr 192 0 2 0/24 ext cidr 192 0 2 0/24 type pulsesecure zta 2 nics new vpc jinja where you are specifying a new vpc for your virtual machine instance, make sure you use properties (for example, networking settings) that do not conflict with an existing vpc save the yaml file on the google cloud platform, start a command line session from the title bar for example a command line session starts select the required project gcloud config set project \<project name> within the project folder, create a deploymentmanager folder copy the three script files to this folder create a vm instance from the zta gateway image archive file using the following command for example gcloud deployment manager deployments create \<vm name> config \<yaml file> gcloud deployment manager deployments create vm gcp 123 config pulsesecure zta 3 nics existing vpc yaml wait until the command completes on the vm instances page, click on the new vm in the list of vm instances the vm instance details page appears for the instance confirm the details for the vm instance, including the number of network interfaces make a note of the public ip address of the ext interface (typically, this is nic1 this is required inside nzta you can now complete this process by updating the gateway details on the controller, see completing the configuration of the controller completing the configuration of the controller if you specified a dummy public ip address (for example, 1 1 1 1 ) when you created the gateway on the controller, you now need to update the controller with the allocated public ip address for the gateway vm instance on google cloud platform you do not need to perform the following procedure if you specified the correct public ip address when you created the gateway on the controller, see adding a gcp gateway in nsa return to the gateways list page in the nzta tenant admin portal locate the new gateway record in the list and confirm that its status has updated to connected select the gateway, and then select secure access > gateways > configuration under gateway network settings , delete the current public ip setting and replace it with the public ip address if the nic1 (external) interface for the vm instance after you have registered a gateway, you can configure it (or the gateway group to which it belongs) as the default gateway if required see the ics tenant admin guide for details workflow creating a gateway in oracle cloud platform for 22 7r1 3 release, 22 7r2 2 zta gateway version is not supported with oracle, aws, and kvm platforms this workflow leads you through the processes for setting up a gateway on the oracle cloud platform (oci) these processes must be performed in sequence preparing to create an oracle gateway, see preparing to create an oracle gateway docid\ afistx9svtxuira4shuc9 creating the gateway record in the controller, see adding an oracle gateway docid\ afistx9svtxuira4shuc9 downloading metadata for oracle cloud platform, see downloading metadata for oracle cloud platform docid\ afistx9svtxuira4shuc9 uploading the oracle image onto the oracle cloud platform, see uploading the oracle virtual machine image onto the oracle cloud platform docid\ afistx9svtxuira4shuc9 creating a vm instance of the oci image creating a vm instance of the uploaded oracle image using a script/template, see creating a vm instance of the uploaded oci image using terraform script docid\ afistx9svtxuira4shuc9 refer terraform configurations for details on the configuration, see terraform configurations docid\ afistx9svtxuira4shuc9 creating a vm instance of the uploaded oci image using any other methods, see creating a vm instance of the uploaded oci image using any other methods docid\ afistx9svtxuira4shuc9 preparing to create an oracle gateway before you start, make sure you have the following information and files an identifying name for the gateway the public ip address for the gateway this is the ip address at which clients can externally reach the gateway instance, such as an lb/nat or datacenter network forward rules if you want oracle cloud platform to allocate a public ip address automatically, you can use a dummy ip address (for example, 1 1 1 1) when you create the gateway on nzta the gateway geographic location (optional) the name of the gateway group to which you want to add this new gateway record to learn more about gateway groups, see configuring gateways docid\ afistx9svtxuira4shuc9 gateway group may have a defined public ip address, which you can specify during the creation of the gateway credentials for the oracle cloud platform console these credentials must include sufficient permissions to create a virtual machine using terraform scripts the primary (and optional secondary) dns server ip address, and search domain adding an oracle gateway to register a gateway on your controller, use the gateway details dialog to begin, log into the controller tenant admin portal using the credentials provided in your welcome email two outcomes are possible on unconfigured nzta systems, the secure access setup onboarding wizard appears (see working with the onboarding wizard docid\ afistx9svtxuira4shuc9 ) in this case, click add gateway on configured nzta systems, the network overview page appears in this case from the nzta menu, click the secure access icon, then select manage gateways the gateways list page appears, showing the full list of gateway groups and standalone gateways currently configured on the controller to add a new gateway, select create from the top right from the drop down menu, click create zta gateway the gateway details dialog appears enter the following details enter a name for the gateway enter one or more public address or cname (public ip address or cname) for the gateway select add to add each entry to the list to learn more about this setting, see configuring gateways docid\ afistx9svtxuira4shuc9 if you want oracle cloud platform to allocate a public ip address automatically, you can use a dummy ip address (for example, 1 1 1 1) at this point you must then update the controller with the allocated public ip address after the oracle vm instance is created (if it is not updated automatically) select the geographic location details for the gateway for gateway platform, select oracle cloud platform enter the primary dns ip address for the gateway (optional) enter the secondary dns ip address for the gateway enter the dns search domain for the gateway (optional) select the use management port check box to use management network ports for nzta traffic rather than internal ports when the management port is enabled, gateway will use management interface to communicate with controller and ntp server the gateway will still use the internal port for dns resolution and ntp server name resolution if the internal dns cannot resolve the controller domain, the internal interface will require internet access (optional) select the use proxy server for communication check box to enable nzta to controller communication via proxy server proxy is supported on both internal and management interfaces of the gateway once enabled, enter host name and port optionally, if your proxy server requires further authentication, enter a username and password to log in to the proxy server (optional) select a gateway group to which the new gateway is to be added to learn more about gateway groups, see configuring gateways docid\ afistx9svtxuira4shuc9 a gateway group may have a defined public ip address, which you can specify as the public address to add a gateway definition based on the settings you specified in this dialog, select create configuration you can now download your metadata, see downloading metadata for oracle cloud platform docid\ afistx9svtxuira4shuc9 in case of registration failure due to gateway configuration mistakes in firewall rules, dns, etc , you can re register the gateway it does not require re deploying of gateway downloading metadata for oracle cloud platform the preparation of metadata for use on oracle cloud platform currently requires some manual steps log into the controller as a tenant admin, see logging in as a tenant administrator from the nzta menu, click the secure access icon, then select manage gateways > gateways list the gateways list page appears, showing the full list of gateway groups and standalone gateways currently configured on the controller locate and select your oracle cloud gateway the gateways overview page appears click the download icon, then choose download gateway init config to obtain a copy of the gateway definition file specify a save location for your gateway definition file the gateway definition file is valid for 24 hours if this period expires, you must replace the gateway to generate a new gateway definition file (optional) if you have not yet downloaded the latest version of your gateway vm image and optional yaml templates, click the download icon and select download gateway vm image save the archive file and unpack to a local workstation make sure the resulting file set is accessible from the oracle cloud platform management portal you can now create an oracle cloud gateway vm in oracle cloud platform, see uploading the oracle virtual machine image onto the oracle cloud platform docid\ afistx9svtxuira4shuc9 uploading the oracle virtual machine image onto the oracle cloud platform to upload a oracle gateway virtual machine image into oracle cloud platform access the oracle cloud platform management portal, either from a client or a web browser, and log in using your oracle cloud platform credentials click the navigation menu, and then select storage > buckets select the right compartment and then the list of oci storage buckets appears as below select the bucket into which you wish to place the oci image a page listing the current list of the files from the bucket appears click upload an upload dialog appears select the zta gateway oci virtual machine image tar file from your local workstation and click open wait until the upload completes this may take several minutes once upload completes create an image from the bucket using the following method click the navigation menu, and then select compute > custom images select the right compartment and then the list of current images appears click on import image an import dialog will appear and then choose the tar file that was uploaded in the bucket refer to the below screenshots ensure the os is selected as centos ensure launch mode is chosen as paravirtualized mode ensure image type is chosen as qcow2 wait until the import completes this may take several minutes you can now create a vm instance of the uploaded oci image to do this, either perform the task manually, see configuring gateways docid\ afistx9svtxuira4shuc9 perform the task with a script, see creating a vm instance of the uploaded oci image using terraform script docid\ afistx9svtxuira4shuc9 creating a vm instance of the uploaded oci image using terraform script pre requisites ensure oci configurations required for cli access is enabled this is one time process please see here for details download the required template archive file to your local workstation upload all the scripts to oracle cloud shell as below open the cloud shell using the option as shown below upload the terraform scripts using the upload option from the cloud shell settings as shown below once it is uploaded, the scripts will be present in the user’s home directory edit the config auto vars file as per the intended deployment refer terraform configurations docid\ afistx9svtxuira4shuc9 for details on the configuration run terraform init run terraform validate this will let the admin know if there are any issues with the configurations run terraform apply this will trigger the deployment process if any resource deployment fails, retry running the command terraform apply again terraform configurations serial no configuration description sample value 1 enable management this defines, if nzta needs an additional nic for management interface enable management = true 2 internal existing vcn this defines, if existing vcn to be used for internal(primary) interface if true, then we need to provide the vcn id for the configuration internal vcn id internal existing vcn = false 3 external existing vcn this defines, if existing vcn to be used for external interface if true, then we need to provide the vcn id for the configuration external vcn id external existing vcn = false 4 management existing vcn this defines, if existing vcn to be used for management interface if true, then we need to provide the vcn id for the configuration management vcn id management existing vcn = false 5 use internal vcn for all this defines, if internal vcn to be used for all interfaces(external/management) use internal vcn for all = false 6 internal existing subnet this defines, if existing subnet from the existing vcn to be used for internal(primary) interface if true, then we need to provide the configuration internal vcn id and internal subnet id internal existing subnet = false 7 external existing subnet this defines, if existing subnet from the existing vcn to be used for external interface if true, then we need to provide the configuration external vcn id and external subnet id external existing subnet = false 8 management existing subnet this defines, if existing subnet from the existing vcn to be used for management interface if true, then we need to provide the configuration management vcn id and management subnet id management existing subnet = false 9 create management nat this defines, if nat needs to be created for management interface this is required for management interface to access controller deployed in the internet create management nat = true 10 create internal nat this defines, if nat needs to be created for internal(primary) interface this is required for internal interface to access controller deployed in the internet create internal nat = true 11 create external ig this defines, if internet gateway needs to be created for external interface this is required for isac client to reach the external interface for resource access create external ig = true 12 use static external ip this defines, if static private ip to be used for external interface use static external ip = false 13 use static internal ip this defines, if static private ip to be used for internal interface use static internal ip = false 14 use static management ip this defines, if static private ip to be used for management interface use static management ip = false 15 use load balancer this defines, if load balancer needs to be configured for external interface use load balancer = false 16 use existing lb for ext nic this defines, if existing load balancer to be used for external interface if true, then we need to provide the configuration external lb id use existing lb for ext nic = false 17 use existing bs for ext nic this defines, if existing backend set to be used for external interface if true, then we need to provide the configuration bs display name use existing bs for ext nic = false 18 use existing ls for ext nic this defines, if existing listeners to be used for external interface if true, then we need to provide the configuration listener display name use existing ls for ext nic = false 19 compartment id the ocid of the compartment where the nzta gateway will be deployed compartment id = "ocid1 tenancy oc1 aaaaaaaarod5yc3653ujwgvjbqui3s6r6ntfbs3d4uwxlkitku5flcbkrety" 20 vm display name display name for the nzta gateway vm vm display name = "skrn new 2" 21 image id ocid of the image to use for the nzta gateway deployment image id = "ocid1 image oc1 ap hyderabad 1 aaaaaaaapw7vnd4fqbp3heuk5kikfhlmhpcxjhcrl7tz7a3ln52gg7jr3htq" 22 shape vm shape for the nzta gateway (e g , vm standard e4 flex and etc ) if the shape is of type fles, then we need to provide the configuration total flex ocpus and total flex ram as mandatory shape = "vm standard e4 flex" 23 total flex ocpus number of required ocpu's for the flex vm total flex ocpus = 3 24 total flex ram ram size for the flex vm total flex ram = 16 25 availability domain availability domain where the shape belong to availability domain = "bsuy\ ap hyderabad 1 ad 1" 26 internal vcn cidr block internal cidr block for the internal virtual cloud network to be created internal vcn cidr block = "10 0 0 0/16" 27 internal vcn display name display name for the internal virtual cloud network to be created internal vcn display name = "zta internal vnc 2" 28 internal vcn id ocid of the existing vcn to use for the nzta internal interface (primay vnic) internal vcn id = "ocid1 vcn oc1 ap hyderabad 1 amaaaaaatgkbhxyaia3zy75gt3cqxqotgdagfsw7vdy2sylscjvavm2526ha" 29 internal subnet id ocid of the subnet to use for the nzta internal interface (primay vnic) internal subnet id = "ocid1 subnet oc1 ap hyderabad 1 aaaaaaaafscfkn7nzwsnv5xgjscybresi55fyxreqrqeu67umiz2sw7giawa" 30 internal subnet cidr block cidr block for the internal subnet to be created internal subnet cidr block = "10 0 0 0/18" 31 internal subnet display name display name for the internal subnet to be created internal subnet display name = "internal subnet 2" 32 internal rt name display name of the routing table for the internal subnet to be created internal rt name = "internal rt name" 33 internal nat name display name of the nat for the internal subnet to be created internal nat name = "internal nat name" 34 internal nic display name display name for the internal nic (primary vnic) to be created internal nic display name = "internal" 35 internal ip address static ip address of the internal nic (optional) internal ip address = "10 1 1 2" 36 internal is public ip enabled this defines, if we need to ssign public ip to internal nic internal is public ip enabled = false 37 internal nsg name display name of the network security group to be associated with internal nic which will be created internal nsg name = "internal nsg name" 38 internal nsg rules defines the network security group for the internal interface protocol protocol to be allowed values 6 (tcp) ,17 (udp) destination destination cidr block to be allowed source source cidr block to be allowed min dstport min destination port to be allowed max dstport max destination port to be allowed min srcport min destination port to be allowed max srcport max destination port to be allowed description description about the nsg rules direction ingress or egress protocol = "6"//tcp destination ="0 0 0 0 /0" source = "0 0 0 0 /0" min dstport = 6667 max dstport = 6667 min srcport = 0 max srcport = 0 description = "internal ingess" direction = "ingress" 39 external vcn cidr block external cidr block for the external virtual cloud network to be created external vcn cidr block = "10 0 0 0/16" 40 external vcn display name display name for the external virtual cloud network to be created external vcn display name = "zta external vnc 2" 41 external vcn id ocid of the existing vcn to use for the nzta external interface (primay vnic) external vcn id = "ocid1 vcn oc1 ap hyderabad 1 amaaaaaatgkbhxyaia3zy75gt3cqxqotgdagfsw7vdy2sylscjvavm2526ha" 42 external subnet id ocid of the subnet to use for the nzta external interface (primay vnic) external subnet id = "ocid1 subnet oc1 ap hyderabad 1 aaaaaaaafscfkn7nzwsnv5xgjscybresi55fyxreqrqeu67umiz2sw7giawa" 43 external subnet cidr block cidr block for the external subnet to be created external subnet cidr block = "10 0 0 0/18" 44 external subnet display name display name for the external subnet to be created external subnet display name = "external subnet 2" 45 external rt name display name of the routing table for the external subnet to be created external rt name = "external rt name" 46 external ig name display name of the internal gateway for the external subnet to be created external ig name = "external ig name" 47 external nic display name display name for the external nic (primary vnic) to be created external nic display name = "external" 48 external ip address static ip address of the external nic (optional) external ip address = "10 1 1 2" 49 external is public ip enabled this defines, if we need to ssign public ip to external nic external is public ip enabled = true 50 external nsg name display name of the network security group to be associated with external nic which will be created external nsg name = "external nsg name" 51 external nsg rules defines the network security group for the external interface protocol protocol to be allowed values 6 (tcp) ,17 (udp) destination destination cidr block to be allowed source source cidr block to be allowed min dstport min destination port to be allowed max dstport max destination port to be allowed min srcport min destination port to be allowed max srcport max destination port to be allowed description description about the nsg rules direction ingress or egress protocol = "6"//tcp destination ="0 0 0 0 /0" source = "0 0 0 0 /0" min dstport = 6667 max dstport = 6667 min srcport = 0 max srcport = 0 description = "external ingess" direction = "ingress" 52 management vcn cidr block management cidr block for the management virtual cloud network to be created management vcn cidr block = "10 0 0 0/16" 53 management vcn display name display name for the management virtual cloud network to be created management vcn display name = "zta management vnc 2" 54 management vcn id ocid of the existing vcn to use for the nzta management interface (primay vnic) management vcn id = "ocid1 vcn oc1 ap hyderabad 1 amaaaaaatgkbhxyaia3zy75gt3cqxqotgdagfsw7vdy2sylscjvavm2526ha" 55 management subnet id ocid of the subnet to use for the nzta management interface (primay vnic) management subnet id = "ocid1 subnet oc1 ap hyderabad 1 aaaaaaaafscfkn7nzwsnv5xgjscybresi55fyxreqrqeu67umiz2sw7giawa" 56 management subnet cidr block cidr block for the management subnet to be created management subnet cidr block = "10 0 0 0/18" 57 management subnet display name display name for the management subnet to be created management subnet display name = "management subnet 2" 58 management rt name display name of the routing table for the management subnet to be created management rt name = "management rt name" 59 management nat name display name of the nat for the management subnet to be created management nat name = "management nat name" 60 management nic display name display name for the management nic (primary vnic) to be created management nic display name = "management" 61 management ip address static ip address of the management nic (optional) management ip address = "10 1 1 2" 62 management is public ip enabled this defines, if we need to ssign public ip to management nic management is public ip enabled = false 63 management nsg name display name of the network security group to be associated with management nic which will be created management nsg name = "management nsg name" 64 management nsg rules defines the network security group for the management interface protocol protocol to be allowed values 6 (tcp) ,17 (udp) destination destination cidr block to be allowed source source cidr block to be allowed min dstport min destination port to be allowed max dstport max destination port to be allowed min srcport min destination port to be allowed max srcport max destination port to be allowed description description about the nsg rules direction ingress or egress protocol = "6"//tcp destination ="0 0 0 0 /0" source = "0 0 0 0 /0" min dstport = 6667 max dstport = 6667 min srcport = 0 max srcport = 0 description = "management ingess" direction = "ingress" 65 init config init config that nzta will pickup while deployment this value needs to be taken from the init file downloaded from the nzta controller interface as explained in admin guide section “downloading metadata for oracle cloud platform” init config = "phb1bhnllwnvbmzpzz48chjpbwfyes1kbnm+oc44ljguodwvchjpbwfyes1kbnm+phnly29uzgfyes1kbnm+oc44ljqundwvc2vjb25kyxj5lwrucz48zg5zlwrvbwfpbj5wc2vjdxjllm5lddwvzg5zlwrvbwfpbj48y2vydc1jb21tb24tbmftzt5za3julw9jas5nlmuyztiuzs5qdw5pcgvylnb6dc5kzxyucgvyznnlyy5jb208l2nlcnqty29tbw9ulw5hbwu+pgfjy2vwdc1sawnlbnnllwfncmvlbwvudd55pc9hy2nlchqtbgljzw5zzs1hz3jlzw1lbnq+pgnvbmzpzy1kb3dubg9hzc11cmw+j2h0dhbzoi8vztjlmi5qdw5pcgvylnb6dc5kzxyucgvyznnlyy5jb20vyxbpl2dhdgv3yxlzlzbjytnlnmuwlwzmmtitnduxny1hytyzlwm5njy5mwuzndmzyi9vcmnozxn0cmf0aw9ul2luaxrpywwty29uzmlnp3q9z0fbqufbqmstqufmyxiwyjgtnxowmxo4avzss1vbutvivuryahjqcnfxcwzqc1jpy0pjs0pjquztqnhwzgflbtrnndhsvw53bty3reftwulwqwp2c2jewguzcna1x2vmu3joc1lswtm1su96wme3dlzsadrxalnsq3zxa3jfvkvvek5motdqedl1t1a1vktxqmdan3nhlv93sudkvnnbcuc3owl4ttu2wvjxblyzc21ntm5mafhfnuxdtkftymv1t3bkwk5qnxpywddoa2y5stzlwuctuwi0ahrenznoznzyyjhznmryzgo0wuliaxitdxa0ynj5d1i0dudivthuz20zr3zwanfpakrfbgjsykfst2vjdxpomujgawpdexhvc09nzdkwbmvrdkppuhdmc3pjluj1tw5frktnvg1px1rztufmy1e4ytm5mmrfulq1ovhwm3p4qkrvaklqq1l1rlntbexcd2nkckrjzc1otvmwsmpxyue1nhhlmdnsmddmthbqz2zrmmfoewhbshr4quiyvfleudutcv9iofdra2pczxnhvmh5bkvrx0rkv0jongotmuf4tt0npc9jb25mawctzg93bmxvywqtdxjspjxhchbsawfuy2utawq+mgnhm2u2ztbmzjeynduxn2fhnjnjoty2otflmzqzm2i8l2fwcgxpyw5jzs1pzd48y29udhjvbgxlci1ob3n0bmftzt5lmmuylmp1bmlwzxiuchp0lmrldi5wzxjmc2vjlmnvbtwvy29udhjvbgxlci1ob3n0bmftzt48y29udhjvbgxlci1lbnjvbgxlzc1ob3n0bmftzt5lmmuylmuuanvuaxblci5wenquzgv2lnblcmzzzwmuy29tpc9jb250cm9sbgvylwvucm9sbgvklwhvc3ruyw1lpjxkbnmtc2vhcmnolwrvbwfpbj5wc2vjdxjllm5lddwvzg5zlxnlyxjjac1kb21haw4+pgnvbm5ly3qtdmlhlw1nbxqtaw50zxjmywnlpm48l2nvbm5ly3qtdmlhlw1nbxqtaw50zxjmywnlpjwvchvsc2uty29uzmlnpg==" 66 lb display name display name of the load balancer that should be created lb display name = "external lb name" 67 listener display name display name of the listener that should be associated with the loadbalancer listener display name = \["external ls name 443" , "external ls name 80"] 68 bs display name display name of the backend sets that should be associated with the loadbalancer bs display name = \["external bs name 443","external bs name 80"] 69 external lb id oci id of the external loadbalancer external lb id = "ocid1 networkloadbalancer oc1 ap hyderabad 1 amaaaaaatgkbhxyanzrjec4irpjuumytyuk5qugcuatjc2oiejpjcvo6hlaa" 70 ports load balancer ports for the listener and backendsets the orfer of port number should be matching the order mentioned in listener and backend set configurations listener display name andbs display name ports = \[443,80] 71 bs policy backend set policy that should be used for traffic distribution in load balancer bs policy = "five tuple" 72 protocol tcp is only protocol supported for load balancer configuration protocol = "tcp" creating a vm instance of the uploaded oci image using any other methods deploy a vm with nzta gateway image uploaded to the oci, with following requisites configure 2 nic’s in the order internal, external, if the management port is not required for the nzta gateway deployment configure 3 nic’s in the order internal, external and management if management port is configured for the nzta gateway deployment ensure custom metadata “pulse config” is configured for the vm the value of pulse config metadata needs to be taken from the init file downloaded from the nzta controller interface as explained in admin guide section downloading metadata for oracle cloud platform docid\ afistx9svtxuira4shuc9 ensure internal nic can access the controller present in the azure cloud and application resources ensure external nic public ip is reachable by the isac clients over the port 443 ensure management nic can access the controller present in the azure cloud , if management port is enabled for controller communication ensure load balancer ip is reachable by the isac clients over port 443, if load balancer is used for gateway deployment recommended firewall rules internal ingress (tcp 6667), egress (tcp any, udp any) external ingress (tcp 443) management ingress (tcp 6667), egress (tcp any, udp any) next steps after you have defined your user authentication policies, move on to create your device policies see creating device policies and device rules