About SpencerMitchell

GlobalProtect: Pre-Logon Authentication   In my previous article, " GlobalProtect: Authentication Policy with MFA ," we covered Authentication Policy with MFA to provide elevated access for both HTTP and non-HTTP traffic to specific sensitive resources. You can see a diagram of the environment  here .   In this post, we are going to add pre-logon authentication using machine certificates. The value of pre-logon authentication means that a device can be connected to a gateway before an actual user logs into the machine, allowing certain internal resources to be accessible or scripts to be run. For more information about pre-logon, please review this TechDocs article: Remote Access VPN with Pre-Logon .   NOTE: This article assumes the following: You have already followed the previous articles in this series.   Part V - Pre-logon Authentication Navigate to   Device > Certificate Management > Certificates > Generate to create a machine certificate signed by the root CA that was previously created Enter a   Certificate Name that represents the device Enter a   Common Name that represents the device Select the root CA that was previously created for   Signed By Click   Generate NOTE: It is recommended to use an enterprise CA in a production environment  Generate Certificate - Machine Certificate Signed by Root CA Navigate to   Device > Certificate Management > Certificates > Generate   to create an authentication cookie certificate signed by the root CA that was previously created Enter a   Certificate Name   that represents the device Enter a   Common Name   that represents the device Select the root CA that was previously created for   Signed By Click   Generate Generate Certificate - Authentication Cookie Certificate Signed by Root CA Navigate to   Device > Certificate Management > Certificates > select the newly created machine certificate   > Export Certificate  Set the   File Format to Encrypted Private Key and Certificate PKCS12 and enter a   Passphrase twice Install the certificate on your test machine For the steps with Windows machines, read the following article:   Deploy Machine Certificates for Authentication   For the steps with OS X machines, please read the following articles:   Import a personal certificate into Mac Keychain   GlobalProtect Requests System Keychain Access on OS X For the steps with iOS machines, please read the following article: Configure GlobalProtect App 5.0 on iOS 12 to Use Client Certificate For Authentication   Navigate to   Device > Certificate Management > Certificate Profile > Add to create a new   Certificate Profile Enter a   Name Navigate to   CA Certificates > Add to add the root CA that was created previously Click   OK Certificate Profile - Add New Certificate Profile Navigate to Policies > Security > Add to create a rule above your existing rules which allows access from devices assigned the Pre-logon user to the minimum internal resources necessary Policies > Security > Add Rule Navigate to   Network > GlobalProtect > Portals > select the existing portal that was previously created Navigate to   Agent > Add Enter a   Name Enable   Authentication Override and select the certificate to be used for authentication cookies that was created previously NOTE: Pre-logon will only work if:  Authentication Override is enabled and the   Certificate Profile created previously   is applied under the   Portals > (your portal) > Authentication tab Authentication Override is   enabled and the Certificate Profile created previously   is not applied under the Portals > (your portal) > Authentication tab Authentication Override is not enabled and the Certificate Profile created previously is applied under the Portals > (your portal) > Authentication tab In this use case, we are using option two, but it's important to note that it will fail if the user has not been previously connected. As we have an internal gateway configured, this will allow the user to connect, or refresh the connection, while on the internal network to generate the Pre-logon cookie. (See "GlobalProtect Pre-Logon Using Cookie-Based Authentication" for more information.) Configs > Authentication Tab for Portal Machine Config Navigate to  Internal  and enter the same information that exists in your other agent configuration Configs > Internal Tab for Home Internal Gateway Navigate to External and enter the same information that exists in your other agent configuration Configs > External Tab for Home External Gateway Navigate to   App and set the   Connect Method to   Pre-logon (Always On) Click OK Configs > App Tab for Connect Method to Pre-logon (Always On) Navigate to Network > GlobalProtect > Portals > select the existing portal that was previously created Navigate to Agent and select the other   Agent that was created prior to beginning the configuration changes in this article (NOT the portal machine config you created above) Enable   Authentication Override and select the certificate to be used for authentication cookies that was created previously  Configs > Authentication Tab for Portal Users Config Navigate to   App and set the Connect Method to Pre-logon (Always On) Click OK Configs > App Tab to Connect Method to Pre-logon (Always on) Navigate to Network > GlobalProtect > Gateways > select the external gateway that was previously created Navigate to   Authentication > Certificate Profile and the certificate profile that was previously created GlobalProtect Gateway - Configuration Certificate Profile Navigate to   Agent > Client Settings > select the existing config   > Authentication Override then enable it and select the certificate to be used for authentication cookies that was created previously Click   OK Configs > Authentication Override Tab Click   OK Commit the configuration You should now start seeing entries in the   System Logs that show successful authentication events with a user name of   Pre-logon (you can filter the logs by   (description contains 'pre-logon')). Based on the configuration changes implemented from this and previous articles, we are now authenticating via machine certificates, user credentials, and DUO. ... View more

GlobalProtect: Authentication Policy with MFA   In my previous article, " GlobalProtect: User/Device Context & Compliance ," we covered security policy matching based on user identity and device context provided via the GlobalProtect app. We also enabled notifications to the end user based on compliance of the endpoint.   In this post, we are going to configure Authentication Policy with MFA to provide elevated access for both HTTP and non-HTTP traffic to specific sensitive resources. You can see a diagram of the environment  here .   The value in leveraging Authentication Policy with MFA is to ensure that regardless of whether or not a user is known and the device is compliant, they must authenticate with multiple factors to validate their identity prior to accessing a specific resource. This helps prevent lateral movement by malicious attackers that are persisting internally via a compromised machine or with phished credentials.   NOTE: This article assumes the following: You have already followed the previous articles in this series You have   DUO MFA configured Although this capability can be configured without GlobalProtect for HTTP applications, we are going to focus on non-HTTP applications to highlight the GlobalProtect app's role in the authentication prompt process.     Part IV - Authentication Policy with MFA Navigate to   Device > Certificate Management > SSL/TLS Service Profile > Add to create a profile that references the root CA created previously SSL/TLS Service Profile to Add a Profile Navigate to   Device > Authentication Profile > Add to create a new profile that consists of the LDAP and DUO   Server Profiles that were previously created On the   Authentication tab Enter a   Name Set the   Type to   LDAP Set the   Server Profile to   LDAP Enter a   Login Attribute of   sAMAccountName Set the   User Domain to your domain Authentication Profile to Set User Domain On the   Factors tab Check the   Enable Additional Authentication Factors box Add the   Multi-Factor Authentication Server Profile that was previously created as part of your DUO setup Authentication Profile for LDAP Auth-Duo On the   Advanced tab, select the user group previously created to add to the   Allow List Click   OK Navigate to   Device > User Identification > Captive Portal and click on the gear icon Check the   Enable Captive Portal box Select the   SSL/TLS Service Profile and   Authentication Profile that were previously created Set the   Mode to   Redirect Set the   Redirect Host to an IP address of an interface on the firewall In my case, its the IP address of my trust interface Click  OK Captive Portal window to Enable Captive Portal Navigate to   Network > GlobalProtect > Portals > select the previously configured portal   > Agent > select the previously configured config   > App > and change the following   App Configurations parameters Set   Connect Method to   User-logon (Always On) Set   Show System Tray Notifications to   Yes Set   Enable Inbound Authentication Prompts from MFA Prompts (UDP) to Yes Set   Trusted MFA Gateways to the IP address referenced in your   Captive Portal along with port 6082 In my case its   192.168.1.254:6082 Click   OK Config App Tab App to Configurations Parameters Navigate to   Objects > Authentication > Add to create a new Authentication Enforcement Enter a   Name Set the   Authentication Method to   web-form Set the   Authentication Profile to the MFA profile that was previously created Click   OK Authentication Enforcement for Duo Navigate to   Policies > Authentication > Add to create an authentication rule NOTE: If you need a resource for testing, there are plenty of test SSH servers available publicly. In the example below, that is what I am using As shown below, any user in the trust or gp zone that generates traffic destined to a specific server in the untrust zone will be prompted to authenticate, regardless of whether they are a verified user or not Policies > Authentication > Add Authentication Rule Commit the configuration Lastly, when testing with a Windows client, make sure that the host firewall is allowing UDP port 4501 inbound   You should now be able to test access to the resource. Here is the general workflow that you can follow: Ensure the GlobalProtect app is connected to either an external or internal gateway From operational mode in the CLI, run the  ' show user ip-user-mapping all type CP' to show authenticated users It should show   0 users Attempt to access the resource referenced in the Authentication Policy rule, and you will see a prompt requiring you to authenticate GlobalProtect - Protected Resource Upon authenticating via the factors you defined, you should be able to access the resource as well as run the same  'show user ip-user-mapping all type CP'  and see your user account In my next article, "GlobalProtect: Pre-Logon Authentication," we will configure pre-logon authentication using machine certificates. ... View more

GlobalProtect: User/Device Context and Compliance     In my previous article, " GlobalProtect: Expanded Setup ," we covered the expanded setup of GlobalProtect, which included multiple authentication types, as well as the creation of an internal gateway.   In this post, we are going to modify security policy matching based on user identity and device context provided via the GlobalProtect app. We will also enable notifications to the end user based on compliance of the endpoint. You can see a diagram of the environment  here . The value in leveraging user identity and device context in security policy along with end user notifications allow for greater visibility as well as more granular control over what users can access. This same methodology is applicable regardless of user location, and best practices dictate that they should be leveraged wherever possible. If a user is outside of what is required in order to access resources, they can be notified or mapped to a different rule to provide the minimum level of access required in order to become compliant.   NOTE:  This article assumes that you have already followed the previous articles in this series.   Part III - User/Device Context and Compliance Navigate to   Objects > GlobalProtect > HIP Objects > Add to create one or more test objects that are applicable to your environment Name the   HIP Object and enable, checking for something specific to your environment. In my case, I run Cortex XDR Prevent on my workstations, and I will be also testing via an iPhone, so I will create two objects called   AV and   iPhone. HIP Object - General Tab - AV HIP Object - Anti-Malware Tab HIP Object - General Tab - iPhone Navigate to   Objects > GlobalProtect > HIP Profiles > Add to create a profile that references both of the previously created objects NOTE: In the screenshot below, the profile will match based on either of the previously created objects HIP Profile - Compliant HIP Profile Navigate to   Network > GlobalProtect > Gateways > open each of the existing gateways   > Agent > HIP Notification > Add Select the   Host Information profile that was previously created On the   Match Message tab Check the Enable box Enter a message On the   Not Match Message tab Check the   Enable box Enter a message HIP Notification - Compliant HIP Profile - Match Message HIP Notification - Compliant HIP Profile - Not Match Message Navigate to   Policies > Security to create rules based on user group and device context As shown below, we are adding a user group and HIP profile as match criteria Security Policies - Add User Group and HIP Profile Commit the configuration You should now be able to log into GlobalProtect and see a message similar to the following: GlobalProtect - Home Internal Gateway Compliant   You should also be able to see rule matches via the   Traffic logs.   In my next article, "GlobalProtect: Authentication Policy with MFA," we will configure authentication policy with MFA for both HTTP and non-HTTP access to sensitive resources. ... View more

GlobalProtect: Expanded Setup   In my previous article, "GlobalProtect: Initial Setup," we covered the initial setup of GlobalProtect, which included a portal, external gateway, and user authentication via local database.   In this post, we are going to configure multiple external authentication types as well as add an internal gateway. You can see a diagram of the environment here.   Internal Gateways & External Authentication The value of adding an internal gateway means that when users are on the local network, user-to-IP address mappings will be supplied to the firewall along with device context. This data can then be used as security policy match conditions, allowing for much more granular, identity-based visibility and enforcement. External authentication types are recommended for a production environment. In this case, we are going to configure the deployment to leverage LDAP authentication for the portal, MFA via RADIUS (AD credentials and Duo) for the external gateway, and LDAP authentication for the internal gateway. This will provide the best possible user experience for users when they are internal, while also enforcing additional factors of authentication when users are remote.   NOTE: This article assumes that you have already followed the initial setup, which is the previous article in this series. This article also assumes that you already have a domain controller (I am running Windows Server 2012 R2) in your environment installed with DUO authentication proxy installed and running. For details on DUO integration, see this post.   Part II - Expanded Setup Navigate to   Device > Server Profiles > LDAP > Add to create an LDAP Server Profile NOTE: Best practices dictate that a dedicated service account be used for integrating your domain controller with Palo Alto Networks LDAP Server Profile Navigate to   Device > Server Profiles > RADIUS > Add to create a RADIUS Server Profile NOTE: Per my note above, this post assumes that you already have Duo Authentication Proxy installed and running on your domain controller RADIUS Server Profile Navigate to   Device > User-ID > Group Mapping Settings > Add to create a   Group Mapping For   Server Profile, select the   LDAP   profile that was previously created Enter the domain name under   User Domain Group Mapping - Server Profile tab Navigate to the   Group Include List and add the group where your users are stored NOTE: If you are unable to expand the available groups, this typically means that your credentials in the LDAP Server Profile are incorrect Click   OK Navigate to   Device > Authentication Profile > Add For   Type select   LDAP For   Server Profile select the LDAP profile that was previously created Enter   sAMAccountName for the   Login Attribute Enter your domain for the   User Domain Authentication Profile - LDAP type Navigate to the   Advanced tab and select the user group that was previously added to the   Group Include List, which was part of the   Group Mapping you previously created Click   OK Navigate to   Device > Authentication Profile > Add For   Type select   RADIUS For   Server Profile select the RADIUS profile that was previously created Enter your domain name of the   User Domain   Authentication Profile - RADIUS Type Navigate to the Advanced tab and select the user group that was previously added to the Group Include List, which was part of the Group Mapping you previously created Click OK Navigate to   Network > GlobalProtect > Gateways > select the existing external gateway   > Authentication > select the client authentication > change the Authentication Profile to the RADIUS profile that was previously created GlobalProtect Gateway Configuration - Home External Authentication Click   OK Click   OK Navigate to   Network > GlobalProtect > Gateways > Add to create an internal gateway Select the   Interface and   IPv4 Address that correspond to the trust interface Navigate to the   Authentication tab  Select the   SSL/TLS Service Profile that was created in the previous post Create a new   Client Authentication profile and select the LDAP Authentication Profile previously created GlobalProtect Gateway Configuration - Home Internal Authentication Click   OK Click   OK Navigate to   Network > GlobalProtect > Portals > select the existing portal   > Agent > select the existing portal config   > Internal > Internal Gateways > Add to create an   Internal Gateway The   IPv4 entry should correspond to the IP address assigned to the trust interface Click   OK Internal Gateway - Home Internal Gateway Navigate to the App tab, and set the Connect Method to User-logon (Always On) NOTE: Internal Gateway authentication will fail if the Connect Method is set to On-demand Click   OK Click   OK Navigate to   Device > Certificate Management > Certificates > Generate NOTE: As you already created a GlobalProtect certificate in the previous post, you will be creating a new one that both the external and internal gateways can reference. The previous certificate contains a common name that refers to the IP address of the portal and external gateway. As the IP address of the internal gateway is not referenced, this will cause authentication to the internal gateway to fail.  NOTE: Keep in mind that you can also leave the current certificate in place and just create a new one for the internal gateway (essentially, having two), but for the purposes of this post, we will be creating a single certificate to be used for everything. Enter a   Certificate Name Enter the IP address or the DNS name of the interface to which remote users will connect for   Common Name NOTE: In this series of posts, we will be using the public IP address for the common name (represented by 1.1.1.1). It is recommended to use a DNS name in a production environment, but IP addresses will work as well. Select the root CA that was previously created for   Signed By Enter the IP address of the trust interface that corresponds to the internal gateway under   Certificate Attributes   GlobalProtect Generate Certificate Navigate to   Device > Certificate Management > SSL/TLS Service Profile > select the existing profile that was created previously and change the   Certificate value from the old certificate to the new one that was just created Click   OK SSL/TLS Service Profile Navigate to   Policy > NAT > Add NOTE: A NAT rule must be created so that the internal users can reach and authenticate to the portal from the internal network In the General tab, enter a   Name  In the   Original Packet tab, set the   Source Zone   to   trust,   Destination Zone   to   untrust, and the   Destination Address to the untrust IP address (the IP address to which the GlobalProtect Portal is assigned) In the   Translated Packet tab, leave everything set to   None Click   OK Creating a new NAT rule Commit the configuration You should now be able to authenticate both internally and externally via the GlobalProtect app and access resources. It is important to note that authentication failures to an internal gateway are notoriously quiet. In other words, it will look as though you are connected even when you are not. You can validate connectivity by issuing the  ' show user ip-user-mapping all type GP' command. If there is no mapping present, then it means that the app was unable to connect and authenticate to the internal gateway.   In my next article, "GlobalProtect: User/Device Context & Compliance," we will make changes to the configuration to include security policy matching based on user identity and device context via the GlobalProtect app. We will also enable notifications based on compliance of the endpoint. ... View more

GlobalProtect: Initial Setup     In my blog, " GlobalProtect: Overview ," I provided a synopsis of the GlobalProtect series and overall objectives, including a description of each article in this series. I would recommend starting there prior to moving forward.   In this post, I will cover the initial setup of GlobalProtect, which includes a portal, external gateway, and user authentication via local database. You can see a diagram of the environment here.   Part I - Initial Setup   Navigate to   Device > GlobalProtect Client then download and activate the latest version (5.0.8 is a TAC-preferred version at the time of this blog post) Navigate to   Network > Network Profiles > Interface Mgmt > Add and create a management profile to apply to the tunnel interface to which remote users will connect Enable Response Pages NOTE: It is not required to enable Response Pages, but this feature will be used in a subsequent article Click OK  Interface Management Profile - Response Pages Navigate to   Network > Zones > Add and create a new   Layer 3 security zone for your GlobalProtect users Provide a name (e.g.,   gp) Set   Type to   Layer3 Check the   Enable User Identification box Click   OK Zone - Enable User Identification Navigate to   Network > Interfaces > Tunnel > Add and create a new tunnel interface Assign the interface a number (e.g., 1) Assign the interface to the appropriate   Virtual Router Assign the interface to the appropriate   Security Zone Tunnel Interface - Config Navigate to the   IPv4 tab and assign a subnet to be used for your mobile users NOTE: It should be a unique network. Also, note that an IP address on this interface is not a requirement. Tunnel Interface - IPv4 Navigate to the   Advanced tab and apply the Management Profile created for the tunnel interface above  Click   OK Tunnel Interface - Advanced Navigate to   Device > Certificate Management > Certificates > Generate and create a trusted root certificate NOTE: In this series of posts, we will be using self-signed certificates. It is recommended to use third-party certificates in a production environment, but self-signed certificates will work as well. Enter a   Certificate Name Enter the management IP of the firewall for the   Common Name Check the   Certificate Authority box Enter information in other fields if desired (optional) Click   Generate Generate Certificate - Local Certificate Authority Select the certificate you just created, and check the Trusted Root CA box Click   OK Certificate Information - Trusted Root CA Navigate to   Device > Certificate Management > Certificates > Generate and a create certificate for GlobalProtect Enter a Certificate Name Enter the IP address or the DNS name of the interface to which remote users will connect for   Common Name NOTE: In this series of posts, we will be using the public IP address for the common name (represented by   1.1.1.1), and it is recommended to use a DNS name in a production environment but IP addresses will work as well Select the certificate previously created under "Signed By" Enter information in other fields if desired (optional) Click   Generate Generate Certificate - Cryptographic Settings Navigate to   Device > Certificate Management > SSL/TLS Service Profile > Add Enter a   Name Select the Certificate previously created Click   OK SSL/TSL Service Profile Navigate to   Device > Local User Database > Users > Add Enter a   Name   and   Password Click   OK Local User Database Navigate to   Device > Authentication Profile > Add Enter a   Name Select   Local Database for   Type Authentication Profile Navigate to   Advanced > Add Select   All Click   OK Authentication Profile - Advanced Tab Navigate to   Network > GlobalProtect > Gateway > Add In the   General tab Enter a   Name Select the   interface to which remote users will connect Select the   IPv4 Address of the interface NOTE: If your interface is assigned an IP address via DHCP, then you will not have an option to select an   IPv4 Address. Just leave this field set to   None. GlobalProtect Gateway Configuration In the   Authentication tab Select the   SSL/TLS Service Profile previously created Under   Client Authentication click   Add Enter a   Name Select the   Authentication Profile previously created Click OK GlobalProtect Gateway Configuration - Authentication Profile In the   Agent tab In the Tunnel Settings tab Enable   Tunnel Mode Select the   Tunnel Interface previously created GlobalProtect Gateway Configuration - Tunnel Settings Tab In the   Client Settings tab Click   Add In the   Config Selection Criteria tab, enter a   Name Configs - Config Selection Criteria In the   IP Pools tab Add an IP Pool Configs - IP Pools In the   Split Tunnel  tab Add an access route to the   Include section NOTE: In this series of posts we will be routing all traffic through the tunnel. It is recommended to tunnel all traffic in a production environment to ensure consistent protection. Click   OK Configs - Split Tunnel In the   Network Services tab Enter values for   Primary DNS and   Secondary DNS Click   OK GlobalProtect Gateway Configuration - Network Services Navigate to   Network > GlobalProtect > Portal > Add In the   General tab Enter a   Name Select the   Interface to which remote users will connect Select the   IP Address of the interface GlobalProtect Portal Configuration - General In the   Authentication tab Select the SSL/TLS Service Profile   previously created  GlobalProtect Portal Configuration - Authentication Under Client Authentication click Add Enter a Name Select the Authentication Profile previously created Click   OK Client Authentication - Portal Authentication In the   Agent  tab Click   Add under Configs In the   Authentication tab Enter a   Name Configs - Authentication Tab In the   Internal  tab Enable   Internal Host Detection IPv4 Enter an   IP Address   of resource that is always available internally Enter the   Hostname of the IP address to which it resolves NOTE: Internal Host Detection uses a reverse lookup to determine whether or not a device is on the internal network in order to establish a VPN tunnel. See   this post   for additional details if you do not have an internal DNS server. Configs - Internal Tab In the   External  tab Add an   External Gateway  Enter a   Name Enter the   Address to which remote users will connect Configs - External Tab In the   App tab Change the   Connect Method to   On-demand Click   OK NOTE:   In subsequent posts, we will be setting the   Connect Method to   User-Logon (Always On), as that is the recommended best practice Configs - App Tab Back in the   Agent  tab, click   Add  under   Trusted Root CA Add the   Root CA Check the   Install in Local Root Certificate Store NOTE: Selecting this option will transparently install the trusted root CA so that we can test SSL Forward Proxy   decryption in the future. It is not required in order for GlobalProtect to function. Click   OK GlobalProtect Portal Configuration - Agent Tab Navigate to   Policies > NAT and add the   gp   zone you created previously to your source NAT rule so that users in the   gp zone can get out to the Internet Policies - NAT - Add GP Zone Navigate to  Policies > Security  and add security policy rules so that users in the  gp  zone can access internal as well as public resources Policies - Security - Add Security Policy Navigate to Policies > Security and add a security policy rule that allows remote users to access GlobalProtect portal Policies - Security - Add Security Policy for Remote Users Commit the configuration  You should now be able to log into the portal, download and install the GlobalProtect App, and test connectivity. In my next post, "GlobalProtect: Expanded Setup," we will make changes to the configuration to include different forms of authentication and add an internal gateway. ... View more

GlobalProtect Overview   Given the current state of things, many technical professionals are scrambling to safely enable remote access to internal resources and the Internet for their end users. As a result, I thought I would share my GlobalProtect series of articles with the community, as this is an extremely viable option for Palo Alto Networks customers that need a robust remote access solution.   GlobalProtect  is a very flexible Palo Alto Networks core capability that allows remote users to access local and/or Internet resources while still being protected from known and unknown threats. This feature provides policy consistency regardless of end user location, and eliminates the need for managing additional point products in your environment. If you are looking for something highly scalable and do not wish to leverage on-premise hardware/software/licensing,  Prisma Access  is a great option, as it is just as robust from a capabilities standpoint, but is a SaaS service that leverages the scale of public cloud to accommodate a 100% remote workforce.   The goal of this series is to provide Palo Alto Networks users with a walk through for setting up a basic configuration that is applicable to both traditional GlobalProtect and Prisma Access for Mobile Users deployments. This can also be something that you can reference prior to kicking off a PoC or implementation to better understand the general implementation flow. Each post in the series builds upon the previous one. Here are the details:   GlobalProtect Part I   - A basic initial setup with a portal, external gateway, and local DB authentication. GlobalProtect Part II   - An expanded setup to include various forms of authentication (LDAP, RADIUS, Duo), as well as an internal gateway. GlobalProtect Part III   - A further expanded setup to include user-based and HIP-based policy, as well as HIP notifications. GlobalProtect Part IV   - A further expanded setup to include authentication policy with MFA for HTTP and non-HTTP access to sensitive resources.  GlobalProtect Part V   - A further expanded setup to include pre-logon authentication using machine certificates.   If you are unfamiliar with GlobalProtect terminology, see  this link . Additional details regarding GlobalProtect administration can be found in the official Palo Alto Networks  documentation . A diagram of the environment used in this series.   ... View more