Prisma Access SASE Extra Security Tips and Features

nikoolayy1 · ‎11-22-2022

1. Allowing only on-prem outbound connections to the Prisma Access SASE cloud(VPN responder/passive mode)

2. Why there is no need for XFF(X-Forwarded-For HTTP) headers to be inserted

3. Prisma Access SASE DNS proxy and resolution

4. GlobalProtect Agent Explicit Proxy support

5. Prisma Access ADEM (Access Autonomous Digital Experience Management )

6. Prisma Acess traffic replication (tcpdump/packet capture)

1. Allowing only on-prem outbound connections to the Prisma Access SASE cloud(VPN responder/passive mode)

The connection between the Prisma Access Cloud and the on-prem devices is usually based on the IPSEC protocol for site to site VPNs. For extra security it is important to configure Prisma Access to be the VPN responder and the on-prem firewall/router as the VPN initiator. To enable responder mode you need to enable IKE passive mode so that Prisma Access only responds to IKE connections and does not initiate them.

When Prisma Access is the VPN responder for investigating site to site VPN issues, the responder device will have more information than the other initiator device. If the VPN tunnel is not coming up, check the system logs in Panorama GUI if Prisma Access is managed by Panorama. If Prisma Access is Cloud Managed then there will be similar logs in the cloud portal.

Figure 2_Prisma-Access-SASE-tips_palo-alto-networks.png

For more information, please see: Prisma Access (Cloud Management)

In some cases only the ESP protocol (IP protocol 50) needs to be enabled in the two directions like for Prisma SD-WAN. Therefor it could be needed to ask the ISP provider to allow only this protocol for inbound connections to the site and this will help with DDOS protections.

For more information, please see: Prisma SD-WAN Administrator’s Guide

With the new ZTNA connector that will replace the IPSEC tunnels for Service Connections between on-prem devices and the Prisma Access SASE (except for something like the Microsoft AD connection that still may need a tunnel to work correctly), then it could be possible that there is no need at all to allow inbound connections at all as from the video I saw from the Palo Alto's "SASE Converge 2022" there will be no need for any inbound ports to be open so the ZTNA connector should start only outbound connection, which is great !

For more information, please see:

Edit(2023):

As of now the ZTNA connector is now out and it even can auto discover services that are added in the Cloud Identity Engine (CIE) by the on-prem or cloud active directory (AD):

2. Why there is no need for XFF (X-Forwarded-For HTTP) headers to be inserted

In many cases when a cloud based proxy or SASE service is used there is the need of a XFF-header that has the real client IP address to be inserted in the HTTP payload before the IP address to be changed by the NAT features.

Figure 3_Prisma-Access-SASE-tips_palo-alto-networks.png

Figure 4_Prisma-Access-SASE-tips_palo-alto-networks.png

As Prisma Access creates dedicated tenant virtual cloud devices for the mobile users or remote networks, the public IP addresses that are seen in the Internet are dedicated to the organization. For this reason, for example servers that are accessed through the internet, can be configured just to allow the dedicated public Prisma Access Internet addresses.

After you deploy Prisma Access for users for the first time, Prisma Access assigns two

public and, if applicable, egress IP addresses

for each portal and gateway.

These IP addresses are unique, not shared, are dedicated to your Prisma Access deployment, and remain allocated to your tenant until the Prisma Access subscription expires and the grace period is over. If you have a multi-tenant setup, Prisma Access adds dedicated IP addresses for each tenant. Since the public IP address is the source IP address used by Prisma Access for requests made to an internet-based destination, you may need to know what the public IP addresses are and add them to an allow list in your network to provide your users access to resources such as SaaS applications or publicly-accessible partner applications.

For more information, please see:

You can also use an API script to retrieve the assigned IP addresses.

For more information, please see: Retrieve the IP Addresses for Prisma Access

When using Inbound Access to allow access to Public applications through Prisma Access from the Internet then the Prisma Access will by default source-NAT the client IP addresses, but many servers may need to disable this as for example the web-servers to be able to see the real client IP addresses and use them for some advanced functions.

For more information, please see:

3. Prisma Access SASE DNS proxy and resolution

The DNS proxy in Prisma Access sends the requests to the DNS servers you specify. The source address in the DNS request is the first IP address in the IP pool you assign to the region. To ensure that your DNS requests can reach the servers you will need to make sure that you allow traffic from all addresses in your mobile user IP address pool to your DNS servers. This may cause confusion when reviewing the logs for DNS traffic. When Prisma Access does not proxy the DNS requests, the source IP address of the DNS request changes to the IP address of the device that requested the DNS lookup. This source IP address allows you to enforce source IP address-based DNS policies or identify endpoints that communicate with malicious domains. This behavior applies for both mobile users and remote network deployments.

For more information, please see: DNS and Prisma Access

For Mobile Users:

Figure 5_Prisma-Access-SASE-tips_palo-alto-networks.png

DNS Resolution for Mobile Users—GlobalProtect Deployments

For Remote Networks :

Figure 6_Prisma-Access-SASE-tips_palo-alto-networks.png

DNS Resolution for Remote Networks

For instructions on creating specific DNS settings that bypasses the default DNS proxy Object for Mobile Users, for troubleshooting or other use cases you can use the procedure below:

How to bypass Prisma Access DNS Proxy configurations for specific Mobile Users

Note: Use the Prisma Access as the DNS service for your users if you are also using features like GlobalProtect FQDN Exclusions as the Local DNS can resolve the DNS name to a different IP address than the Prisma Access and this can cause issues in some cases as Intelligent DNS services may return different DNS resolutions.

Enforce GlobalProtect Connections with FQDN Exclusions

4. Globalprotect Agent Explicit Proxy support

Now the Globalprotect Agent supports IPSEC/SSL VPN tunnels and at the same time it can can act as Web Proxy Agent for when Prisma Access is used in explicit proxy mode to only filter web traffic.

Figure 7_Prisma-Access-SASE-tips_palo-alto-networks.PNG

For information see:

5. Prisma Access ADEM(Access Autonomous Digital Experience Management )

The Prisma Access ADEM (Access Autonomous Digital Experience Management ) is a extra feature just for Prisma Access (not available for on-prem firewalls with globalprotect) to investigate slowness and latency issues between the client computer, the prisma access cloud and the destination server/web application.

Figure 8_Prisma-Access-SASE-tips_palo-alto-networks.png

For information see:

6. Prisma Acess traffic replication (tcpdump/packet capture)

As of now you can do a packet capture on Prisma Access that is saved to a AWS bucket if you need to investigate any issue that may need such capture. The feature is called traffic replication.