Episode Transcript:
John:
Hi PANCasters and welcome back. Today we have with us Amit Srivastava who is here to share some information on Prisma Access ZTNA connectors and a really good use case where they can help. Welcome Amit, to start with, what is a ZTNA connector?
Amit:
Let's start with a brief recap of the building blocks of Prisma Access. Prisma Access essentially has three main building blocks: Mobile user gateways, Remote Networks, and Service Connections. Mobile Users gateways and Remote networks are instances that help mobile users and remote offices securely access the internet, respectively. Both MUs and RNs are security processing nodes. Service connections, on the other hand, help terminate connections to and from data-center locations or other entities external to Prisma Access. Service Connections are not security processing nodes but provide a means to terminate IPSec connections. The solution here leverages the SC component of Prisma Access.
The ZTNA connector is a virtual machine that allows mobile users and users at branch offices to access private applications using a secure tunnel. This is a turnkey solution from Palo Alto Networks within the Prisma Access family, which automatically creates secure tunnels to enable access to private applications within Data Center locations, headquarters, or public clouds.
ZTNA connector virtual machines automatically create tunnels to Prisma Access, eliminating the need for manual IPsec connections between Prisma Access locations and your private application endpoint. The ZTNA connector VM is installed in the same subnets as the applications are . Once the ZTNA connector VM is installed, it discovers the nearest Prisma Access location and initiates a secure IPSec tunnel to the Prisma Access tenant. This tunnel is terminated within the Prisma Access tenant by a ZTT node (ZTNA connector Tunnel Terminator). This ZTT node is a special Service Connection that helps Prisma Access terminate the ZTNA connection.
Operationally, ZTNA nodes in a region remain active for 24 hrs even after all connectors in the region are deleted. If new connectors come up in the region during this time, these ZTT nodes are reused.
John:
Great, thanks Amit. So what is the use case you wanted to discuss?
Amit:
The ZTNA connector simplifies access to an organization’s private applications by providing a fully automated, turnkey solution automating tunnel creation, management, and routing. Functionally its a special service connection. We have an interesting use case that we can leverage this technology with. When two organizations merge through an MnA activity or other business need, one of the most challenging areas is network integration. The reason this is challenging is usually because of RFC 1918 private addresses, which more often than not overlaps across the two organizations.
ZTNA connectors give us access to private applications. However, in case two organizations merge, the most painful part is making sure there are no overlapping RFC 1918 addresses. Traditionally, there are two ways to solve this problem
The first , you can either remove all duplicate IP addresses in the RFC 1918 space in both organizations. Needless to say, this would entail a huge re-IP project. This is not desirable for any operations team as its an enormous overhead.
Secondly, you could use PANOS firewalls at the edge of the network, rewriting DNS payloads, NAT, and providing IPsec tunnel endpoints
Both these solutions need additional firewalls and configurations that typically get audited by INFOSEC and need approvals, besides being complex to implement needing manual configurations
With the use of the ZTNA connector, you can automate this process in a way that is very compelling to operators and IT teams involved in integrations during mergers and acquisitions with two organizations using Prisma Access infrastructure.
ZTNA connectors sit within the private address space, with the service connector part of the solution within the Prisma Access tenant. This will program the DNS lookups within each tenant such that when RNs and MUs get the traffic for the private address space, they are able to do it exactly as intended. Both tenants can continue to use RFC 1918 address spaces with overlaps as long as they enter the FQDN and associated IPs within the ZTNA infrastructure.
ZTNA components also provide clear status information, logs and diagnostic tools to help operators troubleshoot issues.
ZTNA connector traffic is also sent to SLS aka Strata Logging Services. Regardless of your Management platform, operators can view logs under Incident and Alerts/Log Viewer tab.
John:
Sounds like ZTNA connector is a lot easier to deploy than other methods. Is there anything we need to be aware of when configuring ZTNA connector such as implementation issues or additional licensing?
Amit:
To enable ZTNA connectors is fairly simple. A minimum prisma access version of 5.0 is required. If you are using Panorama to manage Prisma Access, you must also upgrade the cloud services plugin to a minimum version of 4.0.
Once you have your Prisma Access versions sorted, add your ZTNA connector IP blocks that Prisma Access would use internally to route traffic between your MU,RNs and connector VMs. Then all you need to do is to launch ZTNA connector from SCM or Panorama and you are all set
John:
Thanks Amit. What would you say are the key takeaways?
Amit:
Like I mentioned earlier the ZTNA connector is a turnkey solution. So the first takeaway is definitely the Turnkey Automation aspect. The ZTNA connector and the ZTT nodes replace manual IPsec configurations with automated, secure tunnels between private apps and Prisma Access.
Next is that its a seamless Architecture: It resides in the same subnet as your applications, discovers the nearest Prisma Access location, and terminates at a specialized ZTT (Tunnel Terminator) node.
ZTNA solutions Solves IP Overlap problems: Its sort of a "silver bullet" for Mergers & Acquisitions, allowing two organizations to integrate without expensive "Re-IP" projects or complex NAT rules, even if they use the same RFC 1918 private IP addresses.
ZTNA solution also simplifies Operations: By leveraging FQDN-based routing, it ensures users reach the correct application based on its name, effectively automating the DNS and routing logic across different Prisma Access tenants.
And like I mentioned earlier-to ensure stability, ZTNA nodes remain active for 24 hours after a connector is deleted, allowing for immediate reuse and reduced downtime during updates or re-deployments.
John:
Thanks again Amit. PANCasters, as always the transcript and links to additional content can be found at live.paloaltonetworks.com.
Related Content:
Prisma Access
