Management Articles

Featured Article
Packets can drop if there is a Zone Protection Profile that drops IP fragmented traffic.   When the Palo Alto Networks firewall is passing through the VPN, the VPN session in some cases does not come up. The devices might send fragmented IP packets on port 500/4500.     To resolve this, disable the fragmented traffic option in Network > Zone Protection > Packet Based Attack Protection > TCP/IP Drop.   Clear the session between the VPN peers and the VPN should come up.
View full article
achalla ‎12-02-2015 11:34 AM
4,377 Views
0 Replies
Issue In ideal setup we create IPSEC tunnel and use PBF rule to forward the traffic to tunnel if IPSEC vpn failover is required. Note: To configure Dual ISP and automatic VPN failover follow the below document: How to Setup a Palo Alto Networks Firewall with Dual ISPs and Automatic VPN Failover   We also configure the monitoring IP (IP which is across the tunnel) to perform the tunnel monitoring.   If we have overlapping subnet, we will configure source NAT in order to avoid routing issue on the other end of tunnel. With this setup PBF rule might not work and you could see the PBF rule gets disabled   Cause When enabling PBF monitoring, firewall will send keep alive messages with egress interface as source and send the packets out. If we manually ping the monitoring IP sourcing from egress interface IP, this traffic will go through route lookup and NAT lookup. Subsequently this traffic will get source NAT-ed and we will get ping replies. However the keep alive messages will not go through route lookup and for the same reason it will not be NAT-ed. This might cause routing issue on the other end and we might not get keep alive replies which in turn cause our PBF rule to disable.   Rule: PBF VPN1(6) Rule State: Disabled Action: Forward Symmetric Return: No Egress IF/VSYS: tunnel.1 NextHop: 0.0.0.0 Monitor Slot: 1 Monitor IP: 170.66.50.11 NextHop Status: DOWN Monitor: Action:Fail-Over, Interval:3, Threshold:5 Stats: KA sent:2971, KA got:0 , Packet Matched:28675   Workaround Configure a public IP on the tunnel interface and on the other end of tunnel create a static route for this public IP pointing to the tunnel.   owner: skumar1
View full article
skumar1 ‎09-11-2015 01:15 AM
7,506 Views
0 Replies
3 Likes
Overview This document describes how to extract the tunnel ID and context ID for a 'GlobalProtect-site-to-site' LSVPN from the GlobalProtect-Satellite in order to view the tunnel flow information between the satellite and gateway.   Details Use the following CLI command to view the desired GlobalProtect Gateway connection information and make a note of the displayed gateway tunnel ID: > show global-protect-satellite current-gateway gateway (specify gateway fqdn/ip) satellite (specify satellite name)   Example: > show global-protect-satellite current-gateway gateway 10.66.24.94 satellite GP-Satellite GlobalProtect Satellite : GP-Satellite (1 gateways) Gateway Info: 10.66.24.94     Get Config State:         Refresh Time (seconds)           : 7200         Failed Refresh Time (seconds)    : 300         Current Get Config               : success         Max Get Config Retries           : 34         Number Get Config Failed         : 0         Config Timer Activated           : yes         Next Get Config Time (seconds)   : 5502         Cached Get Config Time (seconds) : 0         Failed Reason                    :     Portal Config:         GlobalProtect Gateway Name       : Gateway-FW-94         GlobalProtect Gateway Address    : 10.66.24.94         Priority                         : 1     Gateway Config:         Gateway Tunnel Name              : GP-Gateway-S         Gateway Tunnel Interface         : tunnel.6         Gateway Tunnel id                : 9         Gateway Tunnel IP                : 7.7.7.1         Gateway Additional Tunnel IPs    :         Status                           : Active         Status Time                      : Jan.14 05:44:33         Reason                           : Established           Config Refresh Time (hours)      : 2         IP Address                       : 172.17.1.1         Default Gateway                  : 7.7.7.1         Netmask                          : 255.255.255.255         Access Routes                    : 192.168.94.0/24                                          : 10.66.22.0/23         Denied Routes                    :         Duplicate Routes                 :         DNS Servers                      :         DNS Suffixes                     :         Tunnel Monitor Enabled           : No         Tunnel Monitor Interval          : 0 seconds         Tunnel Monitor Action            : wait-recover         Tunnel Monitor Threshold         : 0 attempts         Tunnel Monitor Source            : 172.17.1.1         Tunnel Monitor Destination       : 7.7.7.1         Tunnel Monitor Status            : No data available ------------------------------------------------------------------------------   Shown above, the tunnel ID is 9. Use the following CLI command to view the tunnel state, tunnel encapsulation details and also to retrieve the context ID: > show running tunnel flow tunnel-id 9 tunnel  GP-Satellite         id:                9          type:              GlobalProtect-site-to-site         local ip:          10.66.24.96         inner interface:   tunnel.6         outer interface:  ethernet1/3         ssl cert:          N/A         active users:      1   assigned-ip      remote-ip        MTU   encapsulation ------------------------------------------------------------- 7.7.7.1          10.66.24.94      1420  IPSec SPI CC9CC223 (context 8)   Shown above, the context ID is 8. Use the following CLI command to view the encap/decap context, local/remote SPI values, tunnel monitoring sent/reply packets and other required details: > show running tunnel flow context 8 tunnel  GP-Satellite         id:                     9         en/decap context type:  SSL-VPN         encap type:             IPSec         gateway id:             7.7.7.1         local ip:               10.66.24.96         peer ip:                10.66.24.94         inner interface:        tunnel.6         outer interface:        ethernet1/3         state:                  active         session:                2433         tunnel mtu:             1420         lifetime remain:        1462 sec         idled for:              1 seconds         idle timeout:           432000 seconds         monitor:                off         monitor packets seen:   0         monitor packets reply:  0         en/decap context:       8         local spi:              CC9CC223         remote spi:             66291F47         key type:               GlobalProtect-site-to-site         protocol:               ESP/UDP[4501->4501]         auth algorithm:         SHA1         enc  algorithm:         AES128         anti replay check:      yes         copy tos:               no         authentication errors:  0         decryption errors:      0         inner packet warnings:  0         replay packets:         0         packets received           when lifetime expired:0           when lifesize expired:0         sending sequence:       0         receive sequence:       0         encap packets:          0         decap packets:          11594         encap bytes:            0         decap bytes:            14494560         key acquire requests:   0         owner state:            0         owner cpuid:            s1dp0         ownership:              1   Note: In LSVPN, the tunnel type is 'GlobalProtect-site-to-site' as shown above. Using the tunnel ID value 9 with the following CLI command, which is meant to view the 'IPSec site-to-site' VPN tunnel flow will result in a server error message as shown below: > show vpn flow tunnel-id 9 Server error : tunnel type is not IPSec   owner: gchadrasekeran
View full article
gchandrasekaran ‎09-10-2015 12:48 PM
12,408 Views
3 Replies
1 Like
Issue GlobalProtect Satellite is unable to connect to the GlobalProtect Portal resulting in the Portal Status: 'invalid http response. return error(Satellite certificate generation failed)':   Resolution From the WebGUI, go to the GlobalProtect Portal > Satellite Configuration and ensure that an 'Issuing Certificate' is present. If not present, add the issuing certificate and perform a commit. Note: For satellites to connect to the gateway, a satellite certificate needs to be presented to the gateway in order for the gateway to authenticate the satellite. Hence, the portal needs to issue the satellite its 'satellite certificate' for which an Issuing Certificate is required to be configured on the portal as shown below:   On the GlobalProtect Portal, go to Device > Certificate Management > Certificates > Device Certificates to view the Satellite Certificate created by the Portal as shown below:   On the GlobalProtect Satellite, go to Network > IPSec Tunnels > GP-Satellite and click on 'Gateway Info' to verify for successful satellite connection to the gateway as shown below:   owner: gchandrasekaran
View full article
gchandrasekaran ‎09-09-2015 10:09 AM
2,756 Views
0 Replies
Details When a GlobalProtect Satellite establishes a connection to a GlobalProtect gateway, users have the option to manually make the GlobalProtect Satellite refresh the GlobalProtect gateway config or reconnect to the GlobalProtect gateway.   Reconnect to gateway: From the WebGUI: In order to make the GlobalProtect Satellite reconnect to the GlobalProtect gateway, go to Network > IPSec Tunnels > GlobalProtect Satellite. Click on "Gateway Info" and check the gateway config and click "Reconnect to GW" as shown below:   From the CLI: Use the following CLI command to make the GlobalProtect Satellite reconnect to the GlobalProtect gateway:   > test global-protect-satellite gateway-reconnect satellite GP-Satellite gateway-address 10.66.24.94 method activation Please use "show global-protect-satellite current-gateway gateway 10.66.24.94 satellite GP-Satellite" to check gateway info > show global-protect-satellite current-gateway gateway 10.66.24.94 satellite GP-Satellite  GlobalProtect Satellite : GP-Satellite (1 gateways) Gateway Info: 10.66.24.94 Get Config State: Refresh Time (seconds)          : 7200 Failed Refresh Time (seconds)    : 300 Current Get Config              : success Max Get Config Retries          : 34 Number Get Config Failed        : 0 Config Timer Activated          : yes Next Get Config Time (seconds)  : 7162 Cached Get Config Time (seconds) : 0 Failed Reason                    : Portal Config: GlobalProtect Gateway Name      : Gateway-FW-94 GlobalProtect Gateway Address    : 10.66.24.94 Priority                        : 1 Gateway Config: Gateway Tunnel Name              : GP-Gateway-S Gateway Tunnel Interface        : tunnel.6 Gateway Tunnel id                : 9 Gateway Tunnel IP                : 7.7.7.1 Gateway Additional Tunnel IPs    : Status                          : Active Status Time                      : Jan.19 21:12:03 Reason                          : Tunnel monitoring up Config Refresh Time (hours)      : 2 IP Address                      : 172.17.1.1 Default Gateway                  : 7.7.7.1 Netmask                          : 255.255.255.255 Access Routes                    : 192.168.94.0/24 Denied Routes                    : Duplicate Routes                : DNS Servers                      : DNS Suffixes                    : Tunnel Monitor Enabled          : Yes Tunnel Monitor Interval          : 3 seconds Tunnel Monitor Action            : wait-recover Tunnel Monitor Threshold        : 5 attempts Tunnel Monitor Source            : 172.17.1.1 Tunnel Monitor Destination      : 7.7.7.1 Tunnel Monitor Status            : Up   Note: Users can also manually trigger the GlobalProtect Satellite to disconnect or initially connect to the GlobalProtect gateway using the following CLI command: > test global-protect-satellite gateway- > gateway-connect      Trigger GlobalProtect satellite connects to gateways > gateway-disconnect  Trigger GlobalProtect satellite disconnects from gateways > gateway-reconnect    Trigger GlobalProtect satellite reconnects to gateways   Refresh the gateway config: From the WebGUI: In order to make the GlobalProtect Satellite retrieve any config changes made to the GlobalProtect gateway, go to Network > IPSec Tunnels > GlobalProtect Satellite. Click on "Gateway Info" and check the gateway config and click "Refresh GW Config", as shown below:   From the CLI: Use the following CLI command to refresh the gateway config: > request global-protect-satellite get-gateway-config gateway-address 10.66.24.94 satellite GP-Satellite Please use command "show global-protect-satellite current-gateway gateway 10.66.24.94 satellite GP-Satellite" to display gateway connection status   Note: Usually GlobalProtect Satellites refresh the gateway configuration for the hour value configured in the GlobalProtect Gateway Satellite config as shown below. The default value is 1 hour and maximum value is 48 hours.   owner: gchandrasekaran
View full article
gchandrasekaran ‎09-09-2015 10:02 AM
7,796 Views
0 Replies
1 Like
PAN-OS 7.0 and below: The limit for a pre-shared key is 64 characters.   owner: panagent
View full article
panagent ‎09-09-2015 09:08 AM
4,601 Views
1 Reply
Issue In this scenario a GlobalProtect satellite is successfully connected to a GlobalProtect Gateway as shown below:   As shown above in the 'Route Sharing' column, the GlobalProtect Gateway is advertising the subnet 192.168.94.0/24 to the satellite. A new access route of the subnet 10.66.22.0/23 is added in the GlobalProtect Gateway config to be published to the satellite, as shown below:   However, this newly added access route 10.66.22.0/23 is still not received by the satellite and the gateway information did not change to display 10.66.22.0/23, as shown below:   Resolution On the GlobalProtect Satellite, go to Network > IPSec Tunnels > GP-Satellite and click on "Gateway Info":   Check the gateway config and click "Refresh GW Config", as shown below to retrieve any changes made on the gateway such as receiving an access route:   The GlobalProtect satellite now has a route to reach the subnet 10.66.22.0/23 behind the GlobalProtect gateway. By default, the GlobalProtect satellite refreshes the config from gateway for the hours value specified in the GlobalProtect gateway satellite config, as shown below (default is 1 hour and max value is 48 hours):   Note: To refresh the gateway config through the CLI, and to verify the access routes added on the GlobalProtect satellite, use the following CLI commands: > request global-protect-satellite get-gateway-config gateway-address 10.66.24.94 satellite GP-Satellite Use the command:  > show global-protect-satellite current-gateway gateway 10.66.24.94 satellite GP-Satellite to display the gateway connection status > show global-protect-satellite current-gateway gateway 10.66.24.94 satellite GP-Satellite GlobalProtect Satellite : GP-Satellite (1 gateways) Gateway Info: 10.66.24.94 Get Config State: Refresh Time (seconds)           : 7200 Failed Refresh Time (seconds)    : 300 Current Get Config               : success Max Get Config Retries           : 34 Number Get Config Failed         : 0 Config Timer Activated           : yes Next Get Config Time (seconds)   : 6081 Cached Get Config Time (seconds) : 0 Failed Reason Portal Config: GlobalProtect Gateway Name       : Gateway-FW-94 GlobalProtect Gateway Address    : 10.66.24.94 Priority                         : 1 Gateway Config: Gateway Tunnel Name              : GP-Gateway-S Gateway Tunnel Interface         : tunnel.6 Gateway Tunnel id                : 9 Gateway Tunnel IP                : 7.7.7.1 Gateway Additional Tunnel IPs    : Status                           : Active Status Time                      : Jan.14 03:12:57 Reason                           : Established Config Refresh Time (hours)      : 2 IP Address                       : 172.17.1.1 Default Gateway                  : 7.7.7.1 Netmask                          : 255.255.255.255 Access Routes                    : 192.168.94.0/24 : 10.66.22.0/23 Denied Routes                    : Duplicate Routes                 : DNS Servers                      : DNS Suffixes                     : Tunnel Monitor Enabled           : No Tunnel Monitor Interval          : 0 seconds Tunnel Monitor Action            : wait-recover Tunnel Monitor Threshold         : 0 attempts Tunnel Monitor Source            : 172.17.1.1 Tunnel Monitor Destination       : 7.7.7.1 Tunnel Monitor Status            : No data available   See Also How to Configure GlobalProtect Satellite Large Scale VPN (LSVPN) Deployment Guide   owner: gchandrasekeran
View full article
gchandrasekaran ‎09-09-2015 07:43 AM
4,075 Views
0 Replies
Details When a customer creates a Client Certificate Profile and enables "Use CRL", the CRL files should be in Distinguished Encoding Rules (DER) format:   Use the following CLI command to verify the use of CRL is enabled: > show system setting ssl-decrypt setting vsys                          : vsys1 Forward Proxy Ready           : yes Inbound Proxy Ready           : yes Disable ssl                   : no Disable ssl-decrypt           : no Notify user                   : no Proxy for URL                 : no Wait for URL                  : no Block revoked Cert            : yes Block timeout Cert            : no Block unknown Cert            : no Cert Status Query Timeout     : 5 URL Category Query Timeout    : 5 Use Cert Cache                : yes Verify CRL                    : yes   Verify OCSP                   : no CRL Status receive Timeout    : 5 OCSP Status receive Timeout   : 5   If Verify CRL is shown as "no", it can be enabled with the following CLI commands: > configure # set deviceconfig setting ssl-decrypt crl yes # commit   Additional Information on Debug Commands Enable debug: > debug sslmgr on debug Note: Run the debug mode for 3 to 4 hours to cover at least a couple of "Next Update" time periods for the CRL in question, and collect the Tech Support file.   Collect the file every half of "Next Update" time period: > show clock > debug sslmgr statistics > debug sslmgr tar-all-crl > debug sslmgr view crl <value>   Disable debug: > debug sslmgr on info   Clear the CRL cache on the CP and DP: > debug sslmgr delete crl all > debug dataplane reset ssl-decrypt certificate-cache   For more information review the OpenSSL online manual:  http://www.openssl.org/docs/apps/crl.html   owner: kkondo
View full article
kkondo ‎09-08-2015 04:45 PM
5,958 Views
0 Replies
Symptoms After a user changed active directory password, the GlobalProtect client runs into authentication issues   Issue When using SSO, the GlobalProtect client uses credentials entered at the time the user logged on. Changing the password does not automatically send the new credentials to the client so it will continue to use the old password, which cause issues in some cases.   Resolution It is recommended for the user to log out and log back in so that the SSO picks up the new credentials.   owner: kalavi
View full article
npare ‎09-08-2015 07:28 AM
3,106 Views
0 Replies
Symptoms Two interfaces are used to connect to different internet providers, and are configured in different zones. A single IPSec gateway has been configured on one of those interfaces. Logs show that ESP traffic is being dropped when the local firewalls opens the tunnel. When the remote site initiates the VPN connection, phase 1 fails and the tunnel never comes up   Issue When two internet providers are used, there is a possibility for VPN traffic to arrive via either providers. For example, the tunnel will be established via the provider connected to the interface on which the gateway was configured to use, but return traffic might take a different path and be received by the other interface. Because both public facing interfaces are configured in different zones, if the tunnel was opened in one zone, return traffic received via another zone will be dropped because a session from that zone was never opened.   Resolution To allow return traffic from another interface, two things can be done Configure both public interfaces to be in the same zone Use a loopback address in the same zone as the interface on which the gateway is configured on   owner: swhyte
View full article
npare ‎09-07-2015 05:26 AM
1,743 Views
0 Replies
Yes. Follow the steps below to configure on-demand and pre-login:   Steps Go to Network > GlobalProtect > Portals and select desired portal. Go to Client Configuration and select the 'on demand' Correct Method for the User/User Group that need on-demand access. For pre-logon, click on Add under Client Configuration and select 'pre logon' for select users that need pre-logon access.   owner: ashaikh
View full article
ashaikh ‎09-03-2015 02:50 PM
2,906 Views
0 Replies
Overview Manual Key VPNs is not the preferred method of establishing VPNs because the session keys can be compromised when relaying the key information between the peers. This poses a risk to the data being sniffed if the keys are known. However, in some circumstances manual key VPNs may be required for deployment. For example: When the Palo Alto Networks device is establishing a VPN with a legacy router When we want to reduce the overhead of generating session keys   This document explains how to set up Manual Key VPNs.   Details The screenshot below shows the mandatory fields (marked in yellow) while configuring the manual key VPNs. A best practice in configuring the tunnel is to include all the details and match them with the settings on the peer. Specify the Authentication and Encryption algorithm from the respective drop-downs. Enter the keys in Hex format and make sure each of the key sizes match the selected algorithms. For example, SHA1 requires that you have a pattern in xxxxxxxx format repeated 5 times with a ' - ' separator between each pattern. For example, a valid SHA1 key is "12345678-12345678-12345678-12345678-12345678". A valid key for aes128 is "abcdef12-abcdef12-abcdef12-abcdef12".   The local and the remote SPIs are also in Hex format. Make sure that their values match between the local device and the remote peer. The example screenshot below shows the local SPI as :0023abcd: and the remote SPI as "1234abcd". Select the Interface and the IP address from where the ESP/AH packets would be sourced from, and then configure the tunnel's remote peers IP address.   owner: kprakash
View full article
kprakash ‎09-03-2015 04:48 AM
3,081 Views
0 Replies
Issue The following error display after commit: Commit error: Tunnel interface tunnel.x multiple binding limitation (10) reached.   Cause There is a limit on the maximum number of Proxy IDs per Phase 2.   Resolution To implement VPNs with more than 10 Proxy IDs, configure another tunnel with the same Phase 1 and second Phase 2. or SuperNet the proxy IDs. For example, instead of using 10.1.0.0/16, 10.2.0.0/16, the range can be supernetted to 10.0.0.0/8 to avoid multiple entries.   To configure the first VPN: Go to Network > Interfaces. Create a new tunnel interface. Assign the following parameters: Name tunnel.2 Virtual router Select the existing virtual router. ZoneSelect the Layer 3 internal zone from which the traffic will originate. Go to Network > Network Profiles > IKE Gateways screen to configure the IKE Phase 1 gateway on this screen. Click New and enter: IKE gateway gw-to-siteX, or any name of your choosing. Local IP address  Select the firewall interface closest to the other VPA endpoint. This is the “public” interface of the firewall. Peer IP address Enter the IP address of the “public” interface on the other VPN endpoint. Pre-shared Key Enter a key of your choosing, and remember it so you can enter it in the other firewall’s VPN configuration. To configure the IKE Phase 2 VPN, go to Network > IPSec Tunnels. Create a new VPN with the following parameters: Name vpn-to-siteX, or any name of your choosing. Tunnel interface Pull down to select tunnel.2 IKE gateway Pull down to select the IKE gateway you created in the previous step Next, build your Proxy IDs. Remember the limit is 10:     When creating your second IPSec tunnel, you can refer to the same IKE Gateway. Remember to use a different tunnel interface (in this example, tunnel.3):   You cannot duplicate the Proxy IDs from the first tunnel. They must have at least one element that's different. You can use different Local Proxies in your list of 10.   Note: From PAN-OS 5.0, the Proxy ID limitation has been increased to 250 except on the Palo Alto Networks PA-200, which has a limit of 25 Proxy IDs. Throughput on tunnels with 250 proxy IDs configured is similar to tunnels with only one configured. Each Proxy ID counts towards the platform limit for VPN tunnels.   owner: dlorenzen
View full article
dlorenzen ‎09-01-2015 03:19 AM
12,785 Views
8 Replies
2 Likes
If the IKE traffic is terminated on a Cisco device, it can contain a Cisco vendor ID field.  If the Cisco vendor ID field is seen in IKE packets by the App-ID it will be identified as 'ciscovpn' application.   owner: nmiletic
View full article
nmiletic ‎08-31-2015 09:28 AM
3,582 Views
1 Reply
The Palo Alto Networks GlobalProtect Client supports both AES128 CBC and AES256 CBC encryption algorithms.  RC4 encryption is currently not supported.   owner: gcapuno
View full article
gcapuno ‎08-31-2015 07:13 AM
2,789 Views
0 Replies
Symptom Policy is configured to block traffic with source address 'CN,' yet policy never matches for traffic sourcing from CN region.   Issue A custom object named 'CN' under Objects > Regions was created. This causes the idmanager mapping to associate 'CN' with the custom region object instead of the predefined CN country address block.   To confirm association with custom region object, run the following command: >debug device-server dump idmgr type vsys-region all ID        Name ---------- -------------------- 1024      vsys1+CN Type: 35 Last id: 1025   Resolution Reset the idmanager mapping for the region objects to clear this association, then run a force commit with the following commands: >debug device-server reset id-manager type vsys-region vsys-region ID manager is unset! Please commit the config again. # commit force   To confirm that the old mapping is no longer there, run the following command again and make sure the region object no longer shows in the output. >debug device-server dump idmgr type vsys-region all   owner: achitwadgi
View full article
goku123 ‎08-27-2015 12:54 PM
11,297 Views
5 Replies
1 Like
Overview This document explains the differences between the normal IPSEC tunnel monitoring and LSVPN tunnel monitoring.   Details IPSEC Tunnel Monitoring: The tunnel monitors for the specific IP address mentioned in the 'destination field' as below, there are ICMP echo requests that are sent at specific intervals to check if the destination specified is alive. In case there is no response for the specified number of requests, the destination is considered not reachable and fail over occurs:   LSVPN Tunnel Monitoring: In contrast to IPSEC tunnel monitoring, the IP address given in the destination field is monitored by the satellite devices. If no IP is configured, the satellites will monitor the gateway's tunnel interface address:   The setting needs to be configured only on the gateways. This will automatically be pushed to the satellites. Once the primary gateway fails, traffic from the satellites would be diverted to secondary gateway.   owner: rrajendran
View full article
rrajendran ‎08-26-2015 06:30 AM
4,281 Views
0 Replies
The following applications are recommended for inclusion to security policies on a Palo Alto Networks device to allow Cisco VPN: ciscovpn ike ipsec-ah ipsec-esp ipsec-esp-udp ssl   Ike, ipsec-esp and ciscovpn are almost always seen in the logs, while the other applications in the list are seldom seen.   owner: pvemuri
View full article
pvemuri ‎08-26-2015 06:21 AM
2,564 Views
0 Replies
Overview GlobalProtect Portal configuration is required to provide configuration information to all GlobalProtect clients and/or GlobalProtect satellites (such as gateway information, certificates to be used for authentication or categories to be used for submitting host information).   Details Configuring only the GlobalProtect Portal will not allow the commit to succeed if there is no Client Configuration or Satellite Configuration configured for the respective Portal Configuration resulting in the following error: missing both client config and satellite config (Module: sslvpn) Commit failed   Hence, always ensure that at least any one of the configurations (Client or Satellite) is configured depending on the requirement for the commit to succeed. Shown below is a sample Client Configuration: Shown below is a sample Satellite Configuration:   Note: In scenarios where both Portal and Satellite configurations are present, accessing the GlobalProtect Portal (page https:// <portal-IP>) will not display any data, as there is no Client Configuration present. The GlobalProtect Portal certificate warning might be seen if the trusted CA is not imported in the web-browser, but the GlobalProtect Portal login page will be not displayed.   See Also GlobalProtect Configuration Tech Note How to Configure GlobalProtect Satellite Large Scale VPN (LSVPN) Deployment Guide   owner: gchandrasekaran
View full article
gchandrasekaran ‎08-25-2015 08:44 AM
4,533 Views
0 Replies
Symptom There is site-to-site IPSec excessive rekeying on one tunnel on system logs, while other tunnels are not duplicating this behavior.   Cause There are three possible causes to this issue: Tunnel Monitoring is enabled while there is no IP address configured on the tunnel. Tunnel monitoring use the tunnel IP address as source of tunnel monitoring ICMP packets. Tunnel Monitoring is enabled while there is no corresponding Proxy-ID for the tunnel IP address and IP address being monitored. For Access Control List (ACL) based IPSec VPN, Proxy-ID pair for the corresponding tunnel IP address and IP address being monitored is needed. Note: There is no need for Proxy-ID for tunnel to tunnel IP Address Tunnel Monitoring between Palo Alto Networks firewall. It is possible this is not an issue and that Palo Alto Networks firewall is just logging normal rekey for multiple tunnels. This is true if rekey interval is very short and there are multiple Proxy-ID pairs.   To verify on the Palo Alto Networks firewall use the following CLI commands: Verify IKE debug level > debug ike global show Change IKE debug level to debug > debug ike global on debug To observe IKE messages > tail follow yes mp-log ikemgr.log Return debug level to normal after troubleshooting > debug ike global on normal   Details For issue 1: Configure an allocated IP address on the IPSec tunnel, or disable tunnel monitoring if not needed. For issue 2: Configure Proxy-ID for corresponding tunnel IP address and IP address being monitored, or disable tunnel monitoring if not needed. For issue 3: Check rekey interval on IKE Phase1 and IKE Phase2.   Use the following CLI command to show VPN gateway: > show vpn gateway     GwID   Name     Peer Address/ID            Local Address/ID           Protocol   Proposals -------- ----     ---------------            ----------------           --------   ---------   10     GW-1     1.1.1.1(ipaddr:1.1.1.1)    2.2.2.2(ipaddr:2.2.2.2)    Main       [PSK][DH2][AES256][SHA1] 300-sec      <<== rekey too short   > show vpn tunnel   TnID Name(Gateway)            Local Proxy IP  Ptl:Port  Remote Proxy IP  Ptl:Port  Proposals ---- -------------            --------------  --------  ---------------  --------  --------- 100  TUN-1:ProxyPair1(GW-1)   192.168.1.0/24    0:0     192.168.31.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec     <<== rekey too short 100  TUN-1:ProxyPair2(GW-1)   192.168.2.0/24    0:0     192.168.32.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec     <<== rekey too short 100  TUN-1:ProxyPair3(GW-1)   192.168.3.0/24    0:0     192.168.33.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec     <<== rekey too short <output cut> 100  TUN-1:ProxyPair24(GW-1)  192.168.24.0/24   0:0     192.168.54.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec     <<== rekey too short 100  TUN-1:ProxyPair25(GW-1)  192.168.25.0/24   0:0     192.168.55.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec     <<== rekey too short   Observing the following logs shows the SPI key is being rekeyed every 3mins+. Since there are multiple Proxy-ID pairs on the TUN-1 tunnel, there are frequent rekeys because of the settings lifetime 5mins. The logs appear to be consecutive rekeys and are actually from different tunnels rekeying within the 5mins interval. All multiple Proxy-ID will rekey 5mins and from the logs perspective appears to be too many.   To verify, pick the SPI from the tunnel that exhibiting frequent rekey, use match by PEER-VPN-IP-ADDRESS. > show log system direction equal backward | match 1.1.1.1 2014/02/24 13:43:04 info     vpn     TUN-1 ike-neg 0  IKE phase-2 negotiation is started as initiator, quick mode. Initiated SA: 2.2.2.2[500]-1.1.1.1[500] message id:0x6F845F96. 2014/02/24 13:43:04 info     vpn     TUN-1 ike-neg 0  IKE phase-2 negotiation is succeeded as initiator, quick mode. Established SA: 2.2.2.2[500]-1.1.1.1[500] message id:0x6F845F96, SPI:0xDBE7425F/0xC3D97F6B. 2014/02/24 13:43:04 info     vpn     TUN-1 ipsec-k 0  IPSec key installed. Installed SA: 2.2.2.2[500]-1.1.1.1[500] SPI:0xDBE7425F/0xC3D97F6B lifetime 300 Sec lifesize 128000 KB.   Using the following command, choose only logs related to the SPI: > grep pattern 0xDBE7425F mp-log ikemgr.log   Established SA: 2.2.2.2[500]-1.1.1.1[500] message id:0xB6DF139C, SPI:0xDBE7425F/0xC3D97F6B 2014-02-24 13:43:04 [INFO]: ike_pfkey.c:339:sadb_log_add(): SADB_UPDATE ul_proto=255 src=1.1.1.1[500] dst=2.2.2.2[500] satype=ESP samode=tunl spi=0xDBE7425F authtype=SHA1 enctype=AES256 lifetime soft time=300 bytes=0 hard time=300 bytes=0 Installed SA: 2.2.2.2[500]-1.1.1.1[500] SPI:0xDBE7425F/0xC3D97F6B lifetime 300 Sec lifesize unlimited Deleted SA: 2.2.2.2[500]-1.1.1.1[500] SPI:0xDBE7425F/0xC3D97F6B 2014-02-24 13:46:40 [INFO]: SADB_DELETE ul_proto=0 src=2.2.2.2[500] dst=1.1.1.1[500] satype=ESP spi=0xDBE7425F 2014-02-24 13:46:40 [INFO]: received PFKEY_DELETE seq=0 satype=ESP spi=0xDBE7425F   Start: 13:43:04 End: 13:46:40   Resolution Approximately, rekey every 3 mins+ for every tunnel will create what appears to be that excessive rekey is normal. Increase the rekey value to balance or suit requirements.   owner: jlunario
View full article
pagmitian ‎08-25-2015 07:47 AM
27,777 Views
1 Reply
Issue Palo Alto Networks GlobalProtect Client on a MacOS system keeps reconnecting. The following error messages appear in PanGPS.log: Jun 25 11:28:56:456493 Debug( 40): SCDynamicStoreCopyValue(State:/Network/Global/DNS) failed: No such key Jun 25 11:28:56:456516 Error( 328): pan_SC_GetPropertyList(State:/Network/Global/DNS) failed Jun 25 11:28:56:456525 Error( 537): failed to prepare sysconf Jun 25 11:28:56:456669 Debug( 894): ProcMonitor: do_disconnect() Jun 25 11:28:56:456677 Info ( 908): VPN disconnect. The reason is Internal error. Notify server   Cause SubKey "Network/Global/DNS" is necessary for Global Protect Client on Mac to work. To verify, run the "scutil" command on the Mac and type "list": $ scutil > list   subKey [0] = Plugin:IPConfiguration   subKey [1] = Plugin:InterfaceNamer   subKey [2] = Setup:    :   subKey [73] = State:/Network/Global/DNS   subKey [74] = State:/Network/Global/IPv4   subKey [75] = State:/Network/Global/Proxies   If the subKey "Network/Global/DNS" doesn't exist, that means there's no DNS setting on any of network interfaces configurations.   Resolution Add a DNS server IP address in the network settings on the Mac. System Preferences... > Network > Ethernet > Advanced... > DNS > DNS Servers   owner: ymiyashita
View full article
ymiyashita ‎08-21-2015 07:42 AM
9,758 Views
0 Replies
Overview This document describes how to extract the tunnel ID and context ID for a 'GlobalProtect-site-to-site' LSVPN from the GlobalProtect Gateway in order to view the tunnel flow information between the gateway and satellite.   Details Use the following CLI command to view the desired gateway tunnel information, corresponding tunnel encapsulation details and make a note of the displayed context ID: > show global-protect-gateway flow-site-to-site name (specify the tunnel name)   Example: > show global-protect-gateway flow-site-to-site name GP-Gateway-S   tunnel  GP-Gateway-S         id:                4         type:              GlobalProtect-site-to-site         local ip:          10.66.24.94         inner interface:  tunnel.7        outer interface:  ethernet1/3         ssl cert:          GP-Server-Cert         active users:      2   assigned-ip      remote-ip        MTU  encapsulation ----------------------------------------------------------------------------------------------- 172.17.1.1      10.66.24.96      1420  IPSec SPI 589EA620 (context 8) 7.7.7.2          10.66.24.96      1420  IPSec SPI 589EA620 (context 8)   Shown above, the context ID is 8. Use the following CLI command to view the encap/decap context, local/remote SPI values, tunnel monitoring sent/reply packets and other required details: > show running tunnel flow context 8   tunnel  GP-Gateway-S         id:                    4         en/decap context type:  SSL-VPN         encap type:            IPSec         gateway id:            172.17.1.1         local ip:              10.66.24.94         peer ip:                10.66.24.96         inner interface:        tunnel.7         outer interface:        ethernet1/3         state:                  active         session:                0         tunnel mtu:            1420         lifetime remain:        2939 sec         idled for:              660 seconds         idle timeout:          432000 seconds         monitor:                off         monitor packets seen:  0         monitor packets reply:  0         en/decap context:      8         local spi:              589EA620         remote spi:            7117F9E7         key type:              GlobalProtect-site-to-site         protocol:              ESP/UDP[4501->4501]         auth algorithm:        SHA1         enc  algorithm:        AES128         anti replay check:      yes         copy tos:              no         authentication errors:  0         decryption errors:      0         inner packet warnings:  0         replay packets:        0         packets received           when lifetime expired:0           when lifesize expired:0         sending sequence:      3787         receive sequence:      0         encap packets:          3787         decap packets:          0         encap bytes:            4534560         decap bytes:            0         key acquire requests:  0         owner state:            0         owner cpuid:            s1dp0         ownership:              1   Note: In LSVPN, the tunnel type is 'GlobalProtect-site-to-site', as shown above. Using the tunnel ID value 4, with the following CLI command, which is meant to view the 'IPSec site-to-site' VPN tunnel flow type will result in a server error message, as shown below: > show vpn flow tunnel-id 4   Server error : tunnel type is not IPSec   Also, using the tunnel ID value 4, with the following CLI command, which is meant to view the 'GlobalProtect-Gateway' VPN tunnel flow type will result in a server error message, as shown below: > show global-protect-gateway flow tunnel-id 4   Server error : tunnel type is not GlobalProtect-Gateway   owner: gchandrasekaran
View full article
gchandrasekaran ‎08-19-2015 12:45 PM
5,059 Views
0 Replies
1 Like
Overview The Tunnel Monitor feature is a very useful feature for checking a connection to an IP address situated behind the tunnel. This feature can be used to do an automatic failover to another interface, if needed. Or it can continuously send pings through the tunnel so it keeps it alive even if there is no real user traffic. The following example explains the logs that are generated when the tunnel monitor feature goes down/up. Details When a monitored IP appears down, the system log: "tunnel-status-down" is created. The message shown below is from a VPN and contains the name of the tunnel that went down. The message also has an info level of severity, so if there is a need for a notification to be created through email or an external syslog server, forward the informational level of messages. From the CLI command see the following output: admin@PA-200(active) > show log system direction equal backward subtype equal vpn eventid equal "tunnel-status-down" Time                Severity Subtype Object EventID ID Description =============================================================================== 2014/08/13 15:54:57 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/13 15:54:57 low      vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is down 2014/08/13 15:29:40 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/13 10:08:52 low      vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is down 2014/08/13 10:08:34 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/13 10:08:34 low      vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is down 2014/08/13 10:07:07 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/13 10:06:24 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/13 10:02:02 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/13 10:01:48 low      vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is down 2014/08/13 10:00:54 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/13 09:58:40 low      vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is down 2014/08/11 15:41:09 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/07 17:16:13 low      vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is down 2014/08/07 17:16:13 low      vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is down 2014/04/03 23:30:33 low      vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is down 2014/04/03 23:30:33 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/04/03 17:36:17 low      vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is down 2014/02/17 10:09:24 low      vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is down 2014/02/17 10:09:24 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/02/17 10:01:10 low      vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is down 2014/02/17 10:01:10 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/01/29 17:49:04 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/01/28 13:38:54 low      vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is down 2014/01/27 13:56:41 low      vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is down 2014/01/27 13:56:41 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/01/27 13:51:48 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/01/20 15:13:13 low      vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is down 2014/01/20 15:13:13 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/01/17 15:19:52 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/01/17 15:12:28 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/01/17 15:09:36 low      vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down When a monitored IP comes back up in the system log, "tunnel-status-up" is created. The message below is from a VPN and contains the name of the tunnel that came up. The message also has an info level of severity so if there is a need for a notification to be created through email or an external syslog server, forward the informational level of messages. From the CLI command below, see the following output: admin@PA-200(active)> show log system direction equal backward subtype equal vpn eventid equal "tunnel-status-up" Time                Severity Subtype Object EventID ID Description =============================================================================== 2014/08/13 15:31:31 info    vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is up 2014/08/13 10:08:56 info    vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is up 2014/08/13 10:08:45 info    vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is up 2014/08/13 10:08:38 info    vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is up 2014/08/13 10:07:11 info    vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is up 2014/08/13 10:06:37 info    vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is up 2014/08/13 10:02:10 info    vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is up 2014/08/13 10:01:52 info    vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is up 2014/08/13 10:01:07 info    vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is up 2014/08/13 09:58:44 info    vpn    HQ_tun tunnel- 0  Tunnel HQ_tunnel is up 2014/08/11 15:42:07 info    vpn    DR_tun tunnel- 0  Tunnel DR_tunnel is up 2014/04/03 23:30:21 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/04/03 23:30:21 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/04/03 17:36:13 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/02/17 10:09:12 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/02/17 10:09:12 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/02/17 10:01:02 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/02/17 10:01:02 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/29 17:49:43 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/29 17:49:00 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/29 17:49:00 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/28 13:43:03 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/27 13:56:48 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/27 13:56:44 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/27 13:51:53 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/27 13:51:44 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/27 13:51:44 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/23 11:17:18 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/23 11:17:14 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/20 15:19:17 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/20 15:18:57 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/17 15:55:36 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/17 15:18:01 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/17 15:17:57 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/17 15:16:20 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/17 15:11:03 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/01/17 15:09:32 info    vpn    Sec-IS tunnel- 0  Tunnel Sec-ISP2 is up 2014/01/17 15:09:32 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up Finding site-to-site IPSec tunnel uptime or downtime The output of the logs generated by the Tunnel Monitoring feature can be leveraged using a variation of the show log system command to combine the output: > show log system subtype equal vpn | match " Tunnel <Tunnel_Name> is" This allows for easy visualization of the IPSec tunnel's uptime or downtime. For example: > show log system subtype equal vpn | match " Tunnel Pri-ISP1 is" 2014/12/09 08:03:30 low     vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/12/09 08:03:38 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/12/10 04:49:08 low     vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/12/10 04:49:24 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up 2014/12/10 19:29:50 low     vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is down 2014/12/10 19:30:26 info    vpn    Pri-IS tunnel- 0  Tunnel Pri-ISP1 is up owner: ialeksov
View full article
ialeksov ‎08-13-2014 07:15 AM
45,956 Views
0 Replies
1 Like
IKEv2 support is included with PAN-OS 7.0. Before PAN-OS 7.0 Palo Alto Networks firewall running PAN-OS 6.1 or lower, only supported IKEv1. The following errors would be seen if IKEv2 was configured. info     vpn     ike_se ike-neg 0  IKE phase-1 SA is deleted SA: x.x.x.x[500]-y.y.y.y[500] cookie:8673a55186fc8c10:0000000000000000. info     vpn     ike_se ike-neg 0  IKE phase-1 negotiation is failed as initiator, main mode. Failed SA: x.x.x.x[500]-y.y.y.y[500] cookie:8673a55186fc8c10:0000000000000000. Due to timeout. info     vpn            ike-gen 0  0:x.x.x.x[500] - y.y.y.y[500]:0x30f02178:unknown ikev2 peer info     vpn            ike-gen 0  received unencrypted Notify payload (NO-PROPOSAL-CHOSEN) from IP y.y.y.y[500] to x.x.x.x[500], ignored. info     vpn            ike-gen 0  0:x.x.x.x[500] - y.y.y.y[500]:0x30f03638:unknown ikev2 peer info     vpn     ike_se ike-neg 0  IKE phase-1 negotiation is started as initiator, main mode. Initiated SA: x.x.x.x[500]-y.y.y.y[500] cookie:8673a55186fc8c10:0000000000000000. owner: ashaikh
View full article
ashaikh ‎07-18-2014 05:17 PM
16,298 Views
3 Replies
PAN-OS 6.0 Overview The following document contains information about the maximum number of VPN tunnels for different hardware running PAN-OS 6.0. Note: Each proxy ID is counted as a separate VPN tunnel. Model Maximum Number of VPN tunnels PA-200 25 PA-500 250 PA-2020 1,000 PA-2050 2,000 PA-3020 1,000 PA-3050 2,000 PA-4020 2,000 PA-4050 4,000 PA- 4060 4 ,000 PA-5020 2,000 PA-5050 4,000 PA-5060 8,000 PA-7050 8,000 VM-100 25 VM-200 500 VM-300 2000 owner: mdjeric
View full article
mdjeric ‎07-07-2014 07:02 AM
6,744 Views
1 Reply
Overview The LSVPN implementation allows administrators to quickly connect VPN sites to the main site. The implementation relies on the usage of certificates to authenticate the satellites to the portal, which allows the administrators control who will be allowed access to the VPN network, and who can be denied if emergency action is needed. Details To accomplish full control, there needs to be a Certificate Authority(CA) on the Palo Alto Networks firewall, and OCSP responder for the certificates that we will generate with that CA. The process is very similar to controlling GlobalProtect Remote access VPN connections and similar principles are valid and similar steps should be followed. Note: For more information reference the following link: Controlling GlobalProtect VPN Access with OCSP Create a CA at the firewall Create a local OCSP responder Create a Certificate Profile that will be used to check the status of the certifications with the given OCSP Create a certificate signed by the CA and include the OCSP responder to be checked for the revocation status of these certificates Verify if the certificates are generated with the correct information when a satellite connects to GlobalProtect (this should include the correct Issuer) Verify that the satellites can connect to the VPN network If needed, revoke the satellite certificate to immediately remove the satellite from the devices that can connect to the VPN network Steps After the CA and the OSCP responder are in place on the firewall, create a Certificate Profile. Note: Reference the following link for more information on: How to Configure an OCSP Responder To create a Certificate Profile for the LSVPN satellites, which will be verifying the revocation status with the created OCSP, go to Device > Certificate Management > Certificate Profile. Go to Device > Certificate Management > Certificates and click Generate to create the certificate that will be used to sign the satellite certificates. While creating the certificate, be sure to use the OCSP responder previously created. If this is an intermediated certificate, make sure to select the root CA that is trusted on the satellite. If the root is not trusted on the satellite, or this is a root certificate that is being creating now, be sure to export the certificate from this firewall and import it on the satellite firewall. At this time, the configuration of the LSVPN needs to be completed. Please reference the Large Scale VPN (LSPV) Deployment Guide to complete the configuration. While configuring the setup, make sure to use the appropriate certificates and certificate profiles previously created. Include the trusted root CA and the OCSP responder in the Satellite Configuration under the GlobalProtect Portal, so the certificates are checked for the revocation status. Use the Server Certificate and the Certificate Profile for the GlobalProtect Gateway, as shown below: After the full LSVPN configuration is complete, verify if connections are establishing from the satellites to GlobalProtect. Check the connection under the Network tab > GlobalProtect > Portals > Under Info > click on Satellite Information: Go to Network > GlobalProtect > Gateways > Under Info > click on Satellite Information to access details about the connection to the needed gateway: The certificate that is used for this process is actually created for the satellite, from the CA that has been specified in the previous steps. By default, the validity of these certificates is 7 days. As shown below, see the issued certificate under Device > Certificate Management > Certificates: When opening the certificate, there is an option to revoke the certificate. Once the Revoke button is clicked, the certificate is no longer valid and should not be accepted by the portal to establish connections to the VPN network: The status immediately changes to revoked: From this point on, the connections from that satellite will be dropped, because of authentication with an invalid certificate. This can bee viewed in the system logs, as shown below: In the sslmgr.log of the portal, see that a certificate check is performed and the used certificate is revoked. Run the following operational command to achieve this: > less mp-log sslmgr.log Jun 16 00:51:58 pan_store_portal_cfg_assigned(pan_store_satellite_info.c:1854): find assigned serialno 0006C107270 Jun 16 00:51:58 pan_store_satellite_info_response_print(pan_store_satellite_info.c:106): {satellite info success; vsys id(1); vsys name(vsys1); portal name(GP-Portal); serialno(0006C107270); hostname(IDEA-PA-01); config(LSVPN_Satelites); pin(static); derived from(); last seen ip(10.193.16.27); } Jun 16 00:51:58 pan_store_certificate_info_find_expired_cert(pan_store_certificate_info.c:964): certificate(539DAE57002715) is revoked, don't cleanup Jun 16 00:51:58 pan_store_certificate_info_find_expired_cert(pan_store_certificate_info.c:973): certificate expiration date(Jun 22 22:51:01 2014 GMT) Jun 16 00:51:58 pan_store_certificate_info_find_expired_cert(pan_store_certificate_info.c:979): current date (Jun 15 22:51:58 2014 GMT) Jun 16 00:51:58 pan_store_certificate_info_find_expired_cert(pan_store_certificate_info.c:981): expdate(140622225101Z) curdate(140615225158Z) Jun 16 00:51:58 pan_store_certificate_info_find_expired_cert(pan_store_certificate_info.c:984): exp date(3183271629) curwarmingdate(3176271686) Jun 16 00:51:58 pan_store_is_cert_expired(pan_store_certificate_info.c:70): certificate expiration date(Jun 22 22:51:01 2014 GMT)(140622225101Z) Jun 16 00:51:58 pan_store_is_cert_expired(pan_store_certificate_info.c:77): current date plus warming days (Jun 18 22:51:58 2014 GMT)(140618225158Z) Jun 16 00:51:58 sslmgr_sysd_store_cert_gen(sslmgr_sysd.c:469): certificate is still valid Jun 16 00:51:58 pan_store_satellite_info_request_print(pan_store_satellite_info.c:75): {satellite info find; vsys id(1); vsys name(vsys1); portal name(GP-Portal); seria lno(0006C107270); hostname(); config(); pin(); derived from(); last seen ip(); } Jun 16 00:51:58 pan_store_portal_cfg_assigned(pan_store_satellite_info.c:1854): find assigned serialno 0006C107270 Jun 16 00:51:58 pan_store_satellite_info_response_print(pan_store_satellite_info.c:106): {satellite info success; vsys id(1); vsys name(vsys1); portal name(GP-Portal); serialno(0006C107270); hostname(IDEA-PA-01); config(LSVPN_Satelites); pin(static); derived from(); last seen ip(10.193.16.27); } Jun 16 00:52:14 [OCSP] URL (null)       serialno: 539E235500032C Jun 16 00:52:14 Send cookie:4 session:0 status:2 to DP After revocation, a connection can not be established any more: > show global-protect-gateway current-satellite GlobalProtect Gateway: GP-GW-1 (0 satellites) Tunnel Name          : GP-GW-1-S GlobalProtect Gateway: GP-GW-1-Backup (0 satellites) Tunnel Name          : GP-GW-1-Backup-S > show global-protect-gateway previous-satellite GlobalProtect Gateway: GP-GW-1 (0 satellites) Tunnel Name          : GP-GW-1-S GlobalProtect Gateway: GP-GW-1-Backup (0 satellites) Tunnel Name          : GP-GW-1-Backup-S         Satellite                 : 0006C107270         Satellite Hostname        : IDEA-PA-01         Private IP                : 10.200.2.1         Public IP                 : 10.193.16.27         Satellite Tunnel IPs      :         Login Time                : Jun.15 23:51:33         Logout Time               : Jun.16 00:51:34         Reason                    : Tunnel Lifetime expired         Satellite Published Routes: 172.18.1.0/24         Satellite Denied Routes   :         Satellite Duplicate Routes:         Tunnel Monitor Enabled    : Yes         Tunnel Monitor Interval   : 3 seconds         Tunnel Monitor Action     : fail-over         Tunnel Monitor Threshold  : 5 attempts         Tunnel Monitor Source     : 10.193.21.98         Tunnel Monitor Destination: 10.200.2.1         Tunnel Monitor Status     : No data available The satellite can be permanently removed from the GlobalProtect Portal Satellite configuration. This means the portal does not have to try to validate the certificate. To configure, go to Network > GlobalProtect > Portals > Satellite Configuration, select the satellite, and delete it from the list: owner: ialeksov
View full article
ialeksov ‎06-28-2014 05:51 AM
25,364 Views
0 Replies
Issue Occasionally, on a site-to-site IPSec VPN between a Palo Alto Networks device and another device, Phase 1 and Phase 2 will be up. However, the hosts behind the peer are not reachable. Details Determine what zone the tunnel interface is located. If the tunnel interface is in the untrust zone, the traffic will be NATed to the public IP, while leaving the tunnel, by the default NAT rule on the Palo Alto Networks device. Resolution There are two options to resolve this issue: Move the tunnel interface to one of the inside zones, so that the traffic will not get NATed while leaving the tunnel. Create a No-NAT rule for traffic from the inside zones to those destination addresses behind the peer. owner: achalla
View full article
achalla ‎04-09-2014 03:39 AM
10,818 Views
2 Replies
1 Like
Overview IPSec Tunnel Monitoring is a mechanism that sends constant pings to the monitored IP address sourced from the IP of the tunnel interface. The interval for the pings is specified in its Monitor Profile (Network > Network Profiles > Monitor > Interval). Note: The monitored IP address is configured at: Network > IPSec Tunnels > General Tab > Destination IP. Details To check if the tunnel monitoring is up or down, use the following command: > show vpn flow id  name               state     monitor  local-ip        peer-ip      tunnel-i/f ------------------------------------------------------------------------------------ 1  tunnel-to-remote    active    up       10.66.24.94     10.66.24.95  tunnel.2 The above output shows that the monitor status is "up". To verify the count of these pings use the show vpn flow tunnel-id <id> command. For example: > show vpn flow tunnel-id 1 tunnel  tunnel-to-remote         id:                    1         type:                  IPSec         gateway id:            1         local ip:              10.66.24.94         peer ip:                10.66.24.95         inner interface:        tunnel.2         outer interface:        ethernet1/3         state:                  active         session:                6443         tunnel mtu:            1436         lifetime remain:        2663 sec         latest rekey:          937 seconds ago         monitor:                on         monitor status:        up         monitor interval:      3 seconds         monitor threshold:      5 probe losses         monitor packets sent:  739180         monitor packets recv:  732283         monitor packets seen:  584         monitor packets reply:  584         en/decap context:      76         local spi:              F18E58FF         remote spi:            B90FCFB2 In the above output: monitor packets sent - Number of pings sent monitor packets recv - Number of replies received to the pings sent. monitor packets seen - Number of monitor packets received from remote side querying for us. monitor packets reply - Number of replies sent in response to "monitor packets seen". This will increment only if the requests were made to tunnel interface IP. In order to see real-time run-time states for a particular tunnel, run the following command: > show running tunnel flow tunnel-id 1 | match monitor         monitor:                on         monitor status:        up         monitor interval:      3 seconds         monitor threshold:      5 probe losses         monitor packets sent:  739180         monitor packets recv:  732283         monitor packets seen:  584         monitor packets reply:  584 If the monitor is "on" and monitor status is "down" for any reason, you can still view that "monitor packets sent" keeps incrementing but "monitor packets recv" is constant. Even if the tunnel is down and the monitor status is down, the "monitor packets sent" still sends pings at regular intervals. Note: Whenever the tunnel goes down, the Palo Alto Networks firewall generates an event under system logs ( s everity is set to critical). Notifications are generated if an email alert profile is configured for critical logs. Please review the following document for more information: How to Configure Email Alerts for System Logs? See Also Dead Peer Detection and Tunnel Monitoring CLI Commands to Status, Clear, Restore, and Monitor an IPSEC VPN Tunnel owner: dreputi
View full article
dreputi ‎10-17-2013 02:03 AM
40,792 Views
3 Replies
5 Likes
Issue Phase 1 Tunnel is not coming up. The following error appears in the ikemgr.log: [PROTO_ERR]: 0:? - 10.10.78.254[500]:(nil):ignore the packet, expecting the packet encrypted. Resolution The error indicates that the pre-shared keys on both ends did not match. This may be due to incorrectly inputting the keys or the key value not being applied in the IKE profile. Re-enter the pre-shared key on the IKE Gateway configuration under Network > Network Profiles > IKE Gateway and commit. owner: pvemuri
View full article
pvemuri ‎08-19-2013 03:42 PM
4,861 Views
1 Reply
1 Like
Issue When GlobalProtect is configured to send HIP report to the GlobalProtect Gateway and the polices are defined based on these reports, the users hit a deny policy even though the connection is successful. Prerequisites Valid GlobalProtect Portal & Gateway license GlobalProtect data file is installed Symptoms No HIP logs in Monitor tab HIP profiles do not show up in the ip-user mapping No output is returned for the following commands:      > debug user-id dump hip-profile-database      > debug user-id dump hip-report computer <comp_name> ip <assigned_by_GP> user <username> Resolution If not using a self-signed certificate, make sure to include the entire certificate chain under Trusted Root CA section of portal config. Note: There will be no certificate-related warning or error messages in the GlobalProtect Agent logs or the firewall. See Also How to Install a Chained Certificate Signed by a Public CA owner: sdarapuneni
View full article
zarina ‎07-25-2013 12:36 PM
3,262 Views
0 Replies
Ask Questions Get Answers Join the Live Community