Configuration Articles

Featured Article
Issue After un-installing the GlobalProtect client and trying to install a new client the following message appears: "An instance of GlobalProtect is already present on the system. Uninstall the current version before attempting to install the new version of GlobalProtect" Resolution Remove the registry items within the following registry path (Windows OS): HKEY_LOCAL_MACHINE\Software\Palo Alto Networks\ GlobalProtect \PanGPS Run the following command as an administrator from the windows cmd line: sc delete PanGPS Reboot the machine. This will completely remove the GlobalProtect client from the machine and will allow users to install the new client without any issues. owner: shasnain
View full article
shasnain ‎10-16-2014 05:26 PM
34,573 Views
0 Replies
2 Likes
Steps To allow GlobalProtect Agent Upgrades to only specific users, a separate 'client configuration' needs to be configured under the GlobalProtect Portal. Follow the steps below: Go to Network > GlobalProtect > Portals > Client Configuration and Click Add, add a profile for the desired group of users In this example, 'support users' are allowed to upgrade and the upgrade is disabled for 'corp users': Under Agent Configs > Agent Upgrade, select 'disabled' from the drop down menu within the client configuration for 'corp users':        Create a separate profile for support users and select the 'transparent' option for Agent Upgrade and click OK. owner:  ukhapre
View full article
ukhapre ‎07-22-2014 05:24 PM
2,814 Views
0 Replies
Overview This document describes the configuration steps that will restrict GlobalProtect access for only certified devices. Details This will prevent GlobalProtect users from using unknown devices. The following is a list of requirements that will ensure that the appropriate Windows, Mac OS X, iOS, and Android devices can establish a VPN with GlobalProtect: The Palo Alto Networks firewall’s SSL certificate must have a fully qualified domain-name that resolves to the IP address of the GlobalProtect Portal and Gateway to satisfy Apple iOS requirements. (The user can specify an IP address in the Common Name field if iOS is not included in the list of supported devices). This certificate will be used to sign a machine certificate The portal will not distribute this certificate The GlobalProtect Portal and Gateway will use the firewall's SSL certificate, which then requires a device to present the issued machine certificate for verification. The machine certificate certifies the device. A user must still properly authenticate in order to establish the tunnel. Go to Device > Certificate Management > Certificates This is the firewall’s primary SSL certificate. When this certificate was created, the fully qualified domain-name was entered in the Common Name field and the Certificate Authority box was checked. It is necessary that a FQDN is presented by the firewall when an iOS device connects to it. The certificate shown below has been selected for other functions, but for this topic, it is going to be used to sign the machine certificate. Create Machine Certificate Go to Device > Certificate Management > Certificates, click Generate to create a new certificate. This is the machine certificate that will be provided to all devices that can use it for GlobalProtect. Notice this certificate is signed by the previously illustrated CA certificate.  Any title or information can be entered under Certificate Name and Common Name fields. Below is an example of what the Certificate Information would look like viewing it after it has been created: Export Machine Certificate Select the PKCS12 file format and enter a password to encrypt this key. This certificate needs to be installed on a device before it first attempts a GlobalProtect connection: Create Certificate Profile The firewall's SSL certificate needs to be added to a Certificate Profile so that the profile can be specified in the GlobalProtect Gateway: Go to Device > GlobalProtect > Gateway and specify certificates for the Gateway. The firewall's SSL certificate is selected for the Server Certificate field, as shown below: Go to Device > GlobalProtect > Portal > Portal Configuration The Client Certificate field is used to distribute the machine certificate to a GlobalProtect platform, which means that any user who authenticates successfully from any device would receive this certificate. Leave this blank to prevent this from happening. The Certificate Profile field is used to specify the CA certificate that signs the certificate that the device must present when one goes to the GlobalProtect client software download page on the firewall. The GlobalProtect agent will also present a machine certificate when it connects to the Portal to retrieve updates. The user may want use the certificate profile created earlier once they have this setup working. Go to Device > GlobalProtect > Portal > Client Configuration In the Portal dialogue window, select Client Configuration and then open a configuration profile that is listed there. The following dialogue window is displayed. The Client Certificate field specifies the certificate that the GlobalProtect must present to the Gateway to certify the connecting device. This certificate needs to be signed by the Server Certificate that the Gateway is using. This is the same certificate that was exported in the PKCS12 format in the Export Machine Certificate section above. Once these settings have been committed, a user that authenticates successfully may only do so from a device that has the required machine certificate. owner: jjosephs
View full article
jjosephs ‎07-13-2014 05:34 PM
15,790 Views
1 Reply
1 Like
Overview On a GP-100, it's possible to configure Scheduled Backup Export. With this export schedule, the following logs/configuration can be backed up: GP-100 device state GP-100 HIP match logs GP-100 MDM logs Steps Go to Setup > Scheduled Backup Export : Click Add to configure a new export schedule: owner: rvanderveken
View full article
rvanderveken ‎06-20-2014 02:52 AM
9,052 Views
1 Reply
Palo Alto Networks does not support Two-Factor authentication for third party VPN clients (for example, Cisco VPN client). However, it is supported for GlobalProtect clients. owner: rvanderveken
View full article
rvanderveken ‎05-22-2014 06:13 AM
7,559 Views
3 Replies
Overview The GlobalProtect configuration has the ability to authenticate users based on username/password, or on certificates. When using certificates to connect, it is a valuable benefit to use an OCSP server to check for revocation status of the certificate, so that the users are denied access if the certificate is revoked. This setup is beneficial when it is used for consultants, as they are allowed access to some projects for a period of time and than the access is revoked. Details Palo Alto Networks devices have the option to generate certificates for these types of users, and if the OCSP responder is configured on the device it allows the capability to revoke access, if needed. Because of this scenario, an OCSP responder is needed on the Palo Alto Networks firewall. To setup the OCSP go to, Device > Certificate Management > OCSP Responder and click Add. Enter a name for the OCSP Responder and use the IP address of the firewall as the the Host Name. As soon as the OCSP Responder is configured and committed, it is now possible to generate certificates on the firewall that are using the OCSP Responder to check the revocation status. To create certificates go to Device > Certificate Management > Certificates and click Generate. While creating new certificates be sure to use the OCSP Responder that is filed. This allows the connections that are authenticated initiated from the user, and holds the certificates that are checked with the OCSP server. To create a Certificate Profile for the VPN users, which will be verifying the revocation status with the OCSP, go to Device > Certificate Management > Certificate Profile. Specify the parameters for the username (in this case is the subject), the CA that signs the certificates and the OCSP URL. Note: Make sure to enable the usage of OCSP, CRL can also be enabled, but be aware that the OCSP will have precedence, because it is more reliable than the CRL. In the GlobalProtect Portal configuration the user authentication should be performed based on the Client Certificate Profile. To setup go to Network > GlobalProtect > Portals, click Add and select Portal Configuration: To perform the same steps for the GlobalProtect Gateway, go to Network > GlobalProtect, click Add and select the General tab as shown below: The users can login using certificates, which are validated using the OCSP. If access for user is no longer needed, revoke the certificate. To revoke the certificate, go to Device > Certificate Management > Certificates and select the certificate, click on the Revoke button. After the revoke, the status of the certificate will change from green "valid" to red "revoked" as shown in the example below: From the CLI, check the revocation status of the issued certificate for the specific OCSP (or for all) by using the command below: > debug sslmgr view ocsp all Current time is: Thu Apr 3 21:49:46 2014 Count Serial Number(HEX) Status      Next Update               Revocation Time Reason         Issuer Name  Hash   OCSP Responder URL ----  ------------------ --------    ------------------------  ------------------------  -----------  ----------------------- [ 1]  10                 revoked     Apr 04 21:41:39 2014 GMT  Apr 03 21:44:54 2014 GMT  7ccb1b43     http://10.193.17.2/CA/ocsp [ 2]  0D                 valid       Apr 03 22:41:39 2014 GM                             df89db2d     http://10.193.17.2/CA/ocsp When a user tries to login with a revoked certificate the firewall will check with the OCSP and deny access. This can be verified by the sslmgr.log, see the examples below: 2014-04-03 23:47:41.537 +0200 debug: sslmgr_check_status(sslmgr_main.c:655): [0] start checking OCSP, status for certificate chain, num: 3; block unknown: no; from DP: yes 2014-04-03 23:47:41.537 +0200 [OCSP] URL http://10.193.17.2/CA/ocsp  serialno: 0D 2014-04-03 23:47:41.538 +0200 [OCSP] URL http://10.193.17.2/CA/ocsp  serialno: 10 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 2, URI: (null) 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2000): [0] No AIA URL, skip checking OCSP for depth 2. 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 1, URI: http://10.193.17.2/CA/ocsp 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2045): [0] OCSP check result is 'valid' for level 1 per cache 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 0, URI: http://10.193.17.2/CA/ocsp 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2045): [0] OCSP check result is 'revoked' for level 0 per cache 2014-04-03 23:47:41.538 +0200 debug: sslmgr_check_status(sslmgr_main.c:709): [0] OCSP check result is 'revoked', depth 0 2014-04-03 23:47:41.539 +0200 debug: sslmgr_check_status(sslmgr_main.c:915): [0] final status: revoked; reason: ; depth: 0; BY OCSP 2014-04-03 23:47:41.539 +0200 Send cookie:5 session:0 status:4 to DP owner: ialeksov
View full article
ialeksov ‎04-23-2014 02:35 PM
11,218 Views
8 Replies
1 Like
Overview This document describes how to make the required configuration changes for GlobalProtect when a Palo Alto Networks device with a private IP address on the untrust interface is being NATed by an upstream device with a public IP address. Example scenario: PAN Eth1/3 192.168.1.1 (Private IP) with a Static NAT on the upstream device of 1.1.1.1 (Public IP) Steps The following steps applies the IP addresses from the example scenario described above. Generate Portal and Gateway server certificates with the Common Name configured for the Public IP address: FQDN that resolve to 1.1.1.1 or IP address of 1.1.1.1 as Common Name. To setup the GlobalProtect Portal go to Network > GlobalProtect > Portal > Portal Configuration and use the untrust interface Eth1/3 and Private IP address assigned to interface. Select the Server Certificate with the Public IP address for Common Name. Configure Client Configuration Gateway IP address to the Public IP address Network > GlobalProtect > Portal > Client Configuration > Add > Gateway > External Gateways > Add The portal will send the GW IP address that the client will connect to and it will need to be the NAT Public IP address, which is this example: 1.1.1.1. To configure the GlobalProtect Gateway go to Network > GlobalProtect > Gateway > Add and use the untrust interface Eth1/3 and Private IP address assigned to interface. owner: gcapuno
View full article
gcapuno ‎04-16-2014 12:36 AM
5,363 Views
0 Replies
Issue The GlobalProtect client cannot connect to the GlobalProtect Portal. The following error appears in the GPS (GlobalProtect Services) log: failed to SetDoc. Message: errors getting GlobalProtect config Cause The error is caused due to user/group-based restrictions under Portal > Client Configuration > User/User Group. GlobalProtect cannot associate the GlobalProtect user with the configured user/group.  This can occur when the user is not a member of the specified group or when there is a malfunction (for example, syntax error) in the group mapping configuration. Resolution Check the group mapping configuration and make sure the user is a part of a specified group. See: Troubleshooting User-ID: Group and User-to-IP Mapping owner: hshah
View full article
hshah ‎01-06-2014 06:37 PM
7,254 Views
0 Replies
Overview This document describes how to configure HIP profiles for Windows and MAC GlobalProtect users only and then create a security policy to restrict them from using internal/external resources. Steps Create two separate HIP objects for Windows and MAC for all of their respective versions. Create a HIP profile and make sure that the OR operation is selected for both HIP objects. The OR operation is important because one particular workstation cannot be MAC and Windows at the same time when logging through GlobalProtect, even if a Windows VM is running on a MAC or vice-versa. Setup HIP notification for non-authorized trespassers. This is configured under GlobalProtect Gateway > Client Configuration > HIP Notification Create a security policy and apply the HIP profile to that security policy. GP zone is the zone where the tunnel terminates on. owner: kadak
View full article
kadak ‎10-16-2013 03:01 PM
6,316 Views
0 Replies
Overview This document explains how to configure a Palo Alto Networks firewall that has a dual ISP connection in combination with GlobalProtect VPN. One ISP link is used for non VPN traffic and the other is used exclusively for GlobalProtect VPN traffic. Configuration Goals: Dual ISP connection in combination with VPN tunnels. Simple Global Protect VPN Gateway/Portal and Client 1 ISP is preferred for LAN to Internet traffic - Default route towards ISP1 Other ISP link used for GP VPN traffic Details ISP1 is used as the primary ISP.  ISP2 is the GlobalProtect VPN traffic ISP. Palo Alto Networks firewall version: 5.0.6 ( Any version >= 4.1.x can be used ) Interface Configuration Configure four interfaces: Ethernet 1/1 - 10.193.19.1/23 - LAN Zone Interface Ethernet 1/2 - 192.168.2.11/24 - Zone ISP 1 Interface Ethernet 1/3 - 10.193.17.1/23 - Zone ISP 2 Interface tunnel.1 - 172.16.1.1/24 - Zone VPN Interface The VPN Zone GlobalProtect VPN will be configured soon. A requirement for the VPN to function is a tunnel Layer 3 interface. This interface is a virtual interface that has all the features of a physical interface. As such it can be configured in a zone of its own. In this configuration the tunnel.1 interface is placed in the Zone VPN. Whenever VPN traffic is initiated by the customer, this traffic will be seen by the firewall as egress from the tunnel.1 interface and VPN Zone. The VPN traffic needs to reach the ISP2 Zone . Network Security Configuration Configure basic networking and Security Policies to allow traffic between: LAN and ISP1 VPN and ISP2 Add Default Route 0.0.0.0/0 to ISP1: Allow traffic to the 2 ISPs by using NAT Rules In order for the outgoing traffic to be translated from internal IP addresses to outside IP addresses, we need to use some kind of Source NAT. In this example Dynamic IP and Port NAT is being used. The global IP will be the outgoing interface IP. NAT to ISP1: Source zone : any Destination zone: ISP1 NAT Type: Source NAT Source translation : dynamic IP and Port ; Interface : Ethernet 1/2 ; IP address: 192.168.2.11 NAT to ISP2: Source zone : any Destination zone: ISP2 NAT Type: Source NAT Source translation : dynamic IP and Port ; Interface : Ethernet 1/3 ; IP address: 10.193.17.1 At this point, traffic should be able to reach ISP1 from LAN and ISP2 from GlobalProtect VPN that has yet to be configured. ISP1 Connection Test Policy-Based Forwarding Since we are passing the default route 0.0.0.0/0 to the GlobalProtect client, the default behavior of the firewall is to route the packets towards ISP1, because of the default route set up in the static routes of the Virtual Router . The PBF will modify routing behavior in the following way: All packets initiated from interface tunnel.1 that are heading for any other address other than directly connected LAN subnetwork or the directly connected ISP1 subnetwork should be forwarded to interface ethernet 1/3 , going to ISP2. The next hop is the IP pointing to the ISP2 router that goes to the Internet. There is no need for Symetric Return since the NAT will identify NATed sessions and translate it back to the initial internal IP. This will overwrite all packets going to an unknown address originating from the GlobalProtect tunnel interface. GlobalProtect Configuration This implementation of GlobalProtect is a basic one, without any special features. For a more detailed GlobalProtect configuration, check other Knowledge Base articles, Configuration Guides or the official Administration Guide in addition to the following references: How to Configure GlobalProtect How to Generate a New Self-Signed Certificate GlobalProtect Configuration Tech Note GlobalProtect Setup Gateway IP: 10.193.19.1 GlobalProtect Client IP Pool: 172.16.1.2 -> 172.16.1.55 Tunnel Interface: tunnel.1 Tunnel Interface IP: 172.16.1.1 Routes passed to clients : 0.0.0.0/0 - The clients will have as default gateway 172.16.1.1 - tunnel.1 interface Detailed configuration: Certificates GlobalProtect Gateway GlobalProtect Portal Also, the user authentication needs to be configured in the Local Database: Once this is set up, the GlobalProtect Client should be able to connect to the GlobalProtect Gateway: Client Connection to GlobalProtect Connection is successful. Assigned IP address is 172.16.1.2: A Virtual interface is created on the Windows machine: And, the default route is being injected: Connection to Internet through ISP2 is working: Note:  This configuration does not achieve a failover if any one of the ISPs is not reachable. owner: bbolovan
View full article
bbolovan ‎10-15-2013 01:33 AM
73,705 Views
1 Reply
Details To see all users who accessed GlobalProtect VPN for a particular period of time, use the following CLI command: > show log system eventid equal globalprotectportal-auth-succ start-time equal 2014/04/22@14:00:00 end-time equal 2014/04/22@14:12:00 csv-output equal yes The output will be similar to the following: Domain,Receive Time,Serial #,Type,Threat/Content Type,Config Version,Generate Time,Virtual System,eventid,object,fmt,id,module,Severity,Description,seqno,actionflags 1,2014/04/22 14:11:22,007101000242,SYSTEM,globalprotect,0,2014/04/22 14:11:22,,globalprotectportal-auth-succ,portal,0,0,general,informational,"GlobalProtect portal user authentication succeeded. Login from: 192.168.33.68, User name: gpuser, Auth type: profile.",27187,0x0 On the GUI, navigate to Monitor > Logs > System and filter using (eventid eq globalprotectportal-auth-succ) and (receive_time geq '2014/04/22 14:00:00') and (receive_time leq '2014/04/22 14:12:00'). The data can then be exported to CSV format. owner: rsreejith
View full article
rsreejith ‎10-10-2013 04:18 PM
9,719 Views
4 Replies
Overview The OS field in HIP is used to identify the device type. However, there is no Android option in the OS field for HIP. This document explains how to configure HIP check for Android devices. Note: GlobalProtect Application for Android devices require gateway subscription. Steps Since a HIP profile for Android cannot be directly configured, the following steps for a workaround can be applied. Configure a HIP Object for Apple iOS, as shown below: Configure a HIP Object for Apple Mac OS X: Configure a HIP Object for Microsoft Windows: After creating the HIP objects above, configure a HIP profile for Android devices. For the HIP profile we specify the match criteria by using the previously defined HIP objects (by Name). The above workaround suggests that if the device is not iOS, Windows, or Mac OS, then it will be an Android device. owner: jburugupalli
View full article
jburugupalli ‎08-08-2013 11:48 AM
4,916 Views
0 Replies
Overview Starting with PAN-OS 5.0, when you have an interface set to DHCP, that interface can be selected to be used by GlobalProtect for Portal and Gateway. However, the IP address remains as "None". It is not possible to select the IP address. Details When using an interface that receives its address dynamically as a GlobalProtect Portal/Gateway, the configuration process is to select the interface and leave the IP address set to none. The dataplane will automatically use the dynamically assigned IP address. The IP address cannot be selected as doing so would lock the configuration to reference a specific IP value. If the interface were to renew its DHCP lease and receive a different IP address, the configuration would become invalid and GlobalProtect would break. owner: jdelio
View full article
‎04-16-2013 08:43 AM
5,527 Views
2 Replies
In addition to using a non-https Global Protect Portal, you can access an associated Gateway on a configured loopback interface. If you only have one public-facing IP address, and you wish to host SSL-based applications, such as OWA on that IP, the following information provides the configuration steps for doing so. Please follow Knowledge Base article How to Configure GlobalProtect Portal Page to be Accessed on any Port with one caveat. You'll need to create a second loopback interface in addition to the first loopback interface used for the Portal. Create additional loopback interface Make sure the untrust interface can ping the loopback. > ping source 99.7.172.157 host 10.1.1.     PING 10.1.1.2 (10.1.1.2) from 99.7.172.157 : 56(84) bytes of data.     64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.126 ms     64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=0.068 ms     Assign loopback interface as the Portal address Assign loopback.1 interface as the Gateway address Create the following services and add them to a service group. These services will be natted to our Gateway loopback interface. In this example, services were created destined for ports 500 (ike/ciscovpn), 4501 (ipsec-esp-udp). The two custom services are added in addtion to the predefined service-https to the gateway service group profile. Create the services   Add the services to a service group object Create the security policies as needed. As noted in the prior KB article,  a rule is needed for the Portal page to redirect that traffic on a non-ssl standard port to our first loopback interface. Here GP portal is accessed on port 7000 instead of port 443. Below this rule, another rule is created to the gateway allowing ike, ipsec, panos-global-protect, ssl and web-browsing respectively. Create the NAT policy which will forward traffic to the second loopback (loopback.1) interface. In this example, the gateway service group is utilized and used to forward traffic to 10.1.1.2, the loopback.1 interface previously configured. Configure iPhone/iPad on the Gateway. Enable 'X-Auth Support' on the gateway and create a Group Name and the Group Password respectively. This will be utilized when configuring the VPN profile on the mobile devices. Create the VPN Profile on the iPhone/iPad using the shared secret configured in the previous step. The password in the profile will need to match with the authentication method chosen (ie ldap, kerberos,localdb, etc). Confirm access via your Global Protect client as well as your mobile device. > show global-protect-gateway current-user         GlobalProtect Name : gp-gateway (2 users)         Domain User Name      Computer        Client          Private IP      Public IP      ESP    SSL    Login Time      Logout/Expiration TTL     Inactivity TTL         ------ ---------      ---------      ----------      ---------      ---    ---    ----------      ----------------- ---      ----------- ---               \renato          PAN01347        Windows 7 (Version 6.1 Build 7601 Service Pack 1)10.10.10.2      64.124.57.5    exist  none    Oct.02 06:04:01 Nov.01 06:04:01  2589926  9641               \renato          64.124.57.5    iPhone OS:6.0  10.10.10.1      64.124.57.5    exist  none    Oct.02 06:38:33 Oct.02 07:39:33  3657     10798 owner: rkalugdan
View full article
gswcowboy ‎10-01-2012 10:27 PM
21,997 Views
1 Reply
Symptoms OCSP validation of client certificates for GlobalProtect is not working when using a Microsoft's Lightweight OCSP Profile Issue Confirm that validating the certificate outside of the firewall to the OCSP server is successful. Keep in mind that the firewall includes the nonce in the OCSP query Take a look at the following logs from mp-log sslmgr.log, for the following error message (or similar): Jul 30 15:46:59 sslmgr: ike mgr client certificate profile commit Jul 30 15:52:16 Error: pan_ocsp_parse_response(pan_crl.c:1262): [OCSP] The result of Certificate status query is unavailable for serial number[6128D58D000000000004] and uri[ http://labsrv1.stealthllama.local/ocsp ] Jul 30 15:52:16 Error: pan_ocsp_fetch_ocsp(pan_crl.c:1948): pan_ocsp_parse_response() failed There might also be error messages like the ones below: Jul 31 18:24:31 sslmgr_sysd_verify_cert(sslmgr_sysd.c:164): vsys id(1) profile name(StealthllamaClients) cert len (2034) obj len(2074) struct length(40) Jul 31 18:24:31 [OCSP] URL (null) serialno: 6128D58D000000000004 Jul 31 18:24:31 pan_ocsp_certchain_to_file(pan_crl.c:1066): root_ca_fname(Clr3Zk-uU9Jad2n) Jul 31 18:24:31 pan_ocsp_query_responder(pan_crl.c:1807): cetificate valid time information (Issuer: Not Before[Jul 29 15:51:18 2012 GMT]; Not After[Jul 29 16:01:16 2017 GMT]; Cert: Not Before[Jul 29 16:24:45 2012 GMT]; Not After[Jul 29 16:24:45 2013 GMT];) Jul 31 18:24:31 pan_ocsp_parse_response(pan_crl.c:1187): Responder Error: unauthorized (6) Jul 31 18:24:31 Error: pan_ocsp_parse_response(pan_crl.c:1262): [OCSP] The result of Certificate status query is unavailable for serial number[6128D58D000000000004] and uri[ http://labsrv1.stealthllama.local/ocsp ] Jul 31 18:24:31 Error: pan_ocsp_fetch_ocsp(pan_crl.c:1948): pan_ocsp_parse_response() failed Jul 31 18:24:31 sslmgr_check_status(sslmgr_main.c:671): [OCSP] Certificate status unavailable: depth:0 Resolution Enable that extension in the MicroSoft OCSP responder. Microsoft's Lightweight OCSP Profile does not support nonce extensions by default. However, it can be enabled by modifying the Revocation Configuration extensions. owner: dwhyte
View full article
npare ‎08-06-2012 12:37 PM
8,228 Views
1 Reply
Issue This example utilizes a Guest Network Zone for wireless users who are only permitted WWW access outbound. Administrator wishes to permit Guest Network users access to internal resources but does not wish to open up security policies to the trust network to assure complete isolation. As a solution, administrator chooses to allow authorized users within the Guest Network to connect via their GlobalProtect clients to the external Portal/GW permitting access to internal resources. By default, connectivity to the Portal/GW will fail. Reason being users attempting to connect to the portal will be traversing the Untrust interface of the PAN which will utilize the IP assigned via the dynamic NAT created for outbound access (i.e., the IP of the L3 untrust interface IP). As a result, global counters or flow-basic logs would typically indicate a potential LAND Attack/Spoof due to the source IP of the requesting client (NATd by the untrust interface) is also connecting to the same IP as a destination for Portal/GW termination. Resolution Option 1 Create a separate NAT (move to the top of the NAT policy list) utilizing a unique IP for a specific host/subnet (i.e., subnet specified for all guest network users) when accessing the portal. This NAT would be similar to the dynamic NAT utilized for outbound web access though would be tweaked slightly to define a destination IP for which the NAT will be applied (i.e., Portal/GW Address), the source subnet that the users reside as well as a source translation (dynamic-ip-and-port) utilizing a unique IP , seperate from the IP of the Portal/GW. Following excerpt shows a successful connection from the Trust Network->Untrust (Public IP of Untrust Interface) being NATd using a unique IP (i.e., last octet in this example = .222): > show session all filter destination 10.30.6.82 -------------------------------------------------------------------------------- ID      Application    State  Type Flag  Src[Sport]/Zone/Proto (translated IP[Port]) Vsys          Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 55372  web-browsing  ACTIVE  FLOW *NB  192.168.82.142[1395]/Trust/6  (10.30.6.222[21737]) vsys1    10.30.6.82[443]/Untrust  (10.30.6.82[20077]) 55466  ping          ACTIVE  FLOW  NS  192.168.82.142[512]/Trust/1  (10.30.6.222[512]) vsys1       10.30.6.82[39424]/Untrust  (10.30.6.82[39424]) 55423  web-browsing  ACTIVE  FLOW *NB  192.168.82.142[1435]/Trust/6  (10.30.6.222[10228]) vsys1    10.30.6.82[443]/Untrust  (10.30.6.82[20077]) 55489  ping          ACTIVE  FLOW  NS  192.168.82.142[512]/Trust/1  (10.30.6.222[512]) vsys1       10.30.6.82[39168]/Untrust  (10.30.6.82[39168]) > show session id 55372 Session          55372         c2s flow:                 source:      192.168.82.142 [Trust]                 dst:        10.30.6.82                 proto:      6                 sport:      1395            dport:      443                 state:      INIT            type:      FLOW                 src user:    unknown                 dst user:    unknown         s2c flow:                 source:      10.30.6.82 [Untrust]                 dst:        10.30.6.222                 proto:      6                 sport:      20077          dport:      21737                 state:      INIT            type:      FLOW                 src user:    unknown                 dst user:    unknown         start time                    : Thu Jul  5 10:16:53 2012         timeout                      : 60 sec         total byte count(c2s)        : 3308         total byte count(s2c)        : 10292         layer7 packet count(c2s)      : 17         layer7 packet count(s2c)      : 21         vsys                          : vsys1         application                  : web-browsing         rule                          : GlobalProtect-Guest         session to be logged at end  : True         session in session ager      : False         session synced from HA peer  : False         address/port translation      : source + destination         nat-rule                      : GW-TEST(vsys1)         layer7 processing            : completed         URL filtering enabled        : True         URL category                  : private-ip-addresses         session via syn-cookies      : False         session terminated on host    : True         session traverses tunnel      : False         captive portal session        : False         ingress interface            : ethernet1/6         egress interface              : ethernet1/3         session QoS rule              : N/A (class 4) Option 2 This option allows traffic destined for the untrust interface IP strictly as L3 (no nat). Create a new NAT rule (move to the top of the NAT policy list) defining the source IP/subnet of the Zone requiring external GP access, specify the destination IP of the GW & leave both Source & Destination Translation as 'none'. Following the commit, this will allow users accessing these resources directly bypassing any limitations resulting from egress traffic being NATd. Sample session output below showing traffic as still having a ND flag though the NAT rule itself is 'NON-NAT' allowing successful access to the public address of the portal: > show session all filter source 192.168.82.142 destination 10.30.6.82 -------------------------------------------------------------------------------- ID      Application    State  Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])           Vsys                                     Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 10196  ipsec-esp-udp  ACTIVE  FLOW      192.168.82.142[4821]/Trust/17  (192.168.82.142[4821])  vsys1                                    10.30.6.82[4501]/Untrust  (10.30.6.82[4501]) 10813  web-browsing  ACTIVE  FLOW *ND   192.168.82.142[1706]/Trust/6  (192.168.82.142[1706])    vsys1                                    10.30.6.82[443]/Untrust  (10.30.6.82[20077]) > show session id 10813 Session          10813         c2s flow:                 source:      192.168.82.142 [Trust]                 dst:        10.30.6.82                 proto:      6                 sport:      1706            dport:      443                 state:      ACTIVE          type:      FLOW                 src user:    unknown                 dst user:    unknown         s2c flow:                 source:      10.30.6.82 [Untrust]                 dst:        192.168.82.142                 proto:      6                 sport:      20077          dport:      1706                 state:      ACTIVE          type:      FLOW                 src user:    unknown                 dst user:    unknown         start time                    : Thu Jul  5 15:24:51 2012         timeout                      : 60 sec         time to live                  : 52 sec         total byte count(c2s)        : 1131         total byte count(s2c)        : 816         layer7 packet count(c2s)      : 7         layer7 packet count(s2c)      : 4         vsys                          : vsys1         application                  : web-browsing         rule                          : rule1         session to be logged at end  : True         session in session ager      : True         session synced from HA peer  : False         address/port translation      : source + destination         nat-rule                      : NO-NAT(vsys1)         layer7 processing            : completed         URL filtering enabled        : True         URL category                  : private-ip-addresses         session via syn-cookies      : False         session terminated on host    : True         session traverses tunnel      : False         captive portal session        : False         ingress interface            : ethernet1/6         egress interface              : ethernet1/3         session QoS rule              : N/A (class 4) owner: bryan
View full article
bryan ‎07-05-2012 05:56 PM
7,194 Views
0 Replies
1 Like
Overview This document describes the two methods used to uninstall GlobalProtect for MAC. Details Uninstall via Terminal $ sudo /Applications/GlobalProtect.app/Contents/Resources/uninstall_gp.sh Uninstall via pkg file Run the initial .pkg file the was used to do the install. This can be downloaded from the GlobalProtect Portal page. Select Continue on the Introduction page. Destination Select -> Click 'Install for all users of this computer' -> Continue Uncheck 'GlobalProtect', then check 'Uninstall GlobalProtect' -> Continue Click 'Install' owner: sspringer
View full article
sspringer ‎05-30-2012 11:03 PM
52,263 Views
0 Replies
PAN-OS  5.0, 5.1, 6.0, 6.1, 7.0 Overview This document describes the steps to configure GlobalProtect with a client certificate profile when using a client certificate for authentication with or without other authentication methods. The example applied in this document is done with self-signed certificates, but it can also be done with an internal CA store. Refer to the following document for basic GlobalProtect configuration: GlobalProtect Configuration Tech Note . Steps 1. Go to Device > Certificates The screenshot above shows the following: The self-signed Certificate "Root-CA" that will be used to sign the following: Server Certificate used for the the connections to the GlobalProtect Portal and Gateway. Client Certificate used to import on the clients when you want to use a Client Certificate for Authentication as well or alone. The Server Cert signed by the Root-CA with the Subject name which matches the address IP that the client will query for the GlobalProtect Portal and Gateway connections. Note: FQDN will be used for Common name instead of IP if listing FQDN in the configuration for Gateway addresses. Certificate CN name and address the client queries should be the same. The Client Cert also signed by the Root-CA with the Common Name Client Certificate. Note: The client cert name does not matter here as long as it gets imported into the host machines correctly and is signed by the Root-CA. 2. Go to Device > Certificate Profile Click Add and add the Root-CA in the profile. Click OK to save. 3. Go to Network Tab > GlobalProtect Portal Click on your Portal Configuration and add the Certificate Profile to the GlobalProtect Portal Note: You can optionally have an Authentication Profile in your configuration. T his will only work when the certificate profile has the username configured. The commit will fail if GlobalProtect is configured with just a certificate profile as authentication, where the username in the profile is "none". Click on Client Configuration tab in the Portal configuration and make sure to list the Root-CA under the Trusted Root Section. 4. Go to Network > GlobalProtect Gateway Click on your Gateway Configuration Add the Certificate Profile to the Gateway Note: You can optionally have an Authentication Profile in your configuration. 5. Go to Device > Certificates Export the Root-CA as PEM without key Export the Server Certificate as PEM without key Export the Client Cert as PKCS12 with key 6. Commit your changes On your computer: Note: If using a Third Party Certificate source, importing the Root CA will not be necessary as it should already be trusted. Open the Console Certificate Store by pressing the Start Menu and typing "mmc". Click File and click on Add/Remove Snap-in and click on Certificates Click on add to move Certificates over to snap-in and click finish "My user account" is for one account. If there will be multiple other accounts on the computer that will be using the GlobalProtect select "Computer account". Press OK to finish this step Certificates should now be seen under the Console Root folder. Click on the left arrow next to Certificates to have the folders display the Certificate stores for the User account Click the left arrow next to the Trusted Root Certificates folder to see the Certificates Folder for Trusted Root Certificates Right Click the Trusted Root Certificates  > Certificate folder and click import The import Wizard will start. Click Next. Click Browse and find the Root-CA. You may have to change the File type to see the file. Open the file and click on Next through the end of the wizard. The Root will now be seen in the Trusted Root Certificates. Import the Client Certificate into the Personal > Certificates folder by right-clicking the Certificates folder under the Personal folder and then clicking All Tasks > Import Note: Since the Client Certificate is in PKCS12 format with Private Key, the wizard will ask for the password used when you exported it.    Follow the Import Wizard again to complete the import of the Client Certificate into the Personal folder. Go to the Web Broswer and go to your Portal to download the GlobalProtect Client When prompted, choose the client certificate that should be used. This is necessary for the Portal authentication to succeed. Once the certificate is chosen, the Portal page will load. Note: The following example is for IE, but Firefox and Chrome will have similar prompts On the portal page if another Authentication method is configured, you will see the username and password fields If the authentication profile is set to none and the user's client certificate is valid, the user will be allowed access to the portal and will not need to authenticate again. Note: T his will only work when the certificate profile has the username configured. The commit will fail if GlobalProtect is configured with just a certificate profile as authentication, where the username in the profile is "none". owner: glasater
View full article
panagent ‎02-06-2012 09:56 AM
23,196 Views
3 Replies
The GlobalProtet data file, located on the Device tab > Dynamic Updates contains the OPSWAT file that lists the vendors to be used in the HIP object configuration. A valid Global Protect Gateway and Portal license is necessary, and the download schedule needs to be configured before automatic updates can occur. owner: panagent
View full article
nrice ‎03-17-2011 12:01 PM
7,580 Views
3 Replies
Ask Questions Get Answers Join the Live Community