Configuration Articles

Featured Article
Overview Dead Peer Detection (DPD) refers to functionality documented in RFC 3706 , which is a method of detecting dead Internet Key Exchange (IKE/Phase1) peers. Tunnel Monitoring is a Palo Alto Networks proprietary feature that verifies traffic is successfully passing across the IPSEC tunnel in question by sending a PING down the tunnel to the configured destination. Tunnel monitoring can be used in conjunction with “Monitor Profiles” to bring down the tunnel interface allowing routing to update to allow traffic to route across secondary routes. Tunnel monitoring does not require DPD. Dead Peer Detection must be either active or disabled on both sides of the tunnel, having one side with DPD enabled and one side with it disabled can cause VPN reliability issues.   Details Dead Peer Detection DPD is a monitoring function used to determine liveliness of the Security-SA (Security Association and IKE, Phase 1)   DPD is used to detect if the peer device still has a valid IKE-SA. Periodically, it will send a “ISAKMP R-U-THERE” packet to the peer, which will respond back with an “ISAKMP R-U-THERE-ACK” acknowledgement.   The Palo Alto Networks does not currently have a log associated with DPD packets, but can be detected in a debug packet capture. The following is a PCAP from a peer device:   Mar  4 14:32:36 ike_st_i_n: Start, doi = 1, protocol = 1, code = unknown (36137), spi[0..16] = cd11b885 588eeb56 ..., data[0..4] = 003d65fc 00000000 ... Mar  4 14:32:36 DPD; updating EoL (P2 Notify Mar  4 14:32:36 Received IKE DPD R_U_THERE_ACK from IKE peer: 169.132.58.9 Mar  4 14:32:36 DPD: Peer 169.132.58.9 is UP status_val: 0.   The DPD query and delay interval can be configured when DPD is enabled on the Palo Alto Networks device. DPD will tear down the SA once it realizes the peer is no longer responding. Note: The DPD is "not persistent" and is only triggered by a Phase 2 rekey. This means if Phase 2 is up, Palo Alto Networks will not check to see if IKE-SA is active. To get Phase 2 to trigger a rekey, and trigger the DPD to validate the Phase 1 IKE-SA, enable tunnel monitoring.   Tunnel Monitoring Tunnel Monitoring is used to verify connectivity across an IPSEC tunnel. If a tunnel monitor profile is created it will specify one of two action options if the tunnel is not available: Wait Recover or Fail Over. Wait Recover tells the firewall to wait for the tunnel to recover and not take additional action Fail Over will force traffic to a back-up path if one is available In both cases, the firewall will try to negotiate new IPSec keys to accelerate the recovery. A threshold option can be set to specify the number of heartbeats to wait before taking the specified action. The range is between 2 and 100 and the default is 5. The interval between heartbeats can also be configured. The range is between 2 and 10 and the default is 3.   Once the tunnel monitoring profile is created, as shown below, select it and enter the IP address of the remote end to be monitored.   owner: panagent
View full article
nrice ‎08-30-2018 10:14 AM
130,000 Views
22 Replies
2 Likes
Details The following diagram illustrates an IPSec site-to-site between a Palo Alto Networks firewall and Cisco:   Tunnel Interface Create a tunnel interface and select virtual router and security zone. The security policy needs to allow traffic from the LAN zone to the VPN zone, if placing the tunnel interface in some separate zone other than the internal LAN network zone.   The IP address is not required. To run the routing protocol through the tunnel, you must add an IP address to the tunnel interface.         Loopback Interface For this scenario we are using a Loopback interface to simulate a host in an internal zone for testing purposes, otherwise there is no need for the loopback interface.         Phase 1 Create a Phase 1 policy, which will be the same on both sides:   Phase 2 Create a Phase 2 policy, which will be the same on both sides:     IKE Gateway The peer IP address must be reachable through the interface Ethernet 1/1, as shown below:       IPSec Tunnel Select the tunnel interface, the IKE gateway, and the IPSec Crypto profile to make sure the Proxy-ID is added, otherwise phase 2 will not come up.       Route Add the route of the internal network of the other side pointing towards the tunnel interface and select None:   Configuring Cisco   ip access-list extended Crypto_Acl permit ip 10.50.50.0 0.0.0.255 16.16.16.0 0.0.0.255 crypto isakmp policy 16 encr aes hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 crypto ipsec transform-set TSET esp-aes esp-sha-hmac crypto map CMAP 10 ipsec-isakmp set peer 10.50.240.55 set transform-set TSET match address Crypto_Acl interface FastEthernet0/0 crypto map CMAP   owner: pakumar
View full article
pankaku ‎08-28-2018 10:34 AM
9,415 Views
0 Replies
2 Likes
Although it is not possible to change the port GlobalProtect uses, it is possible to use another port with help from a loopback IP address and security rules.   Here is how to do that: Create a loopback   Make sure the untrust interface can ping the loopback. Assign the loopback as the portal address and the gateway address     In the GlobalProtect Portal > Agent > External tab, set the external gateway to address (10.30.6.56:7000 for example)   Create a Destination NAT rule with service:7000 to 10.30.6.56 (Untrust Interface) translating to 10.10.10.1 (loopback) on service:443 Create a security policy with destination address as the untrust interface and services as 7000 and 443 With this configuration, you will be able to access the global protect portal page on https://10.30.6.56:7000 which will translate to https://10.10.10.1 .Download and install the GlobalProtect client software.   Use the credentials in the username & password fields. In the portal field, use the IP as 10.30.6.56:7000 as shown.             owner: mvenkatesan
View full article
mvenkatesan ‎07-19-2018 06:07 AM
49,409 Views
17 Replies
4 Likes
Details When terminating IPSec VPN tunnels on a Palo Alto Networks firewall, consider that: The terminating interface must be associated with the same zone as the external port where the tunnel packets enter the firewall. If terminating the tunnel on an aggregate ethernet interface, the aggregate interface must also be bound to the external interface (where the tunnel packets enter the firewall). The interface is where the original packet (IKE packet) entered the firewall.   owner: nayubi
View full article
nayubi ‎06-19-2018 01:16 AM
7,718 Views
0 Replies
 What is GlobalProtect with On-Demand?   As the name says, on-demand (at user's will), the user has control over when to connect or disconnect from GlobalProtect. Once connected to GlobalProtect, the user will see a 'disconnect' option to disconnect when needed.   This document explains basic GlobalProtect configuration for on-demand with the following considerations:   Authentication - local database Same interface serving as portal and gateway. Root, intermediate and server certs are generated on PAN   1. Generate a root CA, intermediate CA and a server cert as explained in this document: https://live.paloaltonetworks.com/t5/1-Submit-and-Collaborate/Certificate-config-for-GP-SSL-TLS-Client-cert-profiles/ta-p/131592         2. Create an SSL/TLS profile under Device > Certificate Management > SSL/TLS service profile, referencing the above created 'server certificate'.   3. Create an authentication profile under Device > Authentication Profile > Add.   Name- Give a name to this authentication profile Type - Choose Local Database(You may choose ldap,radius etc depending on your requirement)   Advanced Tab > Allow List > Add - Select all (If you have groups, you may restrict it to required groups) Click OK to save.         4. Create a tunnel interface under Network > Interfaces >Tunnel. Give a tunnel number, virtual router and security zone. It is recommended to create a separate zone for VPN traffic as it gives better flexibility to create separate security rules for the VPN traffic.       Configure GlobalProtect Portal   5. Go to Network > GlobalProtect > Portals > Add. General Tab. Give a name to the portal and select the interface that serves as portal from the drop down.      6. Authentication Tab.   a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.   7. Agent Tab. Add a new client config. a. Authentication tab: Give any name to this client config Client certificate - leave it to none, this will only be needed if we want to push any client certificate to clients for authentication purpose. Save user credentials - Yes(default) (Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate that is selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '.     b. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups if needed)   Important! Gateways tab.  Under 'External gateways', click Add. Give any name to it. Address- Enter the IP address or FQDN which was referenced in the certificate Common Name(CN) or Subject Alternate Name(SAN) of step 1. In this example we enter 'gp.portal-gw01.local'        d. App tab. Under 'Connect-method' drop down, select 'On-demand (Manual user initiated connection)'.  Note: To change this GP setup from 'On-demand' to 'user-logon', just change the 'connect-method' from 'on-demand' to 'user-logon'.     e. Click OK to save. f. Under 'Trusted Root CA', select the root CA and intermediate CA. Also, select 'Install in Local root certificate store' to install these certificates in the client's local root certificate store after the client successfully connects to the portal for first time.   g. Click OK to save and close GP portal config.     Configure GlobalProtect Gateway   8.  Go to Network>GlobalProtect>Gateways>Add. General Tab. Give a name to the gateway and select the interface that serves as gateway from the drop down.    9. Authentication Tab. This is similar to step 6 but this is for gateway. a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.     10. Agent Tab. a. Tunnel Settings. Check 'Tunnel mode' to enable tunnel mode and select the tunnel interface created in step 4 from the drop-down.  b. Enable IPSec. Check this box to enable IPSec, this is highly recommended. With this setting enabled, GP will always try to first connect over IPSec, if it fails then GP falls back to SSL.   c. Timeout settings - leave them to defaults. For any changes to this, refer to GP admin guide. d. Client settings   Click Add> Give a name to authentication override tab   -(Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '. Note: If a certificate is selected here under portal, the same needs to be selected here under Gateway 'certificate to encrypt/decrypt cookie'.     e. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups if wanted).    Important! If a group is chosen from the drop-down, make sure that the GlobalProtect user is part of this group, if not the client will NOT receive IP address from gateway. Common issues here are when the user is identified by GlobalProtect as 'domain\user' but the firewall's userid may have it as 'fully qualified domain\user', in those cases make sure the group/user is shown identical at both places by overwriting domain field in user-identification>group mapping.      f. Network Settings.  Under the Ip-pool:     Very Important! The GlobalProtect gateway will be assigning IPs from this pool to clients. Specify the one or more IP pool ranges which DO NOT OVERLAP with any of the existing networks in the organization. Overlapping subnets can cause routing issues and network outages. (Optional but recommended) You can add a second IP pool range for backup which will be useful in cases where the user connects a wifi that is providing the same IP pool range as your primary IP pool.   g. Access Route. This defines which subnets can be reached by GP clients once they are connected to gateway. If left blank, it takes it as 0.0.0.0/0 ie all the traffic from GP client will be forced to go through GP tunnel. For split tunneling: Specify required internal subnets like 10.0.0.0/8, 192.168.x.0/24 etc so that GP client will use the tunnel to reach only these subnets. Anything outside these subnets will be accessed directly from the client's local network, th is is called split tunneling.   h. Click OK to save and close client settings. One more OK to save and close GP gateway settings.   11. Create a local username/password under Device>Local user database>users for testing. 12. Create security and NAT policies for the newly created VPN zone to give access appropriately. 13. Commit the changes.   To test on client machine   1. From the browser, go to https://gp.portal-gw01.local/ ie https://<portal-ip/fqdn> 2. Enter the credentials 3. Download the GlobalProtect client  4. In the GlobalProtect client, enter the Portal address and credentials, click connect.    
View full article
dreputi ‎06-18-2018 12:40 PM
20,978 Views
2 Replies
1 Like
Overview This document describes how to configure the Palo Alto Networks firewall to behave as an IPSec passthrough between VPN terminating devices.   Details Configure a security policy to allow the "ipsec" application traffic between the tunnel endpoints. This will enable the Palo Alto Networks firewall to act as vpn passthrough for traffic between vpn peers.   For example The screenshot below shows devices 198.51.100.1 and 203.0.113.1 (10.0.0.1 internally)  as the vpn peers. T he application, "ipsec", is specified under the Application column.     The ipsec application contains the following sub-apps: ike ipsec-ah ipsec-esp ipsec-esp-udp(NAT-T) The sub-apps above are allowed implicitly when the ipsec application is configured as allowed.   owner: saryan
View full article
saryan ‎02-23-2018 03:49 AM
65,230 Views
9 Replies
 What is GlobalProtect with User-logon (Always On)?   As the name says, user-logon, the GlobalProtect is connected after a user logs on to a machine. When this is used with SSO (Windows only) or save user credentials (MAC) , the GlobalProtect gets connected automatically after the user logs into the machine. The idea behind user-logon is to have the user 'always' stay connected to GlobalProtect. Once connected to GlobalProtect, the user will see the 'disable' option (if allowed by admin) to disable the GlobalProtect application when needed.   This document explains basic GlobalProtect configuration for user-logon with the following considerations:   Authentication - local database Same interface serving as portal and gateway. Root, intermediate and server certs are generated on PAN   1. Generate a root CA, intermediate CA and a server cert as explained in this document: https://live.paloaltonetworks.com/t5/Configuration-Articles/Certificate-config-for-GP-SSL-TLS-Client-cert-profiles/ta-p/131592       2. Create an SSL/TLS profile under Device > Certificate Management > SSL/TLS service profile, referencing the above created 'server certificate'.   3. Create an authentication profile under Device > Authentication Profile > Add.   Name- Give a name to this authentication profile Type - Choose Local Database(You may choose ldap,radius etc depending on your requirement) Advanced Tab > Allow List>Add - Select all (If you have groups, you may restrict it to required groups) Click OK to save.            4. Create a tunnel interface under Network > Interfaces > Tunnel. Give a tunnel number, virtual router and security zone. We recommend creating a separate zone for VPN traffic as it gives better flexibility and more security to create separate security rules for the VPN traffic.       Configure GlobalProtect Portal   5. Go to Network > GlobalProtect > Portals > Add. General Tab. Give a name to the portal and select the interface that serves as portal from the drop down.      6. Authentication Tab a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.       7. Agent Tab. Add a new client config    a. Authentication tab: Give any name to this client config Client certificate - leave it as none, this will only be needed if we want to push any client certificate to clients for authentication purpose. Save user credentials - Yes (default) (Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate that is selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '. Note: If a certificate is selected here under portal, the same certificate needs to be selected under Gateway's  config for encrypt/decrypt cookie .      b. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups, if needed)   IMPORTANT! Gateways tab. c. Under 'External gateways', click Add. Give any name to it. Address- Enter the IP address or FQDN which was referenced in the certificate Common Name(CN) or Subject Alternate Name(SAN) of Step 1. In this example we enter 'gp.portal-gw01.local'         d. App tab. Under 'Connect-method' drop down, select 'User-logon (Always On)'.  Note: To change this GP setup from 'User-logon' to 'On-demand', just change the 'connect-method' from 'user-logon' to 'on-demand'.    e. Click OK to save. f. Under 'Trusted Root CA', select the root CA and intermediate CA. Also, select 'Install in Local root certificate store' to install these certificates in the client's local root certificate store after the client successfully connects to the portal for first time. g. Click OK to save and close GP portal config.     Configure GlobalProtect Gateway   8.  Go to Network > GlobalProtect > Gateways > Add. General Tab. Give a name to the gateway and select the interface that serves as gateway from the drop down.    9. Authentication Tab. This is similar to step 6 but this is for gateway. a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.     10. Agent Tab. a. Tunnel Settings. Check 'Tunnel mode' to enable tunnel mode and select the tunnel interface created in step 4 from the drop-down.  b. Enable IPSec. Check this box to enable IPSec, this is highly recommended. With this setting enabled, GP will always try to first connect over IPSec, if it fails then GP falls back to SSL.   c. Timeout settings - leave them to defaults. For any changes to this, refer to the GlobalProtect admin guide. d. Client settings Click Add> Give a name to authentication override tab -(Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '. Note: If a certificate was selected in step 7 under portal, the same certificate needs to be selected here under Gateway 'certificate to encrypt/decrypt cookie'.   e. User/User group tab. Leave the OS and User group to 'any' (you may restrict it to required groups if wanted).    IMPORTANT! If a group is chosen from the drop-down, make sure that the GlobalProtect user is part of this group, if not the client will NOT receive an IP address from gateway. Common issues here are when the user is identified by GlobalProtect as 'domain\user' but  the firewall's userid may have it as 'fully qualified domain\user', in those cases make sure the group/user is shown as identical at both places by overwriting domain field in user-identification>group mapping.    f. Network Settings.  Under the Ip-pool:       IMPORTANT! GlobalProtect gateway will be assigning IPs from this pool to clients. Specify the one or more IP pool ranges which DO NOT OVERLAP with any of the existing networks in the organization. Overlapping subnets can cause routing issues and network outages. (Optional but recommended) You can add a second IP pool range for backup which will be useful in cases where the user connects a wifi that is providing the same IP pool range as your primary IP pool.   g. Access Route. This defines which subnets can be reached by GlobalProtect clients once they are connected to gateway. -If left blank, it takes it as 0.0.0.0/0 ie all the traffic from the GlobalProtect client will be forced to go through GlobalProtect tunnel.   For Split tunneling: Specify required internal subnets like 10.0.0.0/8, 192.168.x.0/24 etc. so that the GlobalProtect client will use the tunnel to reach only these subnets. Anything outside these subnets will be accessed directly from the client's local network, this is called split tunneling.   h. Click OK to save and close client settings. One more OK to save and close GlobalProtect gateway settings.   11. Create a local username/password under Device > Local user database>users for testing. 12. Create security and NAT policies for the newly created VPN zone to give access appropriately. 13. Commit the changes.   To test on client machine   1. From the browser, go to https://gp.portal-gw01.local/ ie https://<portal-ip/fqdn> 2. Enter the credentials 3. Download the GlobalProtect client  4. In the GlobalProtect client, enter the portal address and credentials, click connect.    
View full article
dreputi ‎01-25-2018 03:39 AM
41,417 Views
0 Replies
3 Likes
Overview This document describes the steps to configure an internal only GlobalProtect Gateway. This document was created on Palo Alto Networks device running PAN-OS 8.0   Steps Identify the interface where the customers are going to connect. Interfaces Configure GlobalProtect Gateway: Use the dropdown list to select the internal interface, IP address, and SSL/TLS Service Profile, and Authentication Profile Client configuration for the internal gateway is not needed if tunneling is not performed Internal Gateway Internal Gateway Authentication Configure GlobalProtect Portal: Use the dropdown list to select the internal interface, IP address, and SSL/TLS Service Profile, and Authentication Profile Add the trusted Root CA Add Agent Configuration Make sure the Connect Method is not On-Demand Add the gateway to the list of internal gateways GP Portal configuration GP Portal Authentication GP Portal Agent configuration Agent Internal Gateway configuration Agent App behavior - always-on       Now connect through the internal gateway:   See Also Reference the GlobalProtect Administrator Guide for any additional help with configuring GlobalProtect: GlobalProtect Administrator's Guide 8.0 (English)   owner: aabdelhalim
View full article
mbutt ‎10-30-2017 06:25 AM
21,751 Views
4 Replies
1 Like
Please see the Apple support article at https://support.apple.com/en-us/HT207828 for the source of this information.   In summary, these releases have the following requirements:   Removes support for TLS connections using SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates.  Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0.  Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy. Note: If the SSL/TLS Service Profile for the GlobalProtect Portal and Gateway support a maximum TLS version of 1.1, then either an iOS 11 nor a Mac OS X 10.13 system will succeed in establishing a connection. Once the configuration is committed with the maximum version set to 1.2 or to "max:, then the GlobalProtect agent will succeed.   Changes coming with iOS 11 Security iOS 11, tvOS 11, and Mac OS High Sierra include the following changes to TLS connections: Removes support for TLS connections using   SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates. Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0.  Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy. Changes coming with Mac OS High Sierra Security macOS High Sierra, tvOS 11, and iOS 11 include the following changes to TLS connections: Removes support for TLS connections using SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates. Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0.  Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy.  
View full article
jjosephs ‎10-25-2017 01:30 PM
17,780 Views
0 Replies
1 Like
Issue Phase 1 Negotiation between IPSec Peer and PAN is being identified as "LAND attack". Receiving the following error entry in the Ikemgr.log: IKE phase-1 negotiation is failed as initiator, main mode. Failed SA: 216.204.241.93[500]-216.203.80.108[500] message id:0x43D098BB. Due to negotiation timeout.   Details If the Proxy IDs have been checked for mismatch, try the following: Configure a filter source peer WAN IP to destination Palo Alto Networks WAN IP > debug dataplane packet-diag set filter match source x.x.x.x destination y.y.y.y Turn on the filter. > debug dataplane packet-diag set filter on Initiate a ping in the reverse path. On a remote machine behind the VPN Peer, ping across the VPN tunnel to a host behind the PAN Firewall. From a host on the remote peer network try to ping a host on the local network behind the PAN Firewall (w.w.w.w) c:\> ping w.w.w.w This should cause the tunnel to be created, and initiate a new Phase1 IPSec negotiation. Run the following command a couple of times: > show counter global filter delta yes packet-filter yes   Look for drops in the output. For example: Global counters: Elapsed time since last sampling: 1.481 seconds name                      value  rate  severity  category  aspect    description ----------------------------------------------------------------------------------------- session_allocated         1      0     info      session   resource  Sessions allocated session_freed             1      0     info      session   resource  Sessions freed flow_policy_nat_land      1      0     drop      flow      session   Session setup: source NAT IP allocation result in LAND attack nat_dynamic_port_xlat     1      0     info      nat       resource  The total number of dynamic_ip_port NAT translate called nat_dynamic_port_release  1      0     info      nat       resource  The total number of dynamic_ip_port NAT release called ----------------------------------------------------------------------------------------- Total counters shown: 5 -----------------------------------------------------------------------------------------   Resolution In this case, the 'flow_policy_nat_land' global counter is showing a 'drop', indicating a configuration issue causing the traffic to be dropped, causing this "timeout" error. In the order to resolve the LAND attack, see: Misconfigured Source NAT and LAND attacks   owner: vvasilasco
View full article
vvasilasco ‎06-08-2017 03:01 AM
65,830 Views
2 Replies
This document descibes the basics of configuring certificates in GlobalProtect setup. Please note that there can be other ways to deploy certificates for GlobalProtect which are not covered in this document.   A. SSL/TLS service profile -  Specifies Portal/gateway server cert, every portal/gateway needs one. B. Certificate profile(if any) - Used by portal/gateway to request client/machine certificate C. Installing client/machine cert in end client   A. SSL/TLS service profile In the context of GlobalProtect, this profile is used to specify GlobalProtect portal/gateway's "server certificate" and the SSL/TLS "protocol version range". If same interface serves as both portal and gateway, you can use the same SSL/TLS profile for both portal/gateway. If portal/gateway are served through different interfaces, you can use same SSL/TLS profile as long as the certificate includes both portal/gateway IPs/FQDNs in its Subject Alternate Name(SAN), if not, create different profiles for portals and gateways as needed.   The pre-requisite to create SSL/TLS profile is to either generate/import the portal/gateway "server certificate" and its chain To import a certificate generated externally, navigate to Device>Certificate Management>Certificates and click on 'import' at the bottom. To generate a certificate on the firewall, navigate to Device>Certificate Management>Certificates and click on 'generate' at the bottom.   If the server cert is signed by a well-known third-party CA or by an internal PKI server 1. Import the Root CA (private key is optional) 2. Import intermediate CAs if any (private key is optional) 3. Import the server cert signed by the above CAs "with" private key.   IMPORTANT! If subj alt name(SAN) does not exist in this cert: This cert's common name(CN) 'must' match the portal/gateway's IP or FQDN . If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be one of the entries in that SAN list. In this case the CN can be anything, it does not matter since only SAN will be used to match IP/FQDN. Should not be of type CA. It must be of type end-entity. As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. Eg. if portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and if the certificate references the fqdn 'vpn.xyz.com', then the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.   4. SSL/TLS profile (Location: Device>Certificate Management>SSL/TLS Service Profile)     -Name  - Give any name for this profile     -Certificate - Reference the server cert from step 3     -Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server   5. Reference this SSL/TLS profile in portal/gateway as needed.   If the server cert needs to be generated on the Palo Alto Networks  firewall 1. Generate a root cert with common name of any unique value. (other than IP or FQDN of portal/gateway)   (Location: Device>Certificate Management>Certificates click Generate at the bottom of the screen)   2. (optional) Generate a intermediate cert signed by above root cert. Specify its common name as any unique value. (other than IP or FQDN of portal/gateway)   3. Generate a sever cert signed by the above intermediate cert. a. This cert's common name 'must' match the portal/gateway's IP or FQDN if subj alt name(SAN) does not exist in this cert. In PAN firewalls, SAN can be created under the optional 'certificate attributes' of type 'hostname', 'IP' or 'email'. b. If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be present in that SAN list. c. Should not be a CA. d. As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. For example. if the portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and the certificate references the fqdn 'vpn.xyz.com', the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.        4. SSL/TLS profile (Location: Device>Certificate Management>SSL/TLS Service Profile)     Name  - Give any name for this profile     Certificate - Reference the server cert from step 3     Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server    5. Reference this SSL/TLS profile in portal/gateway as needed.   B. Certificate Profile (Location: Device>Certificate Management>Certificate Profile) Certificate profile specifies a list of CAs and Intermediate CAs. When this certificate profile is applied to the config, the portal/gateway will send a client certificate request to the client to request for a client/machine cert signed by the CA/intermediate CA specified in the cert profile. It is recommended to place both the root and intermediate CAs in this profile, instead of just root CA.    IMPORTANT! -Client certificate refers to user cert, it can be used for 'user-logon'/'on-demand' connect methods. Used to authenticate a user. -Machine certificate refers to device cert, it can be used for 'pre-logon' connect method. This is used to authenticate a device, not a user.   1. Import the "Root CA" that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key) 2. Import the "intermediate CAs" if any that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key) 3. Go to Device > Certificate Management > Certificate Profile, click Add. 4. Give a name to the profile. 5. Add the root and intermediate CAs from Step 1 & 2.   6. Note: Username field by default is set to 'None', in a typical setup where username is pulled from LDAP/RADIUS authentication, you can leave this to none. On the other hand, if certificates are the only method of authentication, that is, if you do not have RADIUS/LDAP for portal/gateway authentication then you must change username field from none to 'Subj' or 'Subj Alt' to extract username from the client certificate common name or email/principal name. Failing to do this will result in a commit failure. 7. (optional) Check CRL or OCSP if the portal/gateway needs to verify the client/machine cert's revocation status using CRL or OCSP. Please use this with caution as it can result in clients failing to connect if used in conjunction with 'Block session if certificate status is unknown'.   8. Reference this certificate profile portal/gateway as needed.   C. Installing client/machine cert in end client   When importing a client/machine certificate, import it in PKCS format which will contain its private key.   Windows -  1. Click Start>Run, type mmc to open Microsoft certificate management console. 2. Go to File > Add/Remove Snap-in:     IMPORTANT! 3. Click Certificates>Add and select one or both of the below:   a. To add client(user) certificate, select 'My user Account'. This is used for 'user-logon' and 'on-demand' since it authenticates a user. b. To add machine(device) certificate, select 'Computer Account'. This is used for 'pre-logon' as it authenticates a machine.           4. Import client/machine certificate into mmc. a. If you are importing client certificate, import it to 'Personal' Folder under 'My user account' b. If you are importing machine certificarte, import it to 'Personal' Folder under 'Computer Account'       5. Similarly import the Root CA in the 'Trusted Root Certificate Authorities and Intermediate CAs(if any) in the 'Intermediate Certification Authorities'     IMPORTANT! 6. Once imported, double click the imported client/machine certificate to make sure  a. It has private key b. Its certificate chain is full upto its root CA. If the chain is missing root CA or intermediate CA, import them to their respective folders as explained in Step 5.         7. At this point, the certificates are imported on the client, so you can close the mmc console without saving it.
View full article
dreputi ‎02-13-2017 11:46 AM
55,001 Views
8 Replies
3 Likes
Topology Main Site: Dual ISPs Single PAN firewall with dual Virtual Routers and dual VPNs. One ISP is used for all VPN traffic and the other is used for Internet traffic, as well as a backup for the VPN traffic. Remote Site: Single PAN firewall with a single VR and a single ISP. Tunnel156 (in VR2) will be the main VPN tunnel. The workstation will ping the remote site from VR1.  The PBF rule will route the packet to the interface of Tunnel156 in VR2. When the PBF monitor fails the packet uses the default route of the VPN network (tunnel.56) in VR1.   VR1 Setup Configure an IP address on the tunnel interface for PBR monitoring. Setup the static route for VPN/tunnel monitoring traffic.   VR2 Setup Configure IP address for tunnel monitoring. Setup the static route for VPN/tunnel monitoring traffic. Create a return route for the source (route back to the other VR).   PBF Policy   Security Policy   admin@lab‐56‐PA500(active)> show pbf rule all Rule       ID Rule State Action  Egress IF/VSYS NextHop        NextHop Status ====       == ========== ======  ============== ============== ============== VPNtraffic 4  Active     Forward tunnel.156     156.156.156.58 UP Session Flow:   admin@lab‐56‐PA500(active)> show session id 29290 Session 29290   c2s flow:     source: 192.168.56.30[Trust]     dst:    192.168.57.1     proto:  6     sport:  3045    dport:  443     state:   ACTIVE    type:  FLOW     src user: unknown     dst user: unknown     pbf rule: VPNtraffic 4   s2c flow:     source: 192.168.57.1[vr2-vpn]     dst:    192.168.56.30     proto:  6     sport:  443    dport:  3045     state:  ACTIVE  type:  FLOW     src user: unknown     dst user: unknown   start time          : Mon Aug 8 10:16:58 2011   timeout              : 1800 sec   time to live        : 1767 sec   total byte count    : 47632   layer7 packet count  : 129   vsys                : vsys1   application          : ssl   rule                : TrafficVPN   session to be logged at end : True   session in session ager : True   session synced from HA peer : False   layer7 processing    : completed   URL filtering enabled: False   session via syn‐cookies: False   session terminated on host : False   session traverses tunnel : True   captive portal session : False   ingress interface : ethernet1/6   egress interface : tunnel.156   session QoS rule : N/A(class 4)   admin@lab‐56‐PA500(active)> show pbf rule all Rule       ID Rule State Action  Egress IF/VSYS NextHop        NextHop Status ====       == ========== ======  ============== ============== ============== VPNtraffic 4  Active     Forward tunnel.156     156.156.156.58 DOWN   admin@lab‐56‐PA500(active)> show session id 61386 Session 61386   c2s flow:     source: 192.168.56.30[Trust]     dst:    192.168.57.1     proto:  6     sport:  512    dport:  55042     state:   INIT    type:  FLOW     src user: unknown     dst user: unknown     s2c flow:     source: 192.168.57.1[vpn]     dst:    192.168.56.30     proto:  1     sport:  55042  dport:  512     state:  INIT    type:  FLOW     src user: unknown     dst user: unknown     start time          : Mon Aug 8 10:49:18 2011   timeout              : 6 sec   total byte count    : 74   layer7 packet count  : 1   vsys                : vsys1   application          : ping   rule                : TrafficVPN   session to be logged at end : True   session in session ager : False     session synced from HA peer : False   layer7 processing    : enabled   URL filtering enabled: False   session via syn‐cookies: False   session terminated on host : False   session traverses tunnel : True   captive portal session : False   ingress interface : ethernet1/6   egress interface : tunnel.56   session QoS rule : N/A(class 4)   owner: panagent
View full article
panagent ‎01-27-2017 03:25 AM
28,958 Views
3 Replies
Topology   PA-Firewall A (10.129.70.38)  -----  Router (DHCP server) -------  (DHCP IP) PA-Firewall B     Configuration on PA-Firewall B   Interface on Firewall B gets the IP address dynamically from the DHCP server (interface on Router configured as DHCP server).     IKE Gateway       Note: In this example, Local ID is mentioned as FQDN (email address). However, we can use any of the available qualifiers, making sure it is the same on the peer end as well. It could be anything as long as it is same on the other end. This is an important configuration since it is the only way for the peer to identify the dynamic gateway.       Note: Since Firewall B has the dynamic IP address, it needs to be the initiator for the VPN tunnel each time. Hence, do not select "Enable Passive Mode."     IPSec Configuration       Configuration on PA-Firewall A   IKE gateway     Note: Peer Identification on the static peer needs to be the same as Local Identification configured on the dynamic peer. Also, "Peer IP Type" is dynamic here since we are not sure of the IP on the other end.       Note: Since this is the static peer and does not know the IP address of the dynamic end, it would not be able to initiate the VPN. Hence, we selected the option  "Enable Passive Mode."     IPSec Configuration     Initially, when the tunnel is down, we see an ipsec-esp session with destination as 0.0.0.0, since we are not sure of the peer IP.   admin@PA-Firewall-A> show session all -------------------------------------------------------------------------------- ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port]) Vsys Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 1 ipsec-esp ACTIVE TUNN 10.129.72.38[0]/L3-Trust/50 (10.129.72.38[0]) vsys1 0.0.0.0[0]/L3-Untrust (0.0.0.0[0])     Note: L3-Trust is the zone of the tunnel interface and L3-Untrust is the external interface.   As soon as the tunnel comes up, this is replaced with the actual IP address of the dynamic peer:   admin@PA-Firewall-A> show session all -------------------------------------------------------------------------------- ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port]) Vsys Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 11 ipsec-esp ACTIVE TUNN 10.129.72.38[53613]/L3-Trust/50 (10.129.72.38[61655]) vsys1 1.1.1.5[12024]/L3-Untrust (1.1.1.5[43745])  
View full article
hagarwal ‎12-05-2016 04:22 PM
21,930 Views
0 Replies
2 Likes
This document covers the configuration of a multi-site VPN scenario with dual ISPs and quadruple VPN tunnels at each site. This scenario has three sites, two remote branches and one main site. Each location has two ISP connections, the remote branches do not connect directly to each other, only to the main site but with a full mesh configuration (4 tunnels per remote site).   This design will support the loss of a single connection at all of the three sites concurrently while maintaining full connectivity.
View full article
mlutgen ‎05-09-2016 02:54 PM
10,138 Views
0 Replies
Topology is as follows: The Palo Alto Networks firewall is getting its IP address from DHCP. We have to configure the IP Sec tunnel between Palo Alto Networks device and Cisco ASA.The only difference on the Palo Alto Networks firewall is in IKE Gateway. The rest are the same as a normal VPN.   Configuration on Cisco ASA.   1. Define Proxy ACL for interesting traffic: access-list ASA-PA-ACL extended permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0   2. Define Phase 1 policy.   crypto ikev1 policy 110 authentication pre-share encryption aes hash sha group 2 lifetime 86400 crypto ikev1 enable inside   3. Define Preshared Key. tunnel-group DefaultL2LGroup ipsec-attributes ikev1 pre-shared-key cisco   4. Define Phase 2 policy.   crypto ipsec ikev1 transform-set TSET esp-aes-256 esp-sha-hmac   5. Create Dyanamic crypto map for create IPSec tunnel with a dynamic peer. crypto dynamic-map DMAP 110 match address ASA-PA-ACL crypto dynamic-map DMAP 110 set ikev1 transform-set TSET   6. Bind the Dynamic Crypto map with the Static Crypto Map. If multiple IPSec tunnels are running on Cisco ASA, just use an existing Crypto MAP but with a new number.   crypto map CMAP 10 ipsec-isakmp dynamic DMAP   7. Apply the Crypto map on interface. crypto map CMAP interface inside  
View full article
pankaku ‎02-22-2016 06:51 PM
8,770 Views
2 Replies
The following is a sample IPSec tunnel configuration with a Palo Alto Networks firewall connecting to a Cisco ASA firewall.   Phase 1 Proposal Cisco ASA: crypto isakmp policy 10 authentication pre-share encryption 3des hash sha group 2 lifetime 86400   Palo Alto Networks firewall: <ike-crypto-profiles>    <entry name="default">       <encryption>          <member>aes192</member>          <member>aes256</member>          <member>aes128</member>          <member>3des</member>       </encryption>    <hash>       <member>sha1</member>       <member>md5</member>    </hash>    <dh-group>       <member>group2</member>       <member>group1</member>    </dh-group>    <lifetime>       <hours>24</hours>    </lifetime>    </entry> </ike-crypto-profiles>   Phase 2 Proposal Cisco ASA: crypto ipsec transform-set palo-alto esp-aes-256 esp-sha-hmac crypto map outside 20 set transform-set palo-alto   Palo Alto Networks firewall: <ipsec-crypto-profiles>    <entry name="default">       <esp>          <encryption>             <member>aes256</member>          </encryption>          <authentication>             <member>sha1</member>          </authentication>       </esp>       <dh-group></dh-group>       <lifetime>          <hours>24</hours>       </lifetime>    </entry> </ipsec-crypto-profiles> <crypto-profiles>   Gateway Cisco ASA: crypto map outside 20 set peer 10.9.3.8 tunnel-group 10.9.3.8 type ipsec-l2l tunnel-group 10.9.3.8 ipsec-attributes pre-shared-key * isakmp keepalive threshold infinite prompt hostname context Cryptochecksum:2e764f8b78fffa0bef7a212795ec0ebe   Palo Alto Networks firewall: <gateway>    <entry name="XYZ.ASA">       <peer-address>          <ip>10.88.12.253</ip>       </peer-address>       <local-address>          <ip>10.9.3.8/24</ip>          <interface>ethernet1/1</interface>       </local-address>       <authentication>          <pre-shared-key>             <key>k2VXNMN7gOjEFUe6y8ALut8vWzxw5TY0</key>          </pre-shared-key>       </authentication>       <protocol>          <ikev1>             <exchange-mode>auto</exchange-mode>             <ike-crypto-profile>default</ike-crypto-profile>             <dpd>                <enable>yes</enable>                <interval>10</interval>                <retry>3</retry>             </dpd>          </ikev1>       </protocol>    </entry> </gateway>   Phase 2 - Proxy ID/tunnel Cisco ASA: access-list ASAtoPAN extended permit ip 10.211.168.0 255.255.252.0 10.61.0.0 255.255.0.0 crypto map outside 20 match address ASAtoPAN   Palo Alto Networks firewall: <tunnel>    <ipsec>       <entry name="XYZTunnel">          <anti-replay>no</anti-replay>          <copy-tos>no</copy-tos>          <tunnel-monitor>             <enable>no</enable>          </tunnel-monitor>          <tunnel-interface>tunnel.1</tunnel-interface>          <auto-key>             <ike-gateway>                <entry name="XYZ.ASA"/>             </ike-gateway>             <ipsec-crypto-profile>default</ipsec-crypto-profile>             <proxy-id>                <local>10.61.0.0/16</local>                <remote>10.211.168.0/22</remote>             </proxy-id>           </auto-key>        </entry>     </ipsec> </tunnel>     Note: Protocol field under proxy-ID should match on both sides.   owner: panagent
View full article
nrice ‎01-13-2016 10:09 AM
28,414 Views
4 Replies
1 Like
  The IPsec tunnel status always shows in green even if the remote interface is down or when there is no connectivity.   Until the SA renegotiates, the tunnel will still shows as green.   By default, if the IPsec tunnel is up and if your remote device is down then your ipsec tunnel will not go down until ipsec phase 2 life is expired. Once it's expired it will try to re-negotiate and since the interface is down, the tunnel will go down.   Configure Tunnel monitoring on both the ends. Tunnel monitoring is used to keep a VPN tunnel communicating with the other VPN endpoint. If a tunnel monitoring profile is created it will specify one of two action options if the tunnel is not available: wait-recover or fail-over. This uses PING packets to monitor the VPN tunnel connectivity sourced from the Tunnel Interface IP. You need to assign an IP address to the tunnel interface for monitoring.   Wait-recover tells the firewall to wait for the tunnel to recover and not take additional action. Fail-over will force traffic to a back-up path if one is available.   In both cases the firewall will try to negotiate new IPSec keys to accelerate the recovery. This option alerts you of any tunnel failures and to provide automatic failover to another interface.   Other helpful articles: Dead Peer Detection and Tunnel Monitoring How to Verify if the IPSec Tunnel Monitoring is Working?
View full article
rsriramoju ‎12-01-2015 02:27 PM
2,432 Views
0 Replies
Overview A branch firewall behind a DSL modem is configured to establish a VPN tunnel with the headquarters (HQ) firewall, enabling users at the branch to access the HQ network. On the branch side, the modem connects to the untrust interface of the firewall and provides an IP address through DHCP to the interface. The modem injects a default route on the Palo Alto Networks firewall, pointing towards the modem's private IP address. The company now wants to enforce a rule that all internet traffic from branch users be routed through the VPN tunnel and through the HQ firewall, instead of directly out through the untrust interface and the modem. Issue A static route, 0.0.0.0/0 next hop tunnel.1 interface, was added to route branch traffic through the VPN tunnel. This caused a total network outage for the branch users.   Cause Refer to the diagram. Before changing the default route pointing to the tunnel interface, all IKE negotiation and the ESP packets to the VPN peer, 1.2.3.4, egressed via the eth1/2 interface on the branch firewall, using the default route provided by the DSL modem ( 0.0.0.0/0 next hop 192.168.1.254). By changing the default route to the tunnel.1 interface, the ESP packets to 1.2.3.4, which should have egressed via the physical eth1/2 interface must now use the tunnel.1 interface. In effect, the IKE negotiation required to establish a tunnel is being routed through the tunnel it is attempting to create. Therefore, the tunnel cannot be established and the network outage occurs.   Resolution Configure a static route with a lower metric for the route to 1.2.3.4, on eth1/2 interface and next hop 192.168.1.254. Configure similar static routes with a lower metric for the Palo Alto Networks updates server, DNS server (if using the service routes for public DNS servers), and any other server that the Palo Alto Networks firewall contacts using service routes on the eth1/2 interface. You can then add 0.0.0.0/0 pointing out to the tunnel.1 interface, which routes all the internet traffic via the tunnel interface, except the IKE negotiation and ESP traffic (which now uses the eth1/2 interface for negotiations).   Additionally, the following security policies are required: From trust zone to VPN zone on the Branch firewall. This policy would have already been configured for branch users to access the HQ network. The reverse policy would have been configured for HQ users to access the branch network. From VPN zone to untrust zone on the HQ firewall. Optionally, configure the reverse policy for specific scenarios that allow communication to initiate from the untrust zone. Policies can be configured to restrict traffic to specific destination IP addresses.   owner: kprakash
View full article
kprakash ‎09-22-2015 06:16 PM
10,124 Views
1 Reply
Overview PAN-OS 6.0 introduced the ability to use certificates for IKE authentication. This document describes how to configure IKE authentication using self-signed certificates on a pair of Palo Alto Networks firewalls running PAN-OS 6.0.   Steps Generate a CA (Certificate Authority) certificate on one of the Palo Alto Networks firewalls. This certificate will be used to sign the client certificates for the authentication. Export the CA certificate: Then import it into the peer firewall: Now generate on a client certificate on both firewalls and sign each one with the imported CA certificate. PA-3000 Series: PA-2000 Series: Create a Certificate Profile on both firewalls and add the CA certificate, as shown in the following example: Create an IKE gateway on each firewall and select Certificate for the Authentication setting. In the following example, "Distinguished Name" (DN) is used as identification. The DN is the same as the Common Name of the certificate. PA-3000 Series: PA-2000 Series: Create an ipsec tunnel on both firewalls: Send traffic through the vpn tunnel to verify that it comes up. PA-3000 Series: PA-2000 Series:   owner: rvanderveken
View full article
rvanderveken ‎09-09-2015 06:05 PM
35,351 Views
3 Replies
Details For this scenario, the IP address 192.168.200.1/24 is configured on ethernet1/4 and the user wants to run GlobalProtect on the IP address 192.168.200.2:   Steps There are two options to achieve this: Configure the IP address 192.168.200.2 on the interface itself as 192.168.200.2/32: Now, select this IP address in the GlobalProtect configuration after selecting interface ethernet1/4. The second option is to terminate GlobalProtect on the loopback interface and create a NAT policy to perform a destination NAT from 192.168.200.2 to the loopback IP address. See the following link for more information on creating a NAT policy: How to create NAT and Security Policies from the CLI   See Also Fundamentals Guide: Security Policies How to Create a NAT Rule on the CLI   owner: csharma
View full article
bat ‎09-07-2015 04:23 AM
4,208 Views
0 Replies
Details On the Palo Alto Networks firewall, the security zone that is assigned to a specific interface is essential for establishing security policies based on traffic that needs to be allowed, restricted or denied. The same principles of zone selection apply for VPN tunnel interfaces when defining security policies. Two scenarios are shown in this document to demonstrate how security policies are written based on how the security zone for the VPN tunnel interface is chosen: The tunnel interface is assigned the same zone as one of the inside interfaces. The tunnel interface is assigned an independent zone.   Scenario 1 In this scenario, tunnel.200 interface has been assigned to the same zone as the ethernet1/2 interface which is the "L3_Trust" zone. Because of this, any existing security policies (including the implicit 'same-zone' allow rule) that match traffic from source "L3_Trust" zone to destination "L3_Trust" zone will be applied to the VPN traffic flowing between tunnel.200 and inside interface ethernet/12.   Ethernet1/2 is in 'L3_Trust' zone:   Tunnel.200 Interface is placed in the 'L3_Trust' zone:   Pre-existing security policy applied to "L3_Trust" zone: In situations where an "Any/Any/Deny" policy is configured which may override the implicit 'same-zone' policy, a policy must be explicitly created to allow the 'L3-Trust' to 'L3-Trust' zone traffic as shown below: For more information regarding the Any/Any/Deny policy, see: Any/Any/Deny Security Rule Changes Default Behavior   Scenario 2 In this scenario, the tunnel.200 interface is assigned an independent zone called 'VLAN_100' while the inside interface ethernet/12 is in the 'L3_Trust' zone: Ethernet1/2 is in 'L3_Trust' zone:   Tunnel.200 Interface is placed in a separate 'VLAN_100' zone: This approach will allow for a separate set of restrictions to be applied only to traffic flowing to/from the inside interface(ethernet1/2) to/from the VPN "VLAN_100" security zone. This approach will provide more granularity if the security requirement is different for VPN traffic.   New Security Policy created and applied only for traffic from VPN 'VLAN_100' to inside 'L3_Trust' zone:   See Also How to Configure IPSEC VPN   owner: jperry
View full article
jperry1 ‎09-03-2015 06:39 AM
11,537 Views
0 Replies
Overview This document outlines the basic steps involved in establishing a tunnel between a Palo Alto Networks device and a Check Point UTM-1 Edge.  The UTM-1 Edge might also be referred to as VPN-1 Edge, SofaWare, or Safe@Office appliances.  All the named Check Point devices run SofaWare’s Embedded NGX code.  The firmware versions used in this document are: PAN-OS version 4.0.1 SofaWare Embedded NGX version 8.0.42   Note: This document is not relevant to Check Point VPN-1 running on Secure Platform, Nokia IPSO appliances, Solaris or Windows. Navigate to Network > IKE Gateways (click New): Enter Remote IKE Gateway name, Local interface and IP, remote Gateway IP, and Pre-Shared Key. Navigate to Network > Interfaces, and at the bottom of the page choose to create a new Tunnel Interface: Navigate to Network > IPSec Tunnels (click New): Enter a name, choose the tunnel interface (above), and choose the IKE Gateway (above). All other fields are populated automatically. Click Show advanced options and enter local and remote proxy IDs: Click OK: Navigate to Network > Virtual Routers. Open the appropriate VR, and add a static route to the networks behind the Edge device: Be sure that the interface is the tunnel interface from above, and Next Hop is None. Navigate to the Policies tab > Security. Add new rules to allow IKE/IPSec traffic between the gateways, and desired traffic inside the tunnel: Commit the changes. Now we'll set up VPN on the Edge side.   Navigate to VPN > VPN Sites. Click New Sites. Choose Site-to-Site VPN in the Wizard: Enter the IP of the Palo Alto Networks device (must be the same IP configured on the Palo Alto Networks as the Local IP above): Specify VPN configuration: Enter the IP Subnet(s) behind the Palo Alto Networks device: Choose Authentication method of Shared Secret: Enter the pre-shared key configured on the Palo Alto Networks device: Set Security Methods Phase 1 and Phase 2 to Automatic: Allow the tunnel to connect: Give the VPN site a name: Make sure to check Keep this site alive. Verify that the tunnel is established: Send a ping from each side to the other (if allowed by policies): On the Palo Alto Networks device, navigate to the Network Tab > IPSec Tunnels: Verify that the lights are green for both Phase 1 and Phase 2 status. On the UTM-1 Edge, navigate to the Reports > Tunnels tab and verify that the tunnel is established:   owner: jfarkas
View full article
nrice ‎09-02-2015 06:28 PM
13,461 Views
1 Reply
Overview This document describes the steps to configure a security policy to block brute force attacks on the GlobalProtect Portal page.   Steps Create a vulnerability profile. Go Object > Security Profiles > Vulnerability Protection. Click the "Edit" Icon under the Threat Name column to open the Edit Time Attribute dialog. Adjust the number of instances detected from the child signature that is being triggered and adjust the time window to trigger the defined action. The child signature "Palo Alto Networks Firewall VPN Login Authentication Attempt" with ID 32256 is looking for "x-private-pan-sslvpn: auth-failed" from the http response header. The default is 10 hits within a 60-second time window. The screenshot below shows an example of a configured vulnerability profile. When creating the profile, search for the vulnerability ID 40017 in the search bar and check the enable box. Set the action to block-ip. With this option a block time can be configured and tracked by IP source or source and destination. Create a security policy to apply this profile. While creating a security policy, add the IP address of the portal under Destination Address and select the vulnerability profile created in step 1 above.   Follow these steps to test if it is working. This is how the GlobalProtect Portal page appears when users try to authenticate for the first time: Log into the portal using random user names and passwords. The firewall processes incorrect login attempts for the first 9 times. The following screenshot shows the GlobalProtect Portal page during the 9 unsuccessful attempts: After the 9th unsuccessful attempt, the user will not be authenticated even with the correct credentials. The GlobalProtect Portal appears as follows after the 9th unsuccessful attempt: Brute Force Authentication Attempt is identified as the vulnerability threat. This can be seen in the threat logs. Go to Monitor > Logs > Threat. If block-ip action was configured, check the block-list on the CLI with command: debug dataplane show dos block-table   New sessions are set to DISCARD with a tracker stage firewall "mitigation block ip" and end-reason "threat". Global counters show drop counts under the name "flow_dos_drop_ip_blocked", and description "Packets dropped: Flagged for blocking and under block duration by other modules".   owner: schaganti
View full article
schaganti ‎09-01-2015 04:24 AM
13,759 Views
2 Replies
4 Likes
This document describes how to configure a dual ISP for a branch office.   In this scenario, an office is connected to two ISPs with redundancy for outbound connectivity.   This configuration uses a combination of static routing, policy-based forwarding (PBF), and destination interface-based source NAT translation.  The  solution provides automatic outbound internet redundancy without requiring BGP routing protocol between ISPs.   Note: This document has been modified for PAN-OS 5.0 and later.  Multiple external zones are no longer required.   owner: kbrazil
View full article
kbrazil ‎08-28-2015 05:33 PM
29,283 Views
4 Replies
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,524 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,161 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
Overview This document briefly describes how to build a tunnel in the following network scenario: PA-LAN  <=> PAN-FW <=>  Internet   <=> <VPN-Peer> [L3-trust zone]        [L3-untrust zone] The tunnel will encrypt the traffic between PA-LAN and VPN-Peer's public IP address. This scenario raises an issue as the VPN on the Palo Alto Networks firewall is route based, and the following must occur at the same time for the VPN-Peer IP address: The IKE and ESP needs to be forwarded to the Internet gateway The client's traffic (protected traffic) needs to be routed to the tunnel interface Details For this example, the PA-LAN is 192.168.181.0/24 and the public IP address for the VPN-Peer is 10.193.17.21. PA-LAN will access the service on 10.193.17.21. To resolve the issue, follow the steps below: Create a tunnel interface Create a normal IKE gateway, as for a site-to-site vpn Create a normal IPSEC tunnel, as for a traditional site-to-site vpn At this step, a static route would normally be configured to push the traffic to the peer's protected IP address to tunnel interface. Instead, configure a PBF (Policy Based Forwarding) rule: Source Zone: l3-trust Source Address: PA-LAN (for example 192.168.181.0/24), Destination Address: Peer's public IP (for example: 10.193.17.21 Action: forward Egress I/F: tunnel interface (for example tunnel.5) Set an IP address on the tunnel interface. This IP address is not really used and can be set to any unused IP address in the company (for example 172.17.1.1/32). If it is not set, the following error message will appear during commit: Error: pbf rule 'a1': No ip/ipv6 address defined on pbf interface tunnel.5. Error: Failed to parse pbf policy Commit the changes After the commit operation completes, test the connectivity from one of the hosts in PA-LAN. owner: rweglarz
View full article
RafalWeglarz ‎01-15-2014 02:01 AM
6,798 Views
2 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 provides the CLI commands to create an IPSec VPN, including the tunnel and route configuration, on a Palo Alto Networks firewall. Before running the commands, ensure that the IKE and IPSec crypto profiles are configured on the firewall. Note: For the commands listed in this document, it is recommended to use the same IKE and IPSec cryptos for the new IPSec tunnels. Details The following information is used as example data for the commands.   Tunnel: Tunnel.10 (zone = vpn)   Name of the tunnel: NewYork VPN   Virtual Router: Virtual Router 1   IKE Crypto: ike-crypto-profile IKE_Profile   IKE Gateway: NewYork VPN   IPsec Crypto: ipsec-crypto-profile IPsec_Profile   Peer IP address: 100.100.100.1   Subnet on the other side of the tunnel: 192.168.3.0/24 The commands below should be executed in the order listed. > configure # set network interface tunnel units tunnel.10 ipv6 enabled no # set network interface tunnel units tunnel.10 ipv6 interface-id EUI-64 # set network interface tunnel units tunnel.10 comment "NewYork VPN" # set zone vpn network layer3 tunnel.10 # set network virtual-router "Virtual Router 1" interface [ ethernet1/1 ethernet1/2 ethernet1/3 ethernet1/4 tunnel.10 ] # set network ike gateway NewYork VPN protocol ikev1 dpd enable no # set network ike gateway NewYork VPN protocol ikev1 dpd interval 5 # set network ike gateway NewYork VPN protocol ikev1 dpd retry # set network ike gateway NewYork VPN protocol ikev1 ike-crypto-profile IKE_Profile # set network ike gateway NewYork VPN protocol ikev1 exchange-mode auto # set network ike gateway NewYork VPN authentication pre-shared-key key paloalto # set network ike gateway NewYork VPN protocol-common nat-traversal enable no # set network ike gateway NewYork VPN protocol-common passive-mode no # set network ike gateway NewYork VPN peer-address ip 100.100.100.1 # set network ike gateway NewYork VPN local-address interface ethernet1/1 # set network tunnel ipsec NewYork VPN auto-key ike-gateway NewYork VPN # set network tunnel ipsec NewYork VPN auto-key ipsec-crypto-profile IPsec_Profile # set network tunnel ipsec NewYork VPN tunnel-monitor enable no # set network tunnel ipsec NewYork VPN anti-replay yes # set network tunnel ipsec NewYork VPN copy-tos no # set network tunnel ipsec NewYork VPN tunnel-interface tunnel.10 # set network virtual-router "Virtual Router 1" routing-table ip static-route Route_to_NewYork interface tunnel.10 # set network virtual-router "Virtual Router 1" routing-table ip static-route Route_to_NewYork metric 10 # set network virtual-router "Virtual Router 1" routing-table ip static-route Route_to_NewYork destination 192.168.3.0/24 Note: Since the cloning feature is not available through the web UI, the commands above can be used to clone IPSec tunnels on same firewall or copied to another Palo Alto Networks firewall. To view existing configuration, run the show command with the appropriate options. For example: # show network ike # show network tunnel ipsec owner: kadak
View full article
kadak ‎11-20-2013 10:56 AM
51,175 Views
1 Reply
Ask Questions Get Answers Join the Live Community