Management Articles

Featured Article
Issue A vpn tunnel goes down and comes back up. A look at the global counters shows that the flow_fwd_zonechange counter is incrementing.   > show counter global   Cause The flow_fwd_zonechange counter indicates that the egress zone of a packet does not match the egress zone of the matching session. For this reason, the packet is dropped and the flow_fwd_zonechange counter is incremented.   Scenario 1 Packets are dropped due to a route change. The flow_fwd_zonechange counter increments when a packet is to be forwarded, but the zone of egress interface does not match the egress zone in the session due to a route change because the tunnel is not up. To verify global counter increments please refer to the following knowledge base How to Check Global Counters for Specific Source and Destination IP Address   In this scenario, the initial routing table is as follows: 0.0.0.0/0 metric 10 untrust zone. A tunnel route to 10.10.10.10/24 through 1.1.1.1 metric 5 tunnel-zone. When the tunnel goes down, the tunnel route is removed from the table and the default route is used for the 10.10.10.10 network in the untrust zone. When the tunnel comes back up, it considers this a zone change and drops the packets incrementing the flow_fwd_zonechange counter.   Resolution 1 All sessions destined to the untrust zone when going to 10.10.10.10/24 need to be cleared and re-initiated. To avoid this zone change, create a dummy IP address (ex: loopback interface IP address 5.5.5.5) in the tunnel zone to make the routing table look like this: 0.0.0.0/0 metric 10 untrust zone. A tunnel route to 10.10.10.10/24 through 1.1.1.1 metric 5 tunnel-zone. Another tunnel route to 10.10.10.10/24 through 5.5.5.5 metric 10 tunnel-zone. This forces the traffic to use the route with metric 10 in the same tunnel zone when the primary tunnel route fails, and there is no zone change that occurs when the tunnel comes back up. Scenario 2 Packets designated to exit out an ingress interface is dropped by the Firewall with "flow_fwd_zonechange".     Resolution 2   In this case, the interface had a /32 (host) instead of /24 (network). Make sure that the interface is showing as a /24. For example 10.10.10.1/24.   owner: pvemuri
View full article
pvemuri ‎10-23-2018 12:33 PM
3,929 Views
0 Replies
  Overview The GlobalProtect Portal configuration allows the user to define whether the GlobalProtect user can "disable" the GlobalProtect agent on the local machine.   From the WebGUI, go to the Network > GlobalProtect > Portals > Client Configuration.     Symptom If the option is set to "disabled," you only allow user to click on the "Disable" option within the GlobalProtect agent. This configuration works fine on PC, MAC and Android platforms.   There is a restriction for this option on iOS devices (iPhone, iPad), which prevents it from working. This is the expected behavior and it is there due to a limitation on interacting with operating system. The user can always disable VPN connection from global Settings menu, regardless of the GlobalProtect configuration.   In GlobalProtect version 2.2 and above, there is one behavior change where the user can disconnect the VPN connection from the GlobalProtect client, but the subsequent traffic will re-initiate the connection if we set the mentioned option to "Disable." However, the user can still disable the VPN through system settings.   Workaround Create different proxy policies within .pac files that will be pushed to users: Create a URL hosting a .pac file, for example: http:// The <server_name> should resolve to a private IP within the corporate network (or when the client is connected to GlobalProtect Gateway) <server_name> should resolve to a public IP if the client is not within the corporate network (using public DNS servers, which are not pushed by the GlobalProtect Gateway) Depending on the DNS resolution, .pac file will be fetched from different servers and will provide a different configuration. Internally fetched .pac will tell the client to forward all http(s) requests directly to the Internet, and externally fetched .pac will force the client to redirect all traffic to a page, which is asking the user to enable GlobalProtect client VPN connection in order to have internet access. Aproxy configuration can be pushed to the clients using an MDM solution.   owner: nmarkovic
View full article
nimark ‎09-18-2018 11:27 AM
5,928 Views
0 Replies
1 Like
Issue PCI compliance scan failed for GlobalProtect IP address not using minimum version of TLS 1.2   Cause Running PAN-OS 6.1.4 and below, b y default the GlobalProtect Agent connects using TLS 1.0.   Resolution To resolve this, we have to configure a minimum version of TLS to be used to secure the connection between the GlobalProtect agent and the firewall.   Steps Go to Device > Certificate Management > SSL/TLS Service Profile > Create a new profile. Go to the GlobalProtect configuration under Network > GlobalProtect. Map the newly created SSL/TLS service profile to both the portal and the gateway configuration. Commit the configuration. Reconnect to the GlobalProtect from the client machine.    
View full article
rchougale ‎09-07-2018 01:15 AM
5,088 Views
3 Replies
Symptoms After deploying GlobalProtect with pre-logon enabled, clients running a bluecoat user agent (bcua) experience intermittent connectivity issues. A continous ping from the client to internal resources shows successful replies but after 40 - 50 seconds, the pings begin to time out. Connection will then get reestablished after a few minutes and the behavior will loop. Diagnosis The bcua creates a tunnel to Symantec Web Security Service (WSS) which means GP traffic is also tunneled. This causes intermittent connectivity.   This can be verified by running a packet capture on the client machine.   A few other ways to verify this is the case: Check the client's public IP address; you can do this by doing a google search of "whats my ip address" Verify if this is the IP address from the client's ISP or whether it belongs to Symantec. I used arin[dot]net to verify. If you get a Symantec IP address that would be an indication that a tunnel has been created to Symantec. On the firewall, run the following commands as shown in the screenshot:   Solution Symantec is aware of this issue and has provided a workaround in this link.  Once the changes have been made, verify the IP seen by the firewall. This should be a non-symantec IP and connectivity should now be stable.  
View full article
zmacharia_PA ‎07-30-2018 11:11 AM
1,707 Views
0 Replies
Symptoms When configuring an IPsec VPN between an AWS Virtual Private Gateway and a Palo Alto Networks device, you might get an error. If you are using the  longer format resource IDs  generated by AWS for Palo Alto Networks as the vendor, you might run into errors while editing the VPN and network settings.   This normally is caused by going into the AWS portal, and then going to "VPC > VPN Connections" and then select "Download Configuration". If the VPN gateway is using the longer format resource IDs, then PAN-OS will not accept some of the generated configuration lines. An error similar to the following will be reported. admin@PA-VM# edit network ike crypto-profiles ike-crypto-profiles ike-crypto-vpn-0901877fe35f95b23-0 ike-crypto-vpn-0901877fe35f95b23-0 should be less than or equal to 31 characters   Invalid syntax. Diagnosis The reason of the invalid syntax is because currently in PAN-OS the network profiles name field accept a max of 31 characters. and the IKE crypto profile name field in the generated configuration contains 34 characters after using the longer instance IDs. (for example ike-crypto-vpn-0901877fe35f95b23-0).   Starting June 2018, AWS will switch to use Longer Format Resource IDs for all AWS resources like VPC IDs. Solution To resolve this you need to manually modify the configuration file generated before copy/paste the configuration into a PAN-OS firewall. You should replace all the instance of the ike crypto profile name as the following example: current value: ike-crypto-vpn-0901877fe35f95b23-0 new value: vpn-0901877fe35f95b23-0 Removing the (ike-crypto-) from the name will make the total number of characters equal to 23. And it will be accepted by PAN-OS.   As of 15-Jun-2018, AWS has updated the VPN configuration generator for PAN-OS to shorten the value for ike-crypto-profiles to automatically create a shorter unique name of the format: vpn-0901877fe35f95b23-0  
View full article
melamin ‎07-03-2018 05:54 PM
2,243 Views
0 Replies
Overview This document is intended to provide a list of GlobalProtect CLI commands to help in troubleshooting sessions, users and statistics.   Details Below is a list of commands for “ > show global-protect-gateway ” that are currently available: (Each give specific information that will be valuable depending on what is being examined) Command Description current-satellite Show current GlobalProtect gateway satellites current-user Show current GlobalProtect gateway users flow Show dataplane GlobalProtect gateway tunnel information flow-site-to-site Show dataplane GlobalProtect site-to-site gateway tunnel information gateway Show list of GlobalProtect gateway configuration previous-satellite Show previous GlobalProtect gateway satellites previous-user Show previous user session for GlobalProtect gateway users statistics Show statistics of current GlobalProtect gateway users   Examples Below are some of the commands above and the output that can be expected: > show global-protect-gateway flow total tunnels configured:                                     1 filter - type GlobalProtect-Gateway, state any   total GlobalProtect-Gateway tunnel shown:                     1   id    name                  local-i/f         local-ip        tunnel-i/f ----------------------------------------------------------------------------------------------- 2     gp-gateway-N          ethernet1/3       10.30.6.26      tunnel.26     > show global-protect-gateway current-user GlobalProtect Gateway: gp-gateway (1 users) Tunnel Name          : gp-gateway-N         Domain-User Name          : :test         Computer                  : HOST17-WIN7-64         Client                    : Microsoft Windows 7 Enterprise Edition Service Pack 1, 64-bit         Private IP                : 172.16.148.1         Public IP                 : 10.30.6.83         ESP                       : removed         SSL                       : exist         Login Time                : Aug.12 17:12:34         Logout/Expiration         : Sep.11 17:12:34         TTL                       : 2591960         Inactivity TTL            : 10760     > show global-protect-gateway gateway GlobalProtect Gateway: gp-gateway (1 users) Tunnel Type          : remote user tunnel Tunnel Name          : gp-gateway-N         Tunnel ID                 : 2         Tunnel Interface          : tunnel.26         Encap Interface           : ethernet1/3         Inheritance From          :         Local Address             : 10.30.6.26         SSL Server Port           : 443         IPSec Encap               : no         HTTP Redirect             : no         UDP Port                  : 4501         Max Users                 : 0         IP Pool Ranges            : 172.16.148.1 - 172.16.148.254;         IP Pool index             : 0         Next IP                   : 172.16.148.2         DNS Servers               : 4.2.2.2                                   : 0.0.0.0         Access Routes             : 0.0.0.0/0;         VSYS                      : vsys1 (id 1)         SSL Server Cert           : iamportal         Auth Profile              : local         Client Cert Profile       :         Lifetime                  : 2592000 seconds         Idle Timeout              : 10800 seconds     owner: panagent
View full article
nrice ‎01-12-2018 04:01 AM
27,931 Views
3 Replies
1 Like
Issue When using a group in the "allow list" for the authentication profile that Global Protect uses, the login attempt fails with the following error: "Reason: User is not in allowlist"   However, the login works fine if the allow list is set to "all" in the authentication profile.   Resolution Confirm that the group you are using is in the include list in a Group Mapping configuration under Device > User Identification > Group Mapping Settings: Group Mapping Confirm that the group in question contains the user attempting to login. Run the CLI command: show user group name <value> For example: > show user group name pantac\vpn-user short name:  pantac\vpn-user source type: ldap source:      Pantac2003 [1     ] pantac\user1 [2     ] pantac\admin1 [3     ] pantac\administrator [4     ] pantac\user2 [5     ] pantac\user4 Confirm that the LDAP server profile used for your Group Mapping and your Global Protect authentication profile contain the Netbios domain name (short name) in the domain field. Do not use the DNS name for the domain (domainname.com) In most cases this is the same profile. This can also be left blank in many cases. The LDAP server profile is under Device > Server Profiles > LDAP In PAN-OS 7.0 and later, the domain section was moved to Device > User Identification > Group Mapping Settings :  User Domain   In PAN-OS 8.0 the User Domain can also be controlled in the Authentication Profile User Domain in the Authentication Profile Confirm that the group name in the allow list in the Global Protect authentication profile is listed with the long name of the group. This value can be pasted into this value from the output of the "show user group list" CLI command. Authentication Profile Allow List   owner: jteestel
View full article
jteetsel ‎11-20-2017 05:04 AM
91,636 Views
23 Replies
1 Like
Issue Inside of the WebGUI > Network> IPSec Tunnels, the IKE Gateway Status (Phase 1) light is red, whereas the IPSec Tunnel (Phase 2) light is green.  However, traffic still continues to flow through the tunnel properly.  After some time, the IKE Gateway Status light returns to green.  Is this normal? VPN Status showing Phase 1 down (Red) but Phase 2 up (Green)   Resolution This is normal behavior. The purpose of Phase 1 (IKE Gateway Status) is to set up a secure channel for subsequent Phase 2 (IPSEC Tunnel) security associations (SA). Once the Phase 2 security associations have been set up, traffic travels on Phase 2 SA. Hence, it is possible that Phase 1 might be down, but traffic across the tunnel still works (because Phase 2 is up). The IKE light will turn red when Phase 1 times out. After a certain period, when Phase 2 is about to timeout, Phase 1 will re-negotiate the encryption key for subsequent Phase 2 negotiations. After these fresh negotiations, the IKE light will turn back to green and this process continues.   This behavior can be seen in the system logs: System logs showing Phase 2 and Phase 1 renegotiating. Description of above events: 21:44:04:  Phase-1 SA timed out.  At this point the IKE Gateway Status light will become red.  Notice the Phase-1 renegotiations have not started right away. 21:45:38:  At this point, Phase-2 SA is about to timeout.  Hence, Phase-1 SA renegotiations started.  IKE Gateway Status light turns back to green. 21:45:38:  Subsequent Phase-2 renegotiations. 21:45:38:  Previous Phase-2 SA expires and is deleted.   See Also For more information on this situation, with more pics and a different explanation, please see: DotW: VPN IPSec Tunnel Status is Red   owner: akhan
View full article
nrice ‎11-17-2017 03:40 PM
27,508 Views
4 Replies
4 Likes
Overview When the GlobalProtect Client configuration is performed, use this information to verify that the correct Connection Method settings have being applied to the client, and that the client has retrieved the latest configuration.   Details User-Logon The client configuration under the GlobalProtect Portal appears as follows when the Connection Method is set to user-logon: Once the client is installed and connected, the options available under the File menu are as shown below: The 'Disconnect' option is grayed out and unavailable. For user-logon mode, the GlobalProtect client automatically establishes a connection after the user logs in to the host computer.   On-Demand The client configuration under the GlobalProtect Portal appears as follows when the Connection Method is set to on-demand: Once the client is installed and connected, the options available under the File menu are as shown below: As seen above, the Disconnect option for on-demand mode, because the user is required to explicitly initiate and end the connection.   owner: pvemuri
View full article
pvemuri ‎11-15-2017 12:30 PM
16,266 Views
0 Replies
We limit the number of entries to 64 for our GlobalProtect Client Settings configuration ( Network > GlobalProtect > Gateways > Agent > Client Settings ).   Notice how the "OK" button is disabled once you go over 65 entries :          This limitation applies to any PANOS in all of our appliances, including Hardware and VMs.    
View full article
SuperMario ‎11-09-2017 02:17 AM
7,901 Views
0 Replies
This document is intended to help troubleshoot IPSec VPN connectivity issues. It is divided into two parts, one for each Phase of an IPSec VPN.   Phase 1 To rule out ISP-related issues, try pinging the peer IP from the PA external interface. Ensure that pings are enabled on the peer's external interface. If pings have been blocked per security requirements, see if the other peer is responding to the main/aggressive mode messages, or the DPDs. Check for the responses of the "Are you there?" messages from the peer in the system logs under the Monitor tab or under ikemgr logs. Check that the IKE identity is configured correctly. Check that the policy is in place to permit IKE and IPSec applications. Usually this policy is not required if there is no clean-up rule configured on the box. If a clean-up rule is configured, the policy is configured usually from the external zone to the external zone. Check that proposals are correct. If incorrect, logs about the mismatch can be found under the system logs, or by using the following CLI command: >  less mp-log ikemgr.log Check that preshared key is correct. If incorrect, logs about the mismatch can be found under the system logs, or by using the following CLI command: >  less mp-log ikemgr.log Take packet captures to analyze the traffic. Use filters to narrow the scope of the captured traffic. Useful CLI commands: > show vpn ike-sa gateway <name> > test vpn ike-sa gateway <name> > debug ike stat Advanced CLI commands: For detailed logging, turn on the logging level to debug: > debug ike global on debug > less mp-log ikemgr.log To view the main/aggressive and quick mode negotiations, it is possible to turn on pcaps for capturing these negotiations. Messages 5 and 6 onwards in the main mode and all the packets in the quick mode have their data payload encrypted: > debug ike pcap on > view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap Turn off debugs > debug ike pcap off  Configuring packet filter and captures restricts pcaps only to the one worked on, debug IKE pcap on shows pcaps for all VPN traffic.   To check if NAT-T is enabled, packets will be on port 4500 instead of 500 from the 5th and 6th messages of main mode. Check if vendor id of the peer is supported on the Palo Alto Networks device and vice-versa.   Phase 2 Check if the firewalls are negotiating the tunnels, and ensure that 2 unidirectional SPIs exist: > show vpn ipsec-sa > show vpn ipsec-sa tunnel <tunnel.name> Check if proposals are correct. If incorrect, logs about the mismatch can be found under the system logs under the monitor tab, or by using the following command: >  less mp-log ikemgr.log Check if pfs is enabled on both ends. If incorrect, logs about the mismatch can be found under the system logs under the monitor tab, or by using the command: >  less mp-log ikemgr.log Check the proxy-id configuration. This is usually not required when the tunnel is between two Palo Alto Networks firewalls, but when the peer is from another vendor, IDs usually need to be configured. A mismatch would be indicated under the system logs, or by using the command: > less mp-log ikemgr.log Useful CLI commands: > show vpn flow name <tunnel.id/tunnel.name> > show vpn flow name <tunnel.id/tunnel.name> | match bytes Check if encapsulation and decapsulation bytes are increasing. If the firewall is passing traffic, then both values should be increasing. > show vpn flow name <tunnel.id/tunnel.name> | match bytes If encapsulation bytes are increasing and decapsulation is constant, then the firewall is sending  but not receiving packets. Check to see if a policy is dropping the traffic, or if a port translating device in front of PAN that might be dropping the ESP packets. > show vpn flow name <tunnel.id/tunnel.name> | match bytes   If decapsulation bytes are increasing and encapsulation is constant, then the firewall is receiving but not transmitting packets. Check to see if a policy is dropping the traffic: > test routing fib-lookup virtual-router default ip <destination IP> -------------------------------------------------- runtime route lookup -------------------------------------------------- virtual-router:  default destination:      10.5.1.1 result:          interface tunnel.1 >  show routing route > test vpn ipsec-sa tunnel <name> Advanced CLI commands: > debug ike global on debug > less mp-log ikemgr.log > debug ike pcap on > view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap > debug ike pcap off If tunnels are up but traffic is not passing through the tunnel: Check security policy and routing. Check for any devices upstream that perform port-and-address-translations. Because ESP is a layer 3 protocol, ESP packets do not have port numbers. When such devices receive ESP packets, there is a high possibility they may silently drop them, because they do not see the port numbers to translate. Apply debug packet filters, captures or logs, if necessary, to isolate the issue where the traffic is getting dropped.   owner: kprakash
View full article
kprakash ‎10-30-2017 12:54 PM
196,811 Views
16 Replies
9 Likes
Starting from PAN-OS 8.0, we can enable IPSec VPN specific debugs per peer.
View full article
mdumitriu ‎08-02-2017 09:29 AM
14,104 Views
0 Replies
2 Likes
Overview When it comes to authenticating users based on the user-groups, most of the deployments make use of LDAP authentication profile. This document describes the configuration that is required on the Palo Alto Networks firewall and sheds some light on how to pull the Palo Alto Networks User Group Attribute to ensure successful user-group based VPN authentication using secure RSA.   prerequisite: group information on the Palo Alto Networks firewall needs to be populated through an LDAP profile as described in this article: How to Configure Active Directory Server Profile for Group Mapping and Authentication before starting these configuration steps   Steps Go to Device > Server Profiles > RADIUS and add a RADIUS server. Go to Device > Authentication Profile and create a RADIUS authentication profile by referencing the RADIUS server profile created in Step 1. Shown in the above screenshot, see that although we have referenced the LDAP user groups in the allow list, we are making use of RADIUS server profile to relay the Authentication request to the RADIUS server. Please note that Authentication will NOT happen on the Palo Alto Networks firewall. Instead, it takes place on the RADIUS server. As a result, the RADIUS server should have the capability to pass the user-group information highlighted in the below screenshot, which is possible through "Palo Alto Networks Dictionary file".   Palo Alto Networks Dictionary installs on the RADIUS server and defines authentication attributes needed for communication between a Palo Alto Networks firewall and the RADIUS server.   See Also To download the dictionary file and for more information, reference the following link: RADIUS Dictionary   owner: tshivkumar
View full article
tshiv ‎06-30-2017 03:11 AM
6,835 Views
0 Replies
2 Likes
Symptom If your IPSEC VPN tunnel is showing green (up), and phase 1 and phase 2 have completed, but traffic is not flowing. This can be seen inside of Network > IPSec Tunnels.   Confirmation In order to confirm this is the issue, please run the CLI following command multiple times, once before and once after trying to send data across the VPN tunnel: > show counter global filter severity drop aspect tunnel category flow Please look for the following 2 values: flow_tunnel_decap_err flow_tunnel_ipsec_bad_length Cause If you see those 2 values increasing, then this might indicate an issue with the IPSec Phase 2 tunnel. Some firewalls may  not support newer ciphers (aes-256-gcm, etc) and may require older ciphers for proper functionality.   Resolution To resolve this issue, please check with your VPN peer, and verify the ciphers being used. It is possible that the Cipher you are using is not supported by the peer.  Once you have a list of the ciphers supported by the peer, verify the encryption ciphers you have selected by going into Network > Network Profiles > IPSec Crypto, select the profile used for this VPN per and add the supported ciphers. Commit and then test.  IPSec Crypto Profile window showing the supported ciphers. Note: If the profile is used by other IPSec VPN peers, and works, then we recommend creating a new Crypto Profile for any new ciphers that are needed.  
View full article
bennicholson ‎02-25-2017 10:06 AM
4,327 Views
0 Replies
Symptoms GlobalProtect app running on Android 6.0 or later cannot establish the VPN connection when:    The root CA certificate for GlobalProtect Portal/Gateway  is in Trusted Credentials on the Android device. And the GlobalProtect Portal/Gateway Certificate Common Name (CN) is IP address.   In this case, the following error message will be displayed : Cannot connect to GlobalProtect portal     Gp.log from GlobalProtect app shows the following errors: (6227)01/05 17:55:33:120201 - javax.net.ssl.SSLPeerUnverifiedException: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1] (6227)01/05 17:55:33:120352 - exception GetHttpResponse, response code is 0 (6227)01/05 17:55:33:120521 - response from server is: null, exception Message: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1] eType:javax.net.ssl.SSLPeerUnverifiedException: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1] (6227)01/05 17:55:33:120557 - (l5)JNI,6243,508,not handled, ret=error, javax.net.ssl.SSLPeerUnverifiedException: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1], return NULL now   Diagnosis This is due to a new behavior of Android 6.0+.   Starting from Android 6.0, if the CN is an IP address in a certificate, the IP address should also be in Subject Alternative Name(SAN) as iPAddress subAltName. If the IP address is missing from iPAddress subAltName, certification verification will fail.   For older Android versions, the certification verification will pass as long as the CN matches.       Solution Generate a certificate for GlobalProtect Portal/Gateway that have iPAddress subAltName field, and replace the existing certificates.   The following screen shot shows how to set iPAddress Subject Alternative Name on the Palo Alto Netrwork Next-Generation Firewall.   In generating a certificate, add "IP" Type and input the IP address as the Value in Certificate Attributes field:     The generated certificate shows IP Address value in  Subject Alternative Name Field :   Set this certificate for  GlobalProtect Portal/Gateway certificates.  After that, the VPN connection can be established.   Please see the following guide for deploying GlobalProtect Server Certificate:  Deploy Server Certificates to the GlobalProtect Components      Another available workaround is removing the CA certificate from the Android phone (Generally from "Setting > Security > Trusted credentials").   In this case, GlobalProtect app shows "Untrsuted Certificate" warning message once (as shown below), then the connection will be established.     This is not recommended generally because users should check destination Portal/Gateway validity manually.
View full article
dyamada ‎02-08-2017 09:20 AM
5,135 Views
0 Replies
1 Like
ISSUE: IPsec tunnel is not flapping or IPsec tunnel is up but not passing traffic.   CAUSE: One of the reasons for the tunnel flapping or not passing traffic is if the SPI number is not stable. A software bug may be the issue, lifetime for phase 1 and phase 2 are not the same so rekey is happening. Proxy ID are mismatching so rekey is happening frequently.   A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. SPI is arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet should be bound. The SPI is provided to map the incoming packet to an SA at the destination.   The SPI number can be checked on the firewall with the following command: show vpn ipsec-sa   The SPI number should remain stable until a tunnel renegotiates. If this number is changing, then the tunnel will not be stable.   EXAMPLE: In both screenshots, the SPI number is changing.     RESOLUTION: Check the lifetime of phase1 and phase2 -- the time should be the same. Check if the proxy ID are matching or not. The issue could be because of a software bug.
View full article
pankaku ‎01-03-2017 12:17 AM
3,632 Views
1 Reply
Symptom When an interface acquires its IP address dynamically, such as with dynamic-PPPoE, that interface can be selected as the IPSec Gateway. Even if the interface is selected, though, the IP address remains "None" because it is not possible to select the IP address.     Cause The configuration process selects the interface and leaves the IP address set to none. The dataplane automatically uses the dynamically assigned IP address. The IP address cannot be selected because that would lock the configuration to reference a specific IP value. If the interface receives a new IP address during the next PPPoE negotiation, the configuration will become invalid and the VPN tunnel will break.   owner: sgantait
View full article
HULK ‎12-07-2016 01:23 AM
8,326 Views
4 Replies
1 Like
Question An IPSec tunnel is configured between two firewalls and it is up and running. To  test, the physical interface is brought down or the LAN cable is unplugged. But, this does not bring the IPSec tunnel down, even if DPD is enabled and the time taken to bring the tunnel down is too long. Answer This is expected behavior. Both the CLI and GUI will show the status of tunnel as up, even when the physical interface is down or unplugged and the tunnel flow status will show as established.   The are only two ways an IPSec tunnel can be bought down: Tunnel monitoring IPSec Re-keying   T he status of the tunnel is tied to tunnel monitoring and IPSec Re-Keying. Although this should not cause an issue between route based VPNs, this could cause an issue if the peer is policy based VPN.   Workaround As a workaround, configure a tunnel monitoring profile. When a tunnel monitoring is configured, an IP will have to be assigned to the tunnel interface and should be included in the proxy ID list.   Once tunnel monitoring is configured, if the monitor IP is unreachable, the tunnel monitor should immediatly bring down the tunnel interface. And, this would in turn end up clearing the IPSec tunnels built over that physical interface.
View full article
shganesh ‎11-09-2016 10:32 AM
2,535 Views
0 Replies
The following table provides a list of valuable resources on understanding and configuring IPSec and Tunneling: Title Description Type Basic How to configure IPSec VPN Configure IPSec VPN Document Configuring the Palo Alto Networks device as an IPSec Configure Palo Alto Networks device as an IPSec Document IPSec crypto options Options for IPSec crypto Document Why is GlobalProtect slower on SSL VPN compared to IPSec VPN? GlobalProtect slower on SSL VPN compared to IPSec VPN Document How to improve performance for IPSec traffic Improve performance for IPSec traffic Document NAT traversal in an IPSec gateway  NAT traversal in an IPSec gateway Document Config guidelines when terminating IPSec VPN tunnels on the firewall Configuration guidelines Document Sample IPSec tunnel configuration - Palo Alto Networks firewall to Cisco ASA Sample IPSec tunnel configuration Document The IPSEC tunnel comes up but hosts behind peer are not reachable  IPSec tunnel troubleshooting Document IPSec VPN with peer ID set to FQDN IPSec VPN with peer ID set to FQDN   Document What encryption is used when enabling IPSec for GlobalProtect? Encryption used when enabling IPSec for GlobalProtect Document How to create an IPSec tunnel that is a responder (not initiator) Create an IPSec tunnel that is a responder Document Intermediate                       IPSec tunnel details Troubleshooting IPSec tunnels Document Differences between IPSec and LSVPN tunnel monitoring The differences between the normal IPSec/LSVPN tunnel monitoring Document IPSec traffic being discarded IPSec traffic troubleshooting Document How to verify if IPSec tunnel monitoring is working Verify if IPSec tunnel monitoring is working Document IPSec VPN error: IKE phase-2 negotiation failed as initiator, quick mode IPSec VPN error troubleshooting Document IPSec interoperability between Palo Alto Network firewalls and Cisco ASA IPSec interoperability between Palo Alto Networks firewalls and Cisco ASA firewall series Document How to configure dynamic routing over IPSec against Cisco routers Configure dynamic routing over IPSec against Cisco routers Document Configuring route based IPSec with overlapping networks Configure route-based IPSec Document IPSec with overlapping subnet IPSec with overlapping subnet Document GlobalProtect configuration for the IPSec client on Apple iOS devices GlobalProtect configuration for the IPSec client on Apple iOS Document Site-to-site VPN between Palo Alto Networks firewall and Cisco router is unstable or intermittent Site-to-site VPN between Palo Alto Networks firewall and Cisco router Document Configuring captive portal for users over site-to-site IPSec VPN Configure captive portal for users Document IPSec VPN IKE phase 1 is down but tunnel is active IPSec troubleshooting Document Tips for configuring a Juniper SRX IPSec VPN tunnel to a Palo Alto Networks firewall Configuring a Juniper SRX IPSec VPN tunnel to a Palo Alto Networks firewall Document Dynamic IPSec site-to-site between Cisco ASA and Palo Alto Networks firewall IPSec site-to-site between Cisco ASA and Palo Alto Networks Document IPSec site-to-site between Palo Alto Networks firewall and Cisco with NAT device IPSec site-to-site between Palo Alto Networks and Cisco with NAT device Document How does the firewall handle diffserv headers in an IPSec tunnel? Diffserv headers in an IPSec Tunnel Document IP phone switch not working through IPSec tunnel IPSec tunnel not working with IP phone switch Document Advanced                  IPSec tunnel is up and packet is getting dropped with wrong SPI counter increase Packet is getting dropped with wrong SPI counter increase Document Configuring route-based IPSec using OSPF Configuring route-based IPSec Document IPSec error: IKE phase-1 negotiation is failed as initiator, main mode due to negotiation timeout IPSec troubleshooting Document Site-to-site IPSec excessive rekeying on only one tunnel on system logs IPSec troubleshooting Document CLI commands to status, clear, restore and monitor an IPSec VPN tunnel IPSec CLI commands Document What do the port numbers in an IPSec-ESP session represent? IPSec-ESP session Document Configuring IPSec VPN between PAN-OS and CheckPoint Edge / Safe@Office IPSec VPN between PAN-OS and CheckPoint Document Configuring site-to-site IPSec VPN in layer 2 Configuring site-to-site IPSec VPN in Layer 2 Document Site-to-site IPSec VPN between Palo Alto Networks firewall and Cisco router using VTI not passing traffic IPSec troubleshooting Document Configuring IKEv2 VPN for Microsoft Azure Environment Configuring IKEv2 VPN for Microsoft Azure Document  
View full article
‎09-14-2016 04:07 AM
85,872 Views
0 Replies
6 Likes
IKEv2 has been introduced in PAN-OS 7.0. With this version of IKE, it is able to do a liveness check through phase 1 SA if there is any problem with underlying network connectivity (for example, physical interface is connected). This option is not enabled by default.        The default interval of liveness checking is every 5 seconds when SA is idle. Upon losing connection, the firewall will do 10 liveness retries with increasing timeout (seconds) for each retry as follows:   1 + 2 + 4 + 8 + 16 + 32 + 64 + 64 + 64 + 64 = 319 seconds (about 5 minutes)   After maxium retries are reached, the firewall will tear down phase 1 and phase 2 (child) SAs. Currently, the number of retries and wait time between each retry are not configurable in PAN-OS 7.0.      Please note that the associated interface tunnel status, however, will remain up and as any static routing egress to this interface tunnel will also stay active. Therefore, in order to failover traffic to a backup path requires additional an function such as phase 2 tunnel-monitoring, policy-based forwarding, or a dynamic routing protocol such as BGP or OSPF.     Output from show command:   > show vpn ike-sa detail gateway [IKE GW name]   IKE Gateway GW, ID 35 2.2.2.2 => 1.1.1.1 Current time: Mar.01 13:49:56 IKE SA: SPI: 8669654AB024E4AE:CABD66D702C02131 Init State: Established SN: 4 Authentication: PSK, peer PSK Proposal: AES256-CBC/SHA256/DH5 ID local: ipaddr:2.2.2.2 remote: ipaddr:1.1.1.1 ID_i: IPv4_address:2.2.2.2 ID_r: IPv4_address:1.1.1.1 NAT: Not detected Message ID: rx 35, tx 37 Liveness check: sending informational packet after idle 5 seconds       Output from ikemgr.log when IKEv2 liveness detects a connectivity problem:    2016-03-01 14:27:06.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 1 limit 10 2016-03-01 14:27:08.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 2 limit 10 2016-03-01 14:27:12.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 3 limit 10 2016-03-01 14:27:20.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 4 limit 10 2016-03-01 14:27:36.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 5 limit 10 2016-03-01 14:28:08.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 6 limit 10 2016-03-01 14:29:12.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 7 limit 10 2016-03-01 14:30:16.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 8 limit 10 2016-03-01 14:31:20.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): IKEv2 transmit {GW:6-I}: child id 150, retry cnt 9 limit 10 2016-03-01 14:32:24 [PROTO_ERR]: ikev2.c:1005:ikev2_timeout(): 6:1.1.1.1[500] - 2.2.2.2[500]:(nil):retransmission count exceeded the limit   2016-03-01 14:32:24 [INFO]: ike_sa.c:275:ikev2_abort(): 6:1.1.1.1[500] - 2.2.2.2[500]:(nil):aborting IKEv2 SA GW:6 2016-03-01 14:32:24.890 +0800 debug: pan_ikev2_debug(protocols/ikev2/ikev2.c:6946): ... IKEv2 SA state {GW:6-I}: SA dying from state ESTABLISHED, caller ikev2_abort 2016-03-01 14:32:24 [DEBUG]: ikev2.c:1174:ikev2_set_state(): 6:1.1.1.1[500] - 2.2.2.2[500]:(nil):ike_sa 0x827b210 state ESTABLISHED -> DYING: func ikev2_set_state, caller ikev2_set_sa_dying 2016-03-01 14:32:24.890 +0800 debug: ikev2_set_state(protocols/ikev2/ikev2.c:1239): keeping retransmit while state changed to DYING, CID 150, child 0x827b210     For information on IKEv1 DPD and how to enable Phase 2 Tunnel Monitor, please see Dead Peer Detection and Tunnel Monitoring   For information on IKEv2 support for VPN tunnels and how to configure, please see PAN-OS 7.0 ikev2-support-for-vpn-tunnels        
View full article
spiromruen ‎09-14-2016 04:05 AM
5,386 Views
0 Replies
1 Like
Issue A site-to-site IPSec VPN  between a Palo Alto Networks firewall and a firewall from a different vendor is configured. Phase 1 succeeds, but Phase 2 negotiation fails.   A look at the ikemgr.log with the CLI command: > tail follow yes mp-log ikemgr.log   shows the following errors: ( description contains 'IKE protocol notification message received: INVALID-ID-INFORMATION (18).' ) and IKE phase-2 negotiation is failed as initiator, quick mode. Failed SA: 216.204.241.93[500]-216.203.80.108[500] message id:0x43D098BB. Due to negotiation timeout     Cause The most common phase-2 failure is due to Proxy ID mismatch.   Resolution To resolve Proxy ID mismatch, please try the following: Check the Proxy ID settings on the Palo Alto Networks firewall and the firewall on the other side. Note: Proxy ID for other firewall vendors may be referred to as the Access List or Access Control List (ACL). Also, check the IPSec crypto to ensure that the proposals match on both sides.   See Also For more info on IPSec, please see the: IPSec and tunneling - resource list   owner: vvasilasco
View full article
vvasilasco ‎09-08-2016 08:18 AM
109,314 Views
12 Replies
3 Likes
Overview This document is intended to help improve performance for IPSec traffic.    Details Traffic to be tunneled will generally add 36 bytes to the original size of the packet because of the ESP header. One thing to keep in mind, depending on the encryption algorithm used,  the ESP header may vary in size.  Note: If the MTU on a device is hard set using this info (36 bytes) it is possible for the tunnel to fail and break any path MTU algorithm. Which is why we recommend the resolution below.   Cause For example, if the original packet size is greater than 1464 bytes, the resulting tunneled packet ends up to be larger than 1500 bytes, causing slowness and sluggishness between IPSEC peers because if packet fragmentation.   Resolution Enabling the option "Adjust TCP MSS" to automatically adjust MSS on the interface terminating the tunnel will resolve that issue by adjusting the MTU to compensate for the extra encapsulation.   owner: kadak  
View full article
kadak ‎08-10-2016 11:28 AM
19,713 Views
5 Replies
1 Like
This will provide steps required in order to HIP Match HIP objects containing Mac OS plists and/or processes. Keep in mind the main caveats in that the MAC GP client can only check 'application' plists from either /Library/Preferences or ~/Library/Preferences where ~ is the current user's home directory. Also, the GP MAC client can only check the "String" or "Number" type values within the application plist. In addition, when defining the plist for MACs, please do not specify the full path.   As noted in this example, to check ~/Library/Preferences/com.apple.finder.plist, you'll simply need to specify "com.apple.finder." The GP MAC client will append ".plist" and first check whether the file "com.apple.finder.plist" exists in /Library/Preferences. If the file, however, does not exist in the system preference folder (i.e. /Library/Preferences), the GP client will call OSX API to enumerate the application plist which includes those plist files under user's ~/Library/Preferences folder. Admins cannot just specify arbitrary plist files similar to "/Users/user1/Library/Safari/Bookmarks.plist." This is a current limitation of the GP client for MACs related to the plist.     Test bed utilized the following:   Mac OS 10.8.5 GP 2.0.2-7 PANOS 5.0.6   Step 1   Create the HIP Object specifying the plist/process. In this example, I'm using the application plist called 'com.apple.finder.' I used xcode to obtain the Key ("GoToField" and Value ("~/Library/Preferences) for the plist respectively.     However, in testing this out, we'll need to utilize what the Host is actually extrapolating as shown in the second screen shot. The MAC GP client is reporting '/Users/user1/Library/Preferences' value which is missing the '/' after Preferences. This is what we'll configure on the HIP Object as a result.      
View full article
gswcowboy ‎07-25-2016 12:46 PM
2,032 Views
0 Replies
Issue In some situations, remote VPN users connect to their corporate headquarters to access the Enterprise Resource Planning (ERP) database server. The ERP server needs to know the IP address of the users for configuring the file host in the server, this allows the users to synchronize the database with ERP servers and vice versa. Commonly, when a user connects to a corporate network through GlobalProtect, a random IP address will be assigned to them from the IP Pool configured under Gateway > Client Configuration > Network Settings.   As shown in the example, users can randomly be assigned to IP addresses from 10.66.100.1-10.66.100.254.   Resolution For remote users to synchronize to their corporate ERP server, preferred IP addresses can be pre-populated on user machines by changing the registry key under: HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\PanGPS\PreferredIP Enter the Registry Editor through Run: Under Palo Alto Networks > GlobalProtect > PanGPS > double click on PreferredIP and change it to the desired IP and click OK:   Note: Reboot the device in order to apply changes.   For more information on the ERP server, reference the following link: http://www.ehow.com/facts_6904009_erp-server_.html   owner: kadak
View full article
kadak ‎07-01-2016 12:08 PM
5,868 Views
1 Reply
Symptoms This error is usually seen when the GlobalProtect client is upgraded or GlobalProtect is not installed correctly. Diagnosis Solution Please follow these steps.   Disable WMI services : run - services.msc - Windows Management Instrumentation(WMI) - stop the service. Delete the files under  C:\Windows\System32\wbem\Repository Open regedit Go to HKEY_LOCAL_MACHINE > Software and HKEY_CURRENT_USER > Software.  Delete the Palo Alto Networks folder. Delete the same if the same folder is present in any other user under HKEY_USERS. Un-install GlobalProtect from Windows 'program and features'. Make sure that the virtual adapter in not present in the Network adapter settings. Reboot the machine. Reinstall GlobalProtect with admin privileges. Confirm that WMI service is running. This should resolve the issue.
View full article
rchougale ‎06-22-2016 03:14 PM
36,774 Views
5 Replies
Symptoms Is there a way to generate SNMP traps or generate some type of notification if a VPN tunnel goes down?   Diagnosis A tunnel monitor was set up to monitor IPsec VPN Tunnels on the between PA device and want to generate an alert if the tunnel goes down. At this point in time PA devices do not support VPN tunnel monitoring events through SNMP MIB's. Solution   As a workaround we can rely on Syslog server and the logs we send to it.  Steps: Configure Tunnel Monitor feature on the firewall. Configure syslog server.  Configure Device > Log Setting > System to send logs to Syslog server.  When tunnel monitor fails firewall generates the following message in the system log:  Time Severity Subtype Object EventID ID Description ============================== ============================== =================== 2015/11 /15 13:24:34 low vpn <object name> tunnel- 0 Tunnel <tunnel name> is down   Syslog server receives "tunnel down" message  After IPSec tunnel is brought up tunnel interface also goes up and a new message "tunnel is UP" is generated in system logs  Newly generated log is sent to the Syslog server.   See also: Dead Peer Detection and Tunnel Monitoring How to Verify if IPSec Tunnel Monitoring is Working How to Forward System Logs to Syslog Server
View full article
crajariyap ‎04-25-2016 07:12 PM
4,571 Views
0 Replies
Overview PBF (Policy Based Forwarding) Monitoring or Tunnel Monitoring sustains uninterrupted connectivity through the configured PBF path or tunnel. For this to be accomplished, ping packets are sent to a configured remote IP to determine if the path is still usable for the desired communication.   Details For the monitoring to work properly, select a remote IP address reachable through the PBF path or configured tunnel. This IP address can be any monitored IP address in the configured remote network or the IP address: On the remote end of the tunnel. Of the next hop.   Note: The ping packets are sourced from the local tunnel interface (for tunnel monitoring), or the interface configured as the egress interface (for PBF monitoring). Generally, tunnel monitoring is used from a Palo Alto Networks firewall to another Palo Alto Networks firewall. If using Palo Alto Networks tunnel monitoring to a non Palo Alto Networks firewall, additional requirements must be met for tunnel monitoring to work with the tunnel monitoring configuration on the Palo Alto Networks firewall. Be sure the following are in place: A policy permitting pings from the Palo Alto Networks firewall tunnel's IP address to the other device. Configured proxy IDs for the monitored traffic on both devices: On the Palo Alto Networks firewall, the local ID is the tunnel's IP, and the remote IP is either the other device's tunnel IP address or the IP address of a node behind the other device (whichever is being monitored). The Proxy IDs on the other device must be a mirror image of what has been specified under the Palo Alto Networks firewall.   If you're using any monitored IP address on the remote network, the local tunnel/egress address does not need to be in the same subnet as the monitored address. Monitoring will still work as long as the monitored device is configured to respond to pings and is reachable through the tunnel or PBF.   Also look at this article in which PBF monitoring through tunnel does not work due to overlapping subnets: PBF Rule is not Working When PBF Monitoring is Enabled for the IPAcross the Tunnel   owner: tasonibare
View full article
tasonibare ‎03-21-2016 07:23 AM
12,417 Views
0 Replies
3 Likes
Overview The NCP Secure Entry Client is an IPsec-compliant third-party application that can be used to establish a connection to a GlobalProtect Gateway using either a PSK or certificates with XAUTH. Versions are currently available for Windows, Mac OS X, and Android operating systems. The instructions below pertain to the Windows client and assume that the GlobalProtect Gateway has already been configured on the Palo Alto Networks firewall. Otherwise, refer to How to Configure GlobalProtect.   Steps Open the NCP Secure Entry Client and go to Configuration > Profiles. Click the Add / Import button. Choose the Connection Type. Select Link to Corporate Network Using IPsec. Choose the Profile Name. Enter an alphanumeric name for the connection profile. Choose the Communication Medium. Select the proper Communication Media depending on how the client connects to the internet. The two most common options are LAN (over IP) for Ethernet and Wi-Fi for wireless connections. The NCP client will automatically select the connection media if automatic media detection is selected. Set the VPN Gateway Parameters. Gateway (Tunnel Endpoint): the DNS name or IP address of the GlobalProtect Gateway configured on the Palo Alto Networks firewall. Check the Extended Authentication (XAUTH) box. Enter a User ID and Password that can be authenticated by the Palo Alto Networks firewall. Note: The gateway address 1.1.1.1 is not active and used only as an example. IPsec Configuration. Exchange Mode. For PSK authentication, select aggressive mode (IKEv1). For certificate authentication, select main mode (IKEv1). PFS Group: none PSK configuration is shown above. For certificate authentication, select main mode (IKEv1). Pre-shared Key Local Identity (IKE): For PSK authentication: Type: select Free string used to identify groups. ID: enter the Group Name configured under Network > GlobalProtect Gateways > Client Configuration on the Palo Alto Networks firewall. For certificate authentication: Type: select ASN1 Distinguished Name. ID: leave this field blank. Pre-shared Key (required for PSK authentication only): Shared Secret: enter the Group Password configured under Network > GlobalProtect Gateways > Client Configuration on the Palo Alto Networks firewall. The configuration for PSK authentication is shown below. GlobalProtect Gateway Client Configuration (7.0.1 firmware). Settings for PSK authentication are highlighted. When using certificates, the highlighted fields should be left blank. here is the The configuration for certificate authentication. Configure the IP Addresses IP Address Assignment: select IKE Config Mode. Don't modify the DNS Server or WINS Server fields. Set up the Firewall. Select the desired Stateful Inspection setting and click the Finish button. If using PSK authentication, the configuration is complete and you should be able to connect to GlobalProtect Gateway. If you are using certificate authentication, continue with the instructions below. Export the root and client certificate from Device > Certificate Management > Certificates on the Palo Alto Networks firewall. Note: This step is not necessary if an external CA is used, but the root certificate must be DER encoded and the client certificate must be in the PKCS#12 format. Export the root certificate in the Binary Encoded Certificate (DER) format. . Export the client certificate in the Encrypted Private Key and Certificate (PKCS12) format. The NCP client will prompt for the Passphrase before connecting to the VPN. In the NCP client, go to Configuration > Certificates. Click the Add button. User Certificate Name : enter a name for the certificate configuration. Certificate: select from PKCS#12 file. PCKS#12 Filename: browse to the client certificate exported from the Palo Alto Networks firewall. (optional) Check the PIN Request at each Connection box if you want the user to enter the client certificate Passphrase before every connection attempt. Click the OK button. 15. In the NCP client, go to Configuration > Profiles, select the previously configured profile, and click the Edit button. 16. Profile Settings In the left menu, select Identities. Certificate Configuration: select the certificate configuration you created earlier. Click the OK button. 17. Move the exported root certificate into the NCP > SecureClient > CaCerts directory. The default installation path is C:\Program Files (x86)\NCP\SecureClient\CaCerts. You should now be able to use the NCP client to connect to the GlobalProtect Gateway using certificates and XAUTH.        
View full article
nanderson ‎01-18-2016 07:28 AM
30,367 Views
0 Replies
AD Group Policy Overview   Active Directory Group Policy allows you to manage your network from on high, governing how your users and computers operate within your AD environment. Policy settings can be created to target the logged-in user or the computer, and a variety of settings that can be configured, including software installation.   To apply policy settings to users and computers in your AD environment you must first configure a Group Policy Object (GPO), which resides in a special folder called “Group Policy Objects” within the AD domain. A GPO is a named collection of configured policy settings.   The policy settings in the GPO aren’t enforced until the GPO is linked to an AD site, domain or organizational unit (OU).   Once the GPO is associated with one of these, the policy settings take effect for the users and computers defined within that container. If the GPO is linked at the domain level, the policy settings apply to the workstations and servers within the domain. If it is linked instead to the Marketing OU, for example, the settings apply only to computers inside that OU.   GPOs can be linked in multiple places such as two different OUs, and a site, domain or OU can have multiple GPOs linked to it.   Group Policy works from the “outside in”, first processing any local policies, then applying the site, domain and subsequent OU GPOs and working its way toward the object’s position in the AD tree. If any policy settings conflict along the way, the last setting applied rules.  Similarly, policy settings applied to user logons do the same, following the path to the user object’s resting place in the AD tree.  AD will override policies set on the individual computer.   Group Policy is a “pull” technology. When a windows client system starts up and is connected to the network it will pull the policy and then poll the domain for GPO changes every 90 to 120 minutes by default. There are intervals for computer and user policy and both have a default offset of up to 30 minutes.   GlobalProtect and GPO   The GlobalProtect client can be installed as either a computer or user policy. Use the Computer Policy to ensure that it is installed on specific systems regardless of the user. Use the User Policy to ensure that specific users receive the client on all systems that they use. Create and Link the GPO   You can use the Group Policy Management MMC (Microsoft Management Console) to create and link the GPO.   Server 2003: Path: Active Directory Users and Computers > your domain> Properties > Group Policy Server 2008: Path: Administrative Tools > Group Policy Management > Forest > Domain > your domain > Group Policy Objects The GPO begins with no settings. Edit the GPO and create a package Path: Computer Configuration > Policies > Software Settings > Software Installation   Assigning the MSI: Make sure the Global Protect client .msi file is in a location reachable on your network by Windows client computers. Clients will download the file from the location selected here. Assigned applications will be installed. Published applications will be available to the user through the Add/Remove programs interface.   owner: panagent
View full article
nrice ‎12-26-2015 10:44 AM
10,143 Views
1 Reply
1 Like
Ask Questions Get Answers Join the Live Community