--- title: Working with Gateways slug: ps/help/en_us/nsa/22x/nsa-zta/ag/1004 docTags: createdAt: 2026-07-22T14:00:50.432Z --- - [Introduction](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Configuring Networks in your Gateway Datacenter](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Using Dynamic IP Addressing to Profile Client Traffic](docId\:odDr4Z3VrHMCgVhHAWv7j) - [White-listing Required IP Addresses for your Services](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Viewing and Monitoring Gateways in the Controller](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Viewing Gateway Logs](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Viewing Gateway Tasks](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Editing Gateway Configuration](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Troubleshooting Gateway Issues](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Adding Gateway Groups for High Availability](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Creating Gateway Selectors](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Workflow: Creating a Gateway in VMware vSphere](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Workflow: Creating a Gateway in Amazon Web Services](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Workflow: Creating a Gateway in Microsoft Azure](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Workflow: Creating a Gateway in Google Cloud Platform](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Workflow: Creating a Gateway in Oracle Cloud Platform](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Upgrading Gateways](docId\:odDr4Z3VrHMCgVhHAWv7j) - [Configuring ZTA Gateway Connection Control for Trusted Networks](docId\:odDr4Z3VrHMCgVhHAWv7j) ## Introduction After you have successfully logged into the *Ivanti Neurons for Zero Trust Access* (*nZTA*) *Controller* as a Tenant Admin user (see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z)), you can start the configuration of your *nZTA* platform by adding Gateways. *nZTA* supports two main Gateway types, depending on your subscription: - *nZTA Gateway* - *Ivanti Connect Secure* (*ICS*) Gateway This chapter covers functionality relating to a *nZTA Gateway* only. For details pertaining to a *ICS* Gateway, see instead the "*ICS* Tenant Admin Guide" in the *nZTA* documentation portal. :::hint{type="info"} To learn more about *nZTA Gateway*s and their relationship with the other dimensions of a *Secure Access Policy*, see [Deploying Gateways](docId\:l_5jA2G89IAVU6vx7XKKi). ::: A Gateway controls access to the applications at the location to which it is deployed. This location could be a physical datacenter, a private or public cloud-based service, or some hybrid combination. Each Gateway communicates with the *Controller* to ensure that access requests are authenticated. A Gateway must be contactable by both the *Controller* and the applications that reside there. See [Configuring Networks in your Gateway Datacenter](docId\:odDr4Z3VrHMCgVhHAWv7j). The process of defining a Gateway on the *Controller* 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 with the *Controller*. :::hint{type="info" indent="1"} Ensure the Gateway virtual machine instance does not exist prior to creating your Gateway definitions on the *Controller*. All *nZTA Gateway*s 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. ::: To register a new Gateway with the *Controller*, use the Tenant Admin portal. The *Controller* requires basic identification and networking details for the Gateway instance, and in return provides a downloadable Gateway definition file. :::hint{type="info" indent="1"} A Gateway definition file is valid for 24 hours. If this period expires, you must replace the Gateway to generate a new Gateway definition file. ::: When you deploy the Gateway virtual machine instance in your on-premise or cloud infrastructure, you apply the definition file as configuration data. At launch time, the Gateway attempts to contact and register itself with the *Controller*, establishing a link between the Gateway record in the *Controller* and the actual virtual machine instance. Any subsequent policy changes made on the *Controller* are automatically synchronized out to all Gateways. You can choose a single Gateway (or Gateway Group) to act as a *default Gateway*. A default Gateway handles all requests from applications that are not referenced by any secure access policy. See [Viewing and Monitoring Gateways in the Controller](docId\:odDr4Z3VrHMCgVhHAWv7j). :::hint{type="info" indent="1"} *Ivanti Secure Access Client* Linux variants do no currently support the use of a default gateway. ::: After you have registered your Gateways with the *Controller*, you can: - View performance and usage graphs - See activity logs - View task lists - Establish Gateway Groups for *High Availability* - Manage version upgrades - Replace Gateway instances registered with the *Controller* To learn more, see [Viewing and Monitoring Gateways in the Controller](docId\:odDr4Z3VrHMCgVhHAWv7j). ### High Availability *nZTA* allows you to deploy multiple Gateways in front of the same set of applications or resources to support high availability. This arrangement can be used to provide scaling, redundancy, and load distribution for your application delivery. To learn more, see [Using Gateway Groups for High Availability](docId\:l_5jA2G89IAVU6vx7XKKi). 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 adding Gateway Groups, see [Adding Gateway Groups for High Availability](docId\:odDr4Z3VrHMCgVhHAWv7j). ### Gateway Deployment Workflows *nZTA* supports Gateway virtual machine instances deployed in the following environments: - **VMware vSphere**: see [Workflow: Creating a Gateway in VMware vSphere](docId\:odDr4Z3VrHMCgVhHAWv7j). - **Amazon Web Services (AWS)**: see[ Workflow: Creating a Gateway in Amazon Web Services](docId\:odDr4Z3VrHMCgVhHAWv7j). - **Microsoft Azure**: see [Workflow: Creating a Gateway in Microsoft Azure](docId\:odDr4Z3VrHMCgVhHAWv7j). - **Google Cloud Platform**: see[Workflow: Creating a Gateway in Google Cloud Platform](docId\:odDr4Z3VrHMCgVhHAWv7j). - **Oracle Cloud Platform** ( Qualified with ZTA GW version: 22.7R1, 22.6R1): [Workflow: Creating a Gateway in Oracle Cloud Platform](docId\:odDr4Z3VrHMCgVhHAWv7j) You can choose any single Gateway (at v21.1 or later) or Gateway Group to act as a *default Gateway*. A default Gateway handles all requests from applications that are not referenced by any secure access policy. See [Configuring a Default Gateway for Application Discovery](docId\:odDr4Z3VrHMCgVhHAWv7j). :::hint{type="info" indent="1"} For 22.7R1.3 release, 22.7R2.2 ZTA Gateway version is not supported with Oracle and AWS platforms. ::: :::hint{type="info" indent="1"} Each process described in this chapter contains prerequisites that correspond to the latest supported Gateway versions for this release. To deploy older supported Gateway versions, substitute in the file paths and names with the version you want to use. To learn more about the supported Gateway images for this release, see the Release Notes or contact your support representative. ::: ## Configuring Networks in your Gateway Datacenter *nZTA Gateway*s deployed in your cloud or on-premise datacenter require the availability of a number of network interfaces and ports to operate correctly. You require the following primary interfaces defined in your Gateway virtual machine instance: - **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. :::hint{type="info" indent="1"} 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. ::: *nZTA Gateway* template images contain parameters and settings for all required interfaces. You provide suitable configuration during the Gateway deployment workflows described in this chapter. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/l9V-0B1zlPQlkeKmGg4yI_gatewaydetail.png" position="flex-start" size="80" width="1989" height="1141" initialPath="img/gateway_detail.png" githubPath="img/gateway_detail.png" darkWidth="1989" darkHeight="1141" showCaption="false"} :::Paragraph{indent="1"} Gateway network connections in your cloud and on-premise datacenter ::: *nZTA Gateway* deployment using this topology offers the following attack protection benefits: - **mTLS Communication**: By using mTLS for communication with the *Controller*, your Gateways are protected from traffic originating from unauthorized and un-enrolled devices. - **DMZ/DDoS Deployment**: *nZTA* allows customers to deploy their own DDoS (Distributed Denial of Service) mitigations, either through network firewalls or DDoS services, before traffic reaches the *nZTA Gateway*s deployed in your datacenter. - **SSL inspection**: If an administrator chooses to use SSL interception or deep inspection for traffic coming into the network or to back-end applications, this can be achieved on the internal *Private Subnet* side before traffic reaches your back-end application servers. The *Controller* communicates with all registered Gateways to validate user sessions, and for reporting/analytics. Each Gateway maintains a timeout period of 5 minutes for validation of user sessions. If a Gateway fails to obtain a response from the *Controller* within this time limit, any new session authorization requests are denied. However, existing sessions remain connected to the applications and resources at that location until the user session expires. To learn more about user session expiry, see [On-Demand Connection Handling](docId\:odDr4Z3VrHMCgVhHAWv7j). For all platforms, make sure the firewall rules for the **Public Subnet** in which your *nZTA Gateway***External Interface** resides is configured to accept inbound client connections on TCP port 443. Furthermore, make sure you configure the **Network Gateway** serving your **Private Subnet** to allow outbound traffic to the *Controller* in the following ways: - Allow outbound TCP traffic on port 443 to the *Controller* service - Allow outbound UDP traffic to the following Network Time Protocol (NTP) services: - time.windows.com (port 123) - time.nist.gov (port 123) If you maintain your own DNS service at the datacenter, you can specify these details during Gateway deployment. If you are planning to use your *nZTA Gateway* to serve SaaS (Software-as-a-Service) applications, configure your 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 *nZTA Gateway*. ## Using Dynamic IP Addressing to Profile Client Traffic :::hint{type="info"} This feature is supported for VMware (ESXi) Gateway types only. ::: :::hint{type="info"} This feature is not supported for Gateway Groups. ::: :::hint{type="info"} Dynamic IP pool feature is supported with ZTA 25.x Gateways. ::: A client establishes a secure tunnel to a Gateway in order to reach the applications and resources controlled by a Secure Access Policy. Traffic from the client passes through the tunnel to the Gateway, and from the *Internal* network interface on the Gateway to the application. The application or resource sees the client's traffic as originating from the Gateway's internal interface. This scenario is transparent to the client and application - the Gateway manages traffic back to the client using Network Address Translation (NAT) to map traffic on the internal interface to the client's source IP address. However, in some circumstances you might want to profile or monitor end-to-end traffic for your clients. This is difficult beyond the Gateway as traffic at the application appears to originate from the same source IP address (that of the Gateway internal interface). To facilitate this, *nZTA* includes the option to specify a pool of IP addresses in a dedicated subnet that the *Controller* can dynamically assign to client sessions. As a client sends traffic to an application or resource, the Gateway establishes a mapping from the tunnel IP address to one of the free IP addresses in the pool. This dynamically-assigned IP address is then used as the source IP address when sending client traffic to the application. The Gateway again uses NAT to manage the connections to each client. You can configure dynamic IP addressing when adding a new Gateway or by editing an existing Gateway configuration. To learn more, refer to the Gateway configuration workflows described in this chapter. To read more about how to enable Dynamic IP Addressing in an existing Gateway, see [On-Demand Connection Handling](docId\:odDr4Z3VrHMCgVhHAWv7j). To use dynamic IP addressing, the *Controller* requires you to define a unique address range for each applicable Gateway, using CIDR notation. For example, `192.0.2.0/24`. You can add only one IP address range per Gateway. :::hint{type="info" indent="1"} The allowed subnet range is 8-28. Make sure you select a subnet value that provides the amount of IP addresses necessary to map the expected number of clients connecting to the Gateway. If you exhaust the IP address range, your clients can still connect, although traffic profiling is not possible. ::: When configuring an address range, make sure this does not overlap with dynamic IP address ranges assigned to other Gateways. ## 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 *nZTA Gateway*s. 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) ## Viewing and Monitoring Gateways in the *Controller* To view, configure, and monitor the health of your deployed Gateways and Gateway Groups, use the **Secure Access > Manage Gateways** section of the *Controller* Tenant Admin portal. The pages in this section remain inactive until you select a Gateway or Gateway Group. :::hint{type="info" indent="1"} To view detailed analytics for your deployed Gateways, see also [Monitoring nZTA Gateway Activity](docId\:odDr4Z3VrHMCgVhHAWv7j). ::: To view information for a Gateways or Gateway Group: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. 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*: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/VDbeDSITk9lMnUC8c2b7l_gatewayslist.png" alt="Viewing All Gateways" position="flex-start" size="80" width="892" height="412" initialPath="img/gatewayslist.png" githubPath="img/gatewayslist.png" darkWidth="892" darkHeight="412" showCaption="false"} Viewing All Gateways The health and status of each Gateway instance is denoted by the indicator colors used in the left-most column; *green* for connected/ready or *red* for disconnected/not ready. Unregistered Gateways are denoted by a missing indicator. Additional status information is given under *Connection Status*, with the current software *Version*, and the *Status* of any scheduled tasks. :::hint{type="info"} Use the *Search* box at the top enter a text search term to narrow the list to only matching Gateways and Gateway Groups. ::: 3. Select a Gateway or Gateway Group from the list to view the *Gateways Overview* page. This page provides further status and configuration details for the selected instance, as well as *Performance*, *Concurrent Sessions*, and *Throughput* usage graphs. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/AGUcxWNWyumn4Ur62hHQY_gatewaysperformance.png" alt="Viewing status, configuration, performance and Usage Graphs in the Gateway Overview page" position="flex-start" size="73" width="727" height="829" initialPath="img/gateways_performance.png" githubPath="img/gateways_performance.png" darkWidth="727" darkHeight="829" showCaption="false"} Viewing status, configuration, performance and Usage Graphs in the Gateway Overview page Hover your pointer over a coordinate in each graph to view a tooltip showing detailed metrics for that moment. For Gateway Groups: - **Edit Group**: Edit details for the group, such as name, description, and load balancer public IP address. - **Delete Group Only**: Deletes the Gateway Group record, leaving any contained Gateways intact as standalone (ungrouped) instances. - **Delete Group and Gateways**: Deletes the Gateway Group and all Gateways contained in the group. :::hint{type="info"} This option appears only if the selected Gateway is in a Gateway Group. ::: - **Add Gateway to this Group**: Add a registered standalone gateway to this group. For Gateways: - **Edit Gateway**: Edit details for the Gateway, such as name, description, and public IP address. You can also select or reset the **Use Management Port** property. - **Replace Gateway**: Allows replacement of the Gateway virtual machine instance associated with this *nZTA Gateway* record. This option regenerates a Gateway definition file based on the existing networking details stored in the Gateway record, but with a new one-time token, to allow deployment and registration of a new virtual machine instance. :::hint{type="info"} A Gateway virtual machine deployed to replace an existing Gateway might be launched with a different public IP address on the external network interface. To update the public IP address setting stored for the Gateway in *nZTA*, use the *Gateway Network Settings* section of the **Secure Access > Manage Gateways > Gateway > Configuration** page. For more details, see [Editing Gateway Configuration](docId\:odDr4Z3VrHMCgVhHAWv7j). ::: - **Remove from Group**: Removes this Gateway from a Gateway Group. :::hint{type="info"} This option appears only if there are existing Gateways in the Group. ::: - **Delete Gateway**: Deletes the Gateway record. - **Upgrade to \**: Upgrades the registered Gateway virtual machine instance to the specified version, see [Upgrading Gateways](docId\:odDr4Z3VrHMCgVhHAWv7j). - **Rollback to \**: Reverts the registered Gateway virtual machine instance to the specified version, see [Rolling Back a Gateway to a Previous Version](docId\:odDr4Z3VrHMCgVhHAWv7j). :::hint{type="info"} The available menu options vary depending on whether the selected Gateway is registered and connected to the *Controller*. ::: ## Viewing Gateway Logs The *Logs* page enables you to view the Access, Admin, and Event logs for the selected Gateway or Gateway Group. To view Gateway logs: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, click the **Secure Access** icon, then select **Manage Gateways > Gateway List**. The *Gateways List* page appears, showing the full list of Gateway Groups and standalone Gateways currently configured on the *Controller*. 3. Select the required Gateway or Gateway Group. The *Gateways Overview* page appears for the selected Gateway/Gateway Group. 4. Select the **Logs** tab. :::Paragraph{indent="1"} The *Gateways Logs* page appears. ::: This page supports the following features: - Select the log type you want to view in the **Log Type** drop-down list. Choose from: - Access Logs - Admin Logs - Event Logs - Set a **Time Period** over which the logs are shown. Use the time period selector to set a time period or range for your log results. Click the calendar (highlighted) to show the selector: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/6q9YHNr9VFBqHQt1AjUNs_logtimeselector.png" alt="Setting a log time period" position="flex-start" size="80" width="1128" height="783" initialPath="img/log_time_selector.png" githubPath="img/log_time_selector.png" darkWidth="1128" darkHeight="783" showCaption="false"} Setting a log time period Set the time period you want to view using the available ranges at the top-left. Choose from: :::Paragraph{listStyleType="disc" indent="2"} Last 60 minutes ::: :::Paragraph{listStyleType="disc" indent="2"} Last 24 hours (default) ::: :::Paragraph{listStyleType="disc" indent="2"} Last 7 days ::: :::Paragraph{listStyleType="disc" indent="2"} Last 1 month ::: :::Paragraph{listStyleType="disc" indent="2"} Custom ::: For **Custom**, set a specific *From* and *To* to denote the start and end of your custom date/time range. :::hint{type="info"} The custom date/time calendar controls are enabled for only the **Custom** option. However, the calendar continues to identify the applicable start and end date-time for all predefined time periods. ::: To apply your changes, click **Apply**. The selected time period is displayed in the filter bar and data on the page updates accordingly. :::hint{type="info"} To configure the timezone, see [Setting the Timezone](docId\:qAQLPFWfOt_GYC0QQw64z). ::: - Logs are refreshed automatically by changing the criteria. To manually refresh the log display, click the following icon: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/of7g0Zx7V_-afc1L71KOc_iconcirculararrow.png" alt="Refreshing the page data" position="flex-start" size="10" width="48" height="48" initialPath="img/icon_circulararrow.png" githubPath="img/icon_circulararrow.png" darkWidth="48" darkHeight="48" showCaption="false"} Refreshing the page data - To change the fields displayed for each log line, use the following icon: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/Z3PYoT1mrt5QSTh_p54yB_iconcolumnselector.png" alt="Show or hide log fields" position="flex-start" size="10" width="38" height="40" initialPath="img/icon_columnselector.png" githubPath="img/icon_columnselector.png" darkWidth="38" darkHeight="40" showCaption="false"} Show or hide log fields In the field selector, click a field name to toggle between show or hide. A *tick* icon indicates a displayed field. After you are finished, click the context menu icon to close the selector. Choose from the following fields: :::Paragraph{listStyleType="disc" indent="2"} Session identifier ::: :::Paragraph{listStyleType="disc" indent="2"} Gateway identifier ::: :::Paragraph{listStyleType="disc" indent="2"} Gateway name ::: :::Paragraph{listStyleType="disc" indent="2"} Source IP address ::: :::Paragraph{listStyleType="disc" indent="2"} User name associated with the event, where applicable ::: :::Paragraph{listStyleType="disc" indent="2"} User device identifier, if available ::: :::Paragraph{listStyleType="disc" indent="2"} A description of the event ::: - Use the following icon to trigger the advanced filter selection: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/XXmT8Ibty1t1-s8Otw2kb_iconadvfilter.png" alt="Applying a filter to the log display" position="flex-start" size="10" width="28" height="30" initialPath="img/icon_advfilter.png" githubPath="img/icon_advfilter.png" darkWidth="28" darkHeight="30" showCaption="false"} Applying a filter to the log display Use the filter to narrow down the displayed log records to your selected criteria. For example, to show only those log messages with a critical severity level, or pertaining to a specific user, or both. To learn about log filtering, see [Filtering the Logs](docId\:odDr4Z3VrHMCgVhHAWv7j). - Use the following field to use search term highlighting. Enter a value into the search box, *nZTA* highlights all matches in the log display. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/yO-7wqoxMJIVP_EtwOGcY_logsearchbox.png" alt="Highlighting a search term in the logs" position="flex-start" size="19" width="186" height="54" initialPath="img/log_searchbox.png" githubPath="img/log_searchbox.png" darkWidth="186" darkHeight="54" showCaption="false"} Highlighting a search term in the logs - To switch between the default and denser data views, use the following icon: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/Ks8rvcnrlcj6gKxBSK3M5_iconviewdensity.png" alt="Setting the view density" position="flex-start" size="10" width="30" height="28" initialPath="img/icon_viewdensity.png" githubPath="img/icon_viewdensity.png" darkWidth="30" darkHeight="28" showCaption="false"} Setting the view density - To apply grouping to the displayed log records, click the **Group By** button. This feature applies grouping to a selected field in the log record display, such that records are accumulated and grouped together under each unique data item identified in that field. Through grouping, an admin can quickly view the number of records of a particular type. To learn more about record grouping, see [Viewing Detailed Logs for a Chart](docId\:odDr4Z3VrHMCgVhHAWv7j). - To view a single log entry in a dedicated panel, click the log message text to activate the info-panel view: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/95SD7c7u2DLX6Wx2pzK6m_gwlogsidepanel.png" alt="Viewing a single log entry in the info-panel" position="flex-start" size="32" width="320" height="361" initialPath="img/gwlogsidepanel.png" githubPath="img/gwlogsidepanel.png" darkWidth="320" darkHeight="361" showCaption="false"} Viewing a single log entry in the info-panel In the info-panel, use the arrow icons to cycle through the previous and next log entries in turn. - To view, sort, and filter the log messages in context with all other logs in your deployment, click **VIEW IN LOGS PAGE** (see [Checking the Logs](docId\:odDr4Z3VrHMCgVhHAWv7j)). This page supports the following features: ## Viewing Gateway Tasks The *Tasks* page enables you to view the current task list for the selected Gateway or Gateway Group. A task is triggered when an action on a Gateway requires an update to be made to the Gateway instance. For example, if you add a Gateway to a Gateway Group, two tasks are created: A Gateway Group change, and a change of certificate on the joining Gateway. This list is read-only and cannot be modified. To filter the displayed tasks, use the **Task Type** and **Date** controls at the top of the page. Task type contains the primary categories within which each task falls. To view all tasks for the current day, click **Clear**. To view Gateway tasks: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, click the **Secure Access** icon, then select **Manage Gateways > Gateway List**. The *Gateways List* page appears, showing the full list of Gateway Groups and standalone Gateways currently configured on the *Controller*. 3. Select the required Gateway or Gateway Group. The *Gateways Overview* page appears for the selected Gateway/Gateway Group. 4. Select the **Tasks** tab. The *Gateway Tasks* page appears, showing the task list for the selected Gateway/Gateway Group. 5. (Optional) Select the **Task Type** and **Date** to filter the results. ## Editing Gateway Configuration The *Configuration* page enables you to edit the selected Gateway or Gateway Group configuration. To edit a Gateway/Gateway Group: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, click the **Secure Access** icon, then select **Manage Gateways > Gateway List**. The *Gateways List* page appears, showing the full list of Gateway Groups and standalone Gateways currently configured on the *Controller*. 3. Select the required Gateway or Gateway Group. The *Gateways Overview* page appears for the selected Gateway/Gateway Group. 4. Select the **Configuration** tab, or click *Edit Gateway/Group* from the context menu at the top-right. 5. The *Gateway Configuration* page appears, showing the current settings for the selected Gateway/Gateway Group: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/pGqpTN1KWlv2P6MN4o0aA_gatewayseditconfig.png" position="flex-start" size="50" width="499" height="832" initialPath="img/gateways_edit_config.png" githubPath="img/gateways_edit_config.png" darkWidth="499" darkHeight="832" showCaption="false"} Editing a Gateway configuration On this page, you can edit the following settings: | **Setting** | **Description** | | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Public Address or CNAME | The public IP address or CNAME at which clients can externally reach the Gateway instance. To learn more, see [Configuring Networks in your Gateway Datacenter](docId\:odDr4Z3VrHMCgVhHAWv7j). | | DNS Server | Contains settings relating to the Domain Name Service (DNS). Enter your **Primary DNS** and **Secondary DNS** IP addresses, and **DNS Search Domain**. For DNS Search Domain, you can enter multiple comma separated domains, with a maximum restriction of 255 characters.
**Note**: Ensure DNS server IP of ZTA Gateway is different from that of ICS Gateway. | | (vSphere Gateways only) Use Manual Settings | Allows you to manually configure IP address settings for your Gateway **Internal**, **External**, and (optional) **Management** interfaces. Deselect this option to instead use DHCP. | | Persistent Tunnel | Persistent tunnel support for NZTA enhances the reliability of user sessions by keeping the NZTA tunnel active for the duration of the session idle timeout specified in Session Settings. With this feature enabled, the tunnel remains connected until the session idle timeout is reached.
If persistent tunnel support is not enabled, the tunnel remains active only for the period defined in the Tunnel Idle Timeout setting (range: 5–120 minutes; default: 15 minutes) when there is no network traffic. Once the tunnel idle timeout elapses, the NZTA tunnel automatically terminates.
Enabling this feature helps ensure uninterrupted connectivity throughout the entire session duration. | | (vSphere and KVM Gateways only) Use Dynamic Tunnel IP
Supported on ICS 25.x release. | Allows you to assign a pool of IP addresses that are dynamically mapped to client sessions, such that user traffic from the Gateway to the application can be identified as originating from a specific client. Enter an IP address and subnet (in the range 8-28) in CIDR notation, then click Add. To learn more, see [Using Dynamic IP Addressing to Profile Client Traffic](docId\:odDr4Z3VrHMCgVhHAWv7j). | | Use Server Initiated Connection | When enabled, allows server-initiated connections for each application. Access is established for each client session and automatically removed when the client disconnects. Dynamic Tunnel IP must be enabled for this feature to work. | Update any required Gateway/Gateway Group details, then click **Save Changes**. ## Troubleshooting Gateway Issues The *Troublshooting* page provides tools that enable you to investigate issues that might be affecting your Gateway or preventing it from operating normally. :::hint{type="info" indent="1"} Troubleshooting is available only for fully registered Gateways, and is not supported for Gateway Groups. ::: To view Gateway troubleshooting tools: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, click the **Secure Access** icon, then select **Manage Gateways > Gateway List**. The *Gateways List* page appears, showing the full list of Gateway Groups and standalone Gateways currently configured on the *Controller*. 3. Select the required Gateway or Gateway Group. The *Gateways Overview* page appears for the selected Gateway/Gateway Group. 4. Click the **Troubleshooting** tab. :::Paragraph{indent="1"} The *Gateway Troubleshooting* page appears, showing troubleshooting tools and options for the selected Gateway/Gateway Group. ::: The page content is affected by your choice of task in the **Select Troubleshooting Task** drop-down menu: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/8QKClK-dYe2dRBbzwoCy__gatewayststasks.png" position="flex-start" size="34" width="340" height="424" initialPath="img/gateways_ts_tasks.png" githubPath="img/gateways_ts_tasks.png" showCaption="false"} :::Paragraph{indent="1"} Viewing the list of available troubleshooting tasks for this Gateway ::: Choose from: - **Troubleshooting Overview**: a list of all captured data based on your completed troubleshooting activities. - **Debug Log**: make a trace recording of a selected process. - **Node Monitor**: Create a snapshot that includes node monitoring statistics to assist Ivanti Technical Support team in debugging the problem. - **TCP Dump**: observe and record TCP packets on the network. - **Commands**: run various common network troubleshooting commands. - **System Snapshot**: take a system snapshot. :::hint{type="info" indent="1"} The availability of specific tasks is limited by Gateway version. Gateway instances based on versions earlier than 21.6 might have access only to a subset of this list. ::: ### Troubleshooting Overview The *Troubleshooting Overview* contains a list of all captured data based on your completed troubleshooting activities. This shows: - TCP dumps - Debug logs - System snapshots ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/lfz19v6ZTjXa2KwwCg5hC_gatewaystsoview.png" position="flex-start" size="80" width="1365" height="858" initialPath="img/gateways_ts_oview.png" githubPath="img/gateways_ts_oview.png" showCaption="false"} :::Paragraph{indent="1"} View a list of data files captured from previous troubleshooting activities ::: To filter the displayed files to a single type, use the **Select Troubleshooting Type** selector. ### Debug Log If your users are having difficulties getting access to a website or other resource, use the *Debug Log* task to make a trace recording for one or more selected processes running on the Gateway. This recording can then be uploaded to the *Controller* for offline analysis by *Ivanti* Technical Support. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/3LgZscYhVdc0uJF0sKkZG_gatewaystsdbglog.png" position="flex-start" size="80" width="916" height="463" initialPath="img/gateways_ts_dbglog.png" githubPath="img/gateways_ts_dbglog.png" showCaption="false"} :::Paragraph{indent="1"} Recording a trace of a named process ::: Set the following fields: - **Process Names**: the names of one or more Gateway processes to trace - **Event Codes**: the event code, or codes, to observe in the trace. Only events matching these codes are appended to the log. - **Max Debug Log Size (MB)**: The maximum allowable size, in MB, for the log file. Choose a value between 0-250. - **Log Detail Level**: The level of verbosity to include in the log. Choose a value between 0-60, from lowest to highest detail. - **Include System Logs**: Whether or not to include Gateway system logs (event, access, and admin logs) as part of the debug log. To activate the trace, Select **Enable Debug Logs** and select **Save Settings**. To activate the trace, select **Enable Debug Logs** and then select **Save Settings**. :::hint{type="info" indent="1"} Use **Cancel** to return the settings on this page to the state last saved. ::: After a trace has been captured, select **Upload** to upload the trace log file to the *Controller*. ### Using Node Monitoring When you enable the node monitor, the ICS Gateway captures certain statistics specific to the nodes on your system. Using the snapshot that results, the support team can identify important data, such as network statistics and CPU usage statistics. Ensure this option is always enabled to help in debugging and monitoring system issues. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/qh_kJevF8RF_208ct8H09_nodemonitor.png" position="flex-start" size="80" width="916" height="310" initialPath="img/node_monitor.png" githubPath="img/node_monitor.png" showCaption="false"} To enable node monitoring: 1. From the **Troubleshooting Logs and System Snapshots** drop-down menu, select **Node Monitoring**. 2. Select **Enable Node Monitoring** check box. 3. Click **Save Settings**. ### TCP Dump Use the *TCP Dump* task to inspect packet data passing through the network interfaces on your Gateway: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/SoDGGdSTVLLicnAfIoXBW_gatewayststcpdump.png" position="flex-start" size="80" width="1636" height="486" initialPath="img/gateways_ts_tcpdump.png" githubPath="img/gateways_ts_tcpdump.png" showCaption="false"} :::Paragraph{indent="1"} Inspecting TCP data packets ::: Select the network interfaces you want to inspect: - Internal or Virtual Port - External or Virtual Port - Management Port (where applicable) Next, set the following optional fields as required: - **Filter**: A comma-separated filter expression for the TCP dump, based on standard UNIX TCP Dump filters. For more information, see [https://www.freebsd.org/cgi/man.cgi?query=tcpdump](https://www.freebsd.org/cgi/man.cgi?query=tcpdump). The following table provides some examples: - **Options**: Command-line options to specify with the tcpdump. Use a space-separated list in the form "-\