Management Articles

Featured Article
Issue A vpn tunnel goes down and comes back up. A look at the global counters shows that the flow_fwd_zonechange counter is incrementing.   > show counter global   Cause The flow_fwd_zonechange counter indicates that the egress zone of a packet does not match the egress zone of the matching session. For this reason, the packet is dropped and the flow_fwd_zonechange counter is incremented.   Scenario 1 Packets are dropped due to a route change. The flow_fwd_zonechange counter increments when a packet is to be forwarded, but the zone of egress interface does not match the egress zone in the session due to a route change because the tunnel is not up. To verify global counter increments please refer to the following knowledge base How to Check Global Counters for Specific Source and Destination IP Address   In this scenario, the initial routing table is as follows: 0.0.0.0/0 metric 10 untrust zone. A tunnel route to 10.10.10.10/24 through 1.1.1.1 metric 5 tunnel-zone. When the tunnel goes down, the tunnel route is removed from the table and the default route is used for the 10.10.10.10 network in the untrust zone. When the tunnel comes back up, it considers this a zone change and drops the packets incrementing the flow_fwd_zonechange counter.   Resolution 1 All sessions destined to the untrust zone when going to 10.10.10.10/24 need to be cleared and re-initiated. To avoid this zone change, create a dummy IP address (ex: loopback interface IP address 5.5.5.5) in the tunnel zone to make the routing table look like this: 0.0.0.0/0 metric 10 untrust zone. A tunnel route to 10.10.10.10/24 through 1.1.1.1 metric 5 tunnel-zone. Another tunnel route to 10.10.10.10/24 through 5.5.5.5 metric 10 tunnel-zone. This forces the traffic to use the route with metric 10 in the same tunnel zone when the primary tunnel route fails, and there is no zone change that occurs when the tunnel comes back up. Scenario 2 Packets designated to exit out an ingress interface is dropped by the Firewall with "flow_fwd_zonechange".     Resolution 2   In this case, the interface had a /32 (host) instead of /24 (network). Make sure that the interface is showing as a /24. For example 10.10.10.1/24.   owner: pvemuri
View full article
pvemuri ‎10-23-2018 12:33 PM
3,929 Views
0 Replies
Issue When running “show routing route” command routing table of Palo Alto firewall displays multiple entries for the same route (prefix and mask).   Details This is expected behavior because Palo Alto Networks firewall routing scheme is designed to take the best route from each protocol and put them all into the routing table. The best route is then selected among them based on Administrative Distance (AD) value of routing protocols which routes came from and that route is marked with flag A, stating that it is the Active route.   For example:   > show routing route flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp, Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2 VIRTUAL ROUTER: default (id 1) ========== destination nexthop metric flags age interface next-AS ... 10.175.0.0/16 10.175.59.1 10 A S ethernet1/2 10.175.0.0/16 192.168.200.99 ?B 92699 0   The route marked with the A flag is further installed into the RIB and FIB table and used for traffic forwarding.   See Also Understanding Route Redistribution and Filtering
View full article
djoksimovic ‎08-28-2018 10:38 AM
8,120 Views
0 Replies
Issue The Palo Alto Networks firewall currently doesn't have SNMP OIDs to monitor IPSec tunnel status, so network management systems cannot rely on SNMP protocol to receive notifications when the IPSec tunnel on the Palo Alto Networks firewall changes it's status.       Workaround Perform the following workaround on the Palo Alto Networks firewall: Configure and enable IPSec Tunnel Monitor feature for the desired IPSec tunnel.(https://live.paloaltonetworks.com/docs/DOC-1323) Configure the Syslog server profile to send syslog messages to the desired Syslog server.(https://live.paloaltonetworks.com/docs/DOC-3837) Go to Device > Log Setting > System to send logs to previously created Syslog server.   When the tunnel monitor fails the firewall generates the following message in the system log:   Time Severity Subtype Object EventID ID Description =============================================================================== 2015/03/15 13:24:34 low vpn <object name> tunnel- 0 Tunnel <tunnel name> is down   The Syslog server receives a "tunnel down" message. After the IPSec tunnel is brought up, the tunnel interface also goes up and a new message "tunnel is UP" is generated in the system logs. Then, a newly generated log is sent to the Syslog server.
View full article
djoksimovic ‎08-28-2018 10:35 AM
9,013 Views
1 Reply
1 Like
Details A question mark next to the route in the routing table symbolizes a  “loose” flag.   This flag is often used for routes coming from BGP protocol because the next-hop attribute is not being changed among iBGP neighbors, so routed process should do reverse routing lookup to determine the real next-hop IP of given route.   See this example:   > show routing route flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp, Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2 VIRTUAL ROUTER: default (id 1) ========== destination nexthop metric flags age interface next-AS ... 10.10.0.0/16 192.168.200.99 ?B 92699 0 10.150.0.0/17 10.150.59.1 10 A S ethernet1/2   owner: djoksimovic
View full article
djoksimovic ‎08-28-2018 10:35 AM
4,280 Views
3 Replies
PAN-OS 6.1+   Issue The system log on the Palo Alto Networks firewall generated a message that says one of the physical ports assigned to a given Aggregate Ethernet (AE) interface was taken out of the AE group and then brought back after a minute.   2015/03/08 19:55:44 critical lacp    ethern nego-fa 0  LACP interface ethernet1/2 moved out of AE-group ae1. Selection state Selected 2015/03/08 19:55:45 critical lacp    ethern lacp-up 0  LACP interface ethernet1/2 moved into AE-group ae1.   Cause The aggregate interface has auto LACP enabled, which means that LACPDU messages are exchanged with a peer to dynamically negotiate LACP parameters and establish and maintain the AE interface status. LACPDU messages are sent out of every physical interface member of any given AE group.   LACP feature has 3 main state machines: Selection, MUX, and RX machine.   The RX machine examines data in the received LACPDUs and updates the peer’s state. If no LACPDU messages have been received by the peer device during the past 3 intervals the RX state machine for the given interface goes from CURRENT (operational) to EXPIRED (non-operational) status. This activity appears in the System log as an interface taken out of the AE group.   The firewall has a dedicated daemon on MP plane for LACP protocol called “l2ctrld.” Logs generated are stored in l2ctrld.log file in the var/log/pan folder. In the var/log/pan/ l2ctrld.log file you can see the following entries:   2015-03-08 19:55:44.766 -0400 ethernet1/2 idx 17, current_while expired. 2015-03-08 19:55:44.766 -0400 ethernet1/2 idx 17, rx state change CURRENT=>EXPIRED 2015-03-08 19:55:44.767 -0400 ethernet1/2 idx 17, mux state change RX_TX=>ATTACHED 2015-03-08 19:55:44.767 -0400 post LACP event to DP: if_idx 17, up 0 2015-03-08 19:55:44.767 -0400 log ethernet1/2 idx 17 leaves lag. sel state Selected 2015-03-08 19:55:45.017 -0400 ethernet1/2 idx 17, mux state change ATTACHED=>RX_TX 2015-03-08 19:55:45.017 -0400 ethernet1/2 idx 17, mux state in RX_TX 2015-03-08 19:55:45.017 -0400 post LACP event to DP: if_idx 17, up 1 2015-03-08 19:55:45.017 -0400 log ethernet1/2 idx 17 join lag
View full article
djoksimovic ‎08-28-2018 08:38 AM
25,885 Views
19 Replies
2 Likes
Symptoms When configuring an IPsec VPN between an AWS Virtual Private Gateway and a Palo Alto Networks device, you might get an error. If you are using the  longer format resource IDs  generated by AWS for Palo Alto Networks as the vendor, you might run into errors while editing the VPN and network settings.   This normally is caused by going into the AWS portal, and then going to "VPC > VPN Connections" and then select "Download Configuration". If the VPN gateway is using the longer format resource IDs, then PAN-OS will not accept some of the generated configuration lines. An error similar to the following will be reported. admin@PA-VM# edit network ike crypto-profiles ike-crypto-profiles ike-crypto-vpn-0901877fe35f95b23-0 ike-crypto-vpn-0901877fe35f95b23-0 should be less than or equal to 31 characters   Invalid syntax. Diagnosis The reason of the invalid syntax is because currently in PAN-OS the network profiles name field accept a max of 31 characters. and the IKE crypto profile name field in the generated configuration contains 34 characters after using the longer instance IDs. (for example ike-crypto-vpn-0901877fe35f95b23-0).   Starting June 2018, AWS will switch to use Longer Format Resource IDs for all AWS resources like VPC IDs. Solution To resolve this you need to manually modify the configuration file generated before copy/paste the configuration into a PAN-OS firewall. You should replace all the instance of the ike crypto profile name as the following example: current value: ike-crypto-vpn-0901877fe35f95b23-0 new value: vpn-0901877fe35f95b23-0 Removing the (ike-crypto-) from the name will make the total number of characters equal to 23. And it will be accepted by PAN-OS.   As of 15-Jun-2018, AWS has updated the VPN configuration generator for PAN-OS to shorten the value for ike-crypto-profiles to automatically create a shorter unique name of the format: vpn-0901877fe35f95b23-0  
View full article
melamin ‎07-03-2018 05:54 PM
2,229 Views
0 Replies
As shown in the following screenshot, the ethernet protocol type is:0x7261        owner: rvanderveken
View full article
rvanderveken ‎05-28-2018 04:35 AM
5,766 Views
0 Replies
How to configure PAN to advertise static/connected routes to its BGP peers except for one of them. This holds good for  connected/OSPF/RIP routes.   Steps  1. Example showing 2 BGP peers.     2. The following static routes are configured on the box If only 100.1.1.0/24 and 50.0.0.0/24 static routes has to redistributed to Peer3 and all static routes to Peer2 then.   4.  Create a redistribution profile to allow all static routes.   5. Use the same redistribution profile in the redist profile of the BGP.   6.  Now this will redistribute all the static routes to peers Peer2 and Peer3. In order to restrict the redistribution , we need to use the export policy and allow the 2 routes.   7. If you check the neighbor/Local-rib/Rib-out , you can see the desired result.   Via the CLI Use the following command to show the bgp loc-rib info: admin@Lab> show routing protocol bgp loc-rib   VIRTUAL ROUTER: default (id 1) ========== Prefix             Nexthop           Peer       Weight   LocPrf Org       MED flap AS-Path *50.0.0.0/24                         Local           0       100 i/c         0     0 *100.1.1.0/24                         Local           0       100 i/c         0     0 *172.17.0.0/16       172.17.0.0       Local           0       100 i/c         0     0 *192.168.254.0/24                     Local           0       100 i/c         0     0   total routes shown: 4     8. Now check the rib-out , only routes 100.1.1.0/24 and 50.0.0.0/24 are redistributed to Peer3 and all routes to Peer2.   Via the CLI Use the following command to show the bgp rib-out info: admin@Lab> show routing protocol bgp rib-out   VIRTUAL ROUTER: default (id 1)   ==========   Prefix             Nexthop           Peer       Originator       Adv Status   Aggr     Status     AS-Path 50.0.0.0/24         172.19.1.1       peer1.1     0.0.0.0           advertised   no aggregation   64713 100.1.1.0/24         172.19.1.1       peer1.1     0.0.0.0           advertised   no aggregation   64713 172.17.0.0/16       172.19.1.1       peer1.1     0.0.0.0           advertised   no aggregation   64713 192.168.254.0/24     172.19.1.1       peer1.1     0.0.0.0           advertised   no aggregation   64713 50.0.0.0/24         172.19.1.1       Peer1.3     0.0.0.0           advertised   no aggregation   64713===>Peer3 100.1.1.0/24         172.19.1.1       Peer1.3     0.0.0.0           advertised   no aggregation   64713===>Peer3   total routes shown: 6   Important Note ------------------- If you have redistribute OSPF,Connected,static route in BGP use the redistribution profile and redist tab on the BGP for the same and use the export rule only when you have to restrict the redistribution to peers as shown in the above example.   If you want to restrict the BGP routes sent out from the box , Use only the export tab and restrict it.  Do not use export and redist tab for exporting BGP routes in BGP.
View full article
panagent ‎05-14-2018 05:27 PM
10,814 Views
1 Reply
Overview The small form-factor pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunication and data communications applications. The PA-2000 Series, PA-3000 Series, PA-4000 Series, PA-5000 Series, and PA-7000 Series firewalls accept SFP module(s). This document describes how to view the currently installed SFP modules.   Details From the CLI, run the following command: > show system state filter sys.sX.pY.phy where X=slot=1 and Y=port=21 for interface 1/21 Typical SFP module output > show system state filter sys.s1.p19.phy sys.s1.p19.phy: { 'link-partner': { }, 'media': SFP-Plus-Fiber, 'sfp': { 'connector': LC, 'encoding': Reserved, 'identifier': SFP, 'transceiver': 10000B-SR, 'vendor-name': OEM , 'vendor-part-number': PAN-SFP-PLUS-SR , 'vendor-part-rev': B4 , }, 'type': Ethernet, } > show system state filter sys.s1.p21.phy sys.s1.p21.phy: { 'link-partner': { }, 'media': SFP-Plus-Fiber, 'sfp': { 'connec tor': LC, 'encoding': Reserved, 'identifier': SFP, 'transceiver': , 'vendor-name ': FINISAR CORP.   , 'vendor-part-number': FTLX8574D3BCL   , 'vendor-part-rev': A   , }, 'type': Ethernet, }   Defective SFP module output If the output appears similar to the sample below, then the SFP module may be defective: sys.s1.p21.phy: { 'link-partner': { }, 'media': SFP-Fiber, 'sfp': { 'connec tor': vendor specific, 'encoding': Reserved, 'identifier': SFP, 'transceiver': , 'vendor- name ': yyyyyyyyyyyyyyyy, 'vendor-part-number': yyyyyyyyyyyyyyyy , 'vendor-part-rev': yyyy, }, 'type': Ethernet, }   Note: To verify the above output, unplug the SFP module from the initial SFP port and plug it into another SFP port. Run the same " show system state filter " command as above. If the output is the same, then the module is defective.   owner: gcapuno
View full article
gcapuno ‎03-02-2018 03:11 AM
56,694 Views
10 Replies
4 Likes
Overview There are circumstances where routers need to advertise default routes to its peers . This document illustrates how we redistribute default routes to peer with/without having the default route in the routing table of the box.   Details Enabling the "Allow Redistribute Default Route" with the redistribution profile having the default route is mandatory to have the default route advertised to its peers. The procedure is same for OSPF and BGP.   If the default route is not available on the routing table , you can directly add the default route(0.0.0.0/0) in the redistribution profile of the protocols in the BGP-Network--BGP---Redistribution profile, Network--OSPF--Exportrule and enable the Allow redistribute default route tab and distribute the route.   The significance of having the Allow Redistribute default route tab  is to validate whether the default route needs to be propogated even if it is part of the redistribution profile, which has all the routes including default.         Troubleshooting - CLI To check if the default route is propogated , check the following CLI commands   OSPF > show routing protocol ospf dump lsbd 1                 1.1.1.1         0.0.0.0 /0          type-5 (External)    0x80000001 0x0000CEFE    29                    Options: [External]             Mask 0.0.0.0 , type 2, tos 0 metric: 1, forward 0.0.0.0 , tag 0.0.0.0   BGP > show routing protocol bgp rib-out | match 0.0.0.0/0  0.0.0.0/0           10.46.40.1       peer-110   0.0.0.0          advertised  no aggregation  65001  0.0.0.0/0           10.46.40.1       subint-2   0.0.0.0          advertised  no aggregation  65001  0.0.0.0/0           10.46.40.1       tunnelpeer 0.0.0.0          advertised  no aggregation  65001   Troubleshooting - WebGUI For BGP,  the same information can be checked on the WebGUI as well, but not for OSPF. This is found in the Virtual Router > BGP > RIB Out screen.   owner: mchandrase
View full article
kprakash ‎02-22-2018 03:17 AM
18,619 Views
5 Replies
Symptoms When Policy Based Forwarding (PBF) is configured with the  "Enforce Symmetric Return" option enabled, but without a Next Hop Address, forwarding may fail occasionally.   See also: How to Configure Symmetric Return Diagnosis When the issue occurs, you can see the return mac entries have reached their maximum level when you run the show pbf return-mac all command. user@firewall> show pbf return-mac all current pbf configuation version:   1 total return nexthop addresses :    0 index   pbf id  ver  hw address          ip address                      return mac          egress port -------------------------------------------------------------------------------- maximum of ipv4 return mac entries supported :     1000 total ipv4 return mac entries in table :           1000 total ipv4 return mac entries shown :              1000 status: s - static, c - complete, e - expiring, i - incomplete pbf rule        id   ip address      hw address        port         status   ttl --------------------------------------------------------------------------------   Note: The maximum number of entries that this ARP table supports is limited by the firewall model and the value is not user configurable. To determine the limit for your model, use the CLI command: show pbf return-mac all . Solution This issue will only occur if the 'Next Hop Address' is not set in a PBF rule that does have symmetric return enabled.  Therfore, please configure a valid peer IP address in the Next Hop Address list to avoid running into the issue. Add a Next Hop Address Setting the Next Hop Address ensures only the appropriate return mac addresses are learned for Symmetric Return     >show pbf return-mac all maximum of ipv4 return mac entries supported : 16000 total ipv4 return mac entries in table : 12800 total ipv4 return mac entries shown : 12800 status: s - static, c - complete, e - expiring, i - incomplete pbf rule id ip address hw address port status ttl -------------------------------------------------------------------------------- symmectric 1 8.0.0.2 00:1b:17:05:f1:17 ethernet1/1 c 737 symmectric 1 8.0.0.3 00:1b:17:05:f1:17 ethernet1/1 c 742 symmectric 1 8.0.0.4 00:1b:17:05:f1:17 ethernet1/1 c 741 symmectric 1 8.0.0.5 00:1b:17:05:f1:17 ethernet1/1 c 743 symmectric 1 8.0.0.6 00:1b:17:05:f1:17 ethernet1/1 c 746 symmectric 1 8.0.0.7 00:1b:17:05:f1:17 ethernet1/1 c 743 symmectric 1 8.0.0.8 00:1b:17:05:f1:17 ethernet1/1 c 742 symmectric 1 8.0.0.9 00:1b:17:05:f1:17 ethernet1/1 c 741 symmectric 1 8.0.0.10 00:1b:17:05:f1:17 ethernet1/1 c 745 symmectric 1 8.0.0.11 00:1b:17:05:f1:17 ethernet1/1 c 746    Author: tsakurai
View full article
tsakurai ‎02-02-2018 12:19 AM
2,669 Views
0 Replies
Symptom After changing the SSL decryption certificate on the Palo Alto Networks firewall, SSL Decryption does not work for the Firefox browser. The Firefox browser shows a certificate error, while SSL decryption for other web browsers continue to work.   Cause The Firefox browser saves cookies in its cache.   Resolution Removing the cookies for the particular websites that produce the certificate errors will resolve the issue. On Firefox, cookies can be removed from the Privacy settings. Note: Please refer to the Mozilla Firefox support site  https://support.mozilla.org for more information about the removing cookies. Here is one article from their site that might help: https://support.mozilla.org/en-US/kb/delete-cookies-remove-info-websites-stored     owner: jlunario
View full article
pagmitian ‎01-02-2018 02:05 PM
9,348 Views
1 Reply
Overview In a High Availability configuration the data interfaces of the passive device can be configured to either be down or up. This "Passive Link State" setting can be found under Device > High Availability > Active/Passive Settings: Active/Passive Link State   Shutdown mode In a High Availability configuration the data interfaces of the passive device will be physically down by default. This mode is called shutdown in the Passive Link State field. Here is a sample of interface output.  The right side is the Active device and the left is Passive. Passive device interface state is down. Passive Link State Shutdown   Auto mode This makes the physical interfaces be 'up' on a passive device, but discards any packets which are received. This option allows  faster failovers  on Layer3 interfaces but could have unwanted side effects on Layer2 interfaces, as some switches may try to send packets over the 'up' interfaces. In the below image, the difference of the passive link state which is UP when the option is set as auto as compared to the shutdown as shown above. Passive Link State Auto   Note: The IP and Mac addresses in the first image are highlighted to show that the L3 interfaces will have same virtual mac and ip addresses on both the Active and Passive devices of HA pair.    
View full article
Phoenix ‎11-21-2017 06:32 AM
20,950 Views
6 Replies
2 Likes
Issue When using a group in the "allow list" for the authentication profile that Global Protect uses, the login attempt fails with the following error: "Reason: User is not in allowlist"   However, the login works fine if the allow list is set to "all" in the authentication profile.   Resolution Confirm that the group you are using is in the include list in a Group Mapping configuration under Device > User Identification > Group Mapping Settings: Group Mapping Confirm that the group in question contains the user attempting to login. Run the CLI command: show user group name <value> For example: > show user group name pantac\vpn-user short name:  pantac\vpn-user source type: ldap source:      Pantac2003 [1     ] pantac\user1 [2     ] pantac\admin1 [3     ] pantac\administrator [4     ] pantac\user2 [5     ] pantac\user4 Confirm that the LDAP server profile used for your Group Mapping and your Global Protect authentication profile contain the Netbios domain name (short name) in the domain field. Do not use the DNS name for the domain (domainname.com) In most cases this is the same profile. This can also be left blank in many cases. The LDAP server profile is under Device > Server Profiles > LDAP In PAN-OS 7.0 and later, the domain section was moved to Device > User Identification > Group Mapping Settings :  User Domain   In PAN-OS 8.0 the User Domain can also be controlled in the Authentication Profile User Domain in the Authentication Profile Confirm that the group name in the allow list in the Global Protect authentication profile is listed with the long name of the group. This value can be pasted into this value from the output of the "show user group list" CLI command. Authentication Profile Allow List   owner: jteestel
View full article
jteetsel ‎11-20-2017 05:04 AM
91,331 Views
23 Replies
1 Like
Overview This document describes the steps to add an Exempt IP address for a specific threat.   Steps Navigate to Monitor > Logs > Threat Click on the target threat name. This is the threat for which the exempt IP addresses are to be added. Make sure there is a vulnerability profile associated with a security policy. In this example, the 'test123' vulnerability profile has been applied. At this point, check the box to highlight the profile and add the IP address (as shown in the image below). Click OK. Note: The IP address can be the Victim or Attacker (source address or destination address ) as shown in the following logs. Confirm the updates by going to the vulnerability profile and clicking on the exceptions tab. From there, click on the 'IP Address Exemptions" applet, as shown below, to verify the changes. After you verified changes and confirmed IP addresses of hosts are entered correctly, click OK, OK, and Commit this change to Firewall. From now on, traffic to hosts behind IP address(es) added to the list of Exempt IP addresses will not trigger this vulnerability in this security rule. Traffic to all other IP addresses, or traffic hitting different security rule, will still trigger vulnerability action as defined in that security policy.
View full article
gswcowboy ‎11-15-2017 12:33 PM
32,865 Views
16 Replies
3 Likes
 As explained in the document https://live.paloaltonetworks.com/docs/DOC-5819, port numbers for IPSec session creation are derived from SPI values that remote IPSec peers exchange during IKE phase 2 of tunnel establishment. But this method can be applied only in case one of IPSec peers is the firewall itself, or in other words, only if the IPSec tunnel is terminated on the firewall.   In the case of pass-through IPSec traffic, where the Palo Alto Networks firewall is just an intermediate device between two IPSec peers, it is practically impossible to create a session based on negotiated SPI values, since IKE phase 2 is encrypted and its content is not visible to the firewall.   Since SPI values can’t be seen in advance, for IPSec pass-through traffic, the Palo Alto Networks firewall creates a session by using generic value 20033 for both source and destination port. In the example below, you can see that source and destination ports of both c2s and s2c flows are given the same value, 20033:   admin@vm-300> show session id 791 Session 791 c2s flow: source: 192.168.0.11 [trust] dst: 129.187.7.11 proto: 50 sport: 20033          dport: 20033 state: ACTIVE          type: FLOW src user: unknown dst user: unknown s2c flow: source: 129.187.7.11 [untrust] dst: 192.168.0.11 proto: 50 sport: 20033          dport: 20033 state: ACTIVE          type: FLOW src user: unknown dst user: unknown start time : Thu June 10 11:58:59 2015 timeout : 3600 sec time to live : 3142 sec total byte count(c2s) : 1080 total byte count(s2c) : 1014 layer7 packet count(c2s) : 8 layer7 packet count(s2c) : 5 vsys : vsys1 application : ipsec-esp rule : any-any session to be logged at end : True session in session ager : True session updated by HA peer : False layer7 processing : completed URL filtering enabled : True URL category : any session via syn-cookies : False session terminated on host : False session traverses tunnel : False captive portal session : False ingress interface :    ethernet1/2 egress interface :     ethernet1/1 session QoS rule :     N/A (class 4) tracker stage l7proc : ctd app has no decoder end-reason : unknown   On PA-7000 and PA-5200 series, due to an architectural difference, we use a different technique for session creation of IPSec pass-through traffic. On these platforms session ports are again derived based on SPI values, as described in https://live.paloaltonetworks.com/t5/Learning-Arti cles/What-do-the-Port-Numbers-in-an-IPSEC-ESP-Sess ... , but since SPI values are not known in advance firewall creates session as real ESP traffic arrives on the firewall. Having each flow (client2server, server2client) of a single IPSec tunnel using a unique SPI value implies that firewall creates two independent IPSec session for one IPSec tunnel, one per each direction. This means security policies must be configured to allow pass-through ESP traffic in both directions on PA-7000 and PA-5200 series platforms.
View full article
djoksimovic ‎11-08-2017 12:14 PM
14,840 Views
0 Replies
DNS rewrite (DNS doctoring) is a  capability that some NAT devices offer in order to translate the DNS A-record for a particular DNS query. The Palo Alto Networks firewall as of now does not support the DNS doctoring feature, but there are a few workarounds that can be used.    Some scenarios in which DNS doctoring applies.   Scenario 1:  External DNS Server is returning the public IP of an application server to a client who is also sitting behind the same firewall.        Traffic Flow in this case: In the above case, DNS server 4.2.2.2 replies to the DNS query of the client with the public IP of the Web server, for example 198.51.100.3. The client now accesses the web server on the public IP and forwards that request to the Firewall.  The firewall tries to do route lookup for  198.51.100.3 IP and finds a route via Eth1/1 (Untrust Zone) pointing to the ISP and sends the packet out.   A firewall capable of DNS rewriting will translate the IP address in the DNS response to the private IP address of the server since it has NAT mapping for the same, which enables the client to directly access the Server through LAN to LAN routing/ policies.   Workarounds Configure the client to use the firewall as DNS proxy, and on Firewall configure a static entry for www.example.com as 10.1.1.3. For all other lookups the firewall can use 4.2.2.2 as the DNS server. How to Configure DNS Proxy on a Palo Alto Networks Firewall   OR Use U-Turn NAT, thereby forwarding the traffic from the client to the Server: How to Configure U-Turn NAT   Scenario 2: Internal DNS server is returning private IP address of application server to both Internal and external users.   The external user will not be able to access the server, since it will get the private IP address of the Web Server.    Workaround Add a secondary DNS server (preferably in a DMZ zone) to serve external clients with a public IP address to the server. Change the DNS Server’s A record to use the public IP of the Web Server, and then use the U Turn NAT solution as in Case 1 for the internal Client to be able to access the Web Server. Some DNS servers, like bind9, can serve different records depending on the source IP of the requestor    
View full article
abjain ‎10-30-2017 07:22 AM
8,732 Views
0 Replies
1 Like
For PAN-OS 7.1 and prior   For all platforms the maximum number of Access Routes is limited to 100   For PAN-OS 8.0    The upper limit for number of Access Routes has been increased to 200   For PAN-OS 8.0.2 and later   The upper limit for number of Access Routes has been increased to 800 on Chromebook and 1.000 on all other endpoints (requires GlobalProtect app 4.0.2 or a later release)   owner: ashaikh
View full article
ashaikh ‎09-29-2017 09:46 AM
4,647 Views
1 Reply
The following steps describe how to perform a factory reset on a Palo Alto Networks device. Note: If running PAN-OS 6.0 and above, review the following link to perform SSH into Maintenance Mode: How to SSH into Maintenance Mode   Steps Connect the Console cable, which is provided by Palo Alto Networks, from the "Console" port to a computer, and use a terminal program (9600,8,n,1) to connect to the Palo Alto Networks device. Note: A USB-to-serial port will have to be used if the computer does not have a 9-pin serial port. Power on to reboot the device. During the boot sequence, the screen should look like this: Type maint to enter maintenance mode. PAN-OS 7.1 NOTE: When performing this on PAN-OS 7.1, you will see a "CHOOSE PANOS" screen with the following options: PANOS (maint-other), PANOS (maint) or PANOS (sysroot0). Please choose  PANOS (maint). Press enter to continue. PAN-OS 7.1 GNU GRUB boot menu. Once in maintenance mode, the following is displayed, please press enter to Continue: Arrow down to Factory Reset and press Enter to display the menu: You will see the Image that will be used to perform the factory reset. Select Factory Reset and press Enter again: The unit will reboot when complete. Please be aware that it may take several minutes before the autocommit to complete and allow the admin/admin login to work properly.   See also Admin-Admin not Working After Factory Reset   owner: rvanderveken
View full article
‎09-13-2017 12:32 PM
187,877 Views
12 Replies
4 Likes
Overview The following example explains how the "Host sweep" feature is triggered in Palo Alto Networks Firewalls. Host sweep can be located under the Zone Protection Profile in the Network tab. Go to Network > Zone Protection > Add a profile. For example: Go to abc > under Reconnaissance Protection tab, configure the Host Sweep as 50 seconds Interval + 60 events Threshold. Run a NMAP tool to scan for 50 IP addresses, which will complete in 42 seconds. Threat logs will be generated. Note: Make sure to associate zone-protection with appropriate zone.   Cause Host sweep protection is based on the scanning activity counted per the time interval specified. Palo Alto Networks excludes destination IP addresses as a criteria and tabulates sweep events. A Host Sweep will trigger regardless of the number of IP addresses as long as it crosses the threshold value for a single host.   owner: pchanda
View full article
pchanda ‎07-12-2017 12:56 AM
17,546 Views
5 Replies
1 Like
Overview This document describes how to set up a master key on the Palo Alto Networks firewall.   Details Found under Device > Master Key and Diagnostics, the master key is used to encrypt private keys such as the RSA key that is used to authenticate access to the CLI. The private key is used to authenticate access to the web interface of the firewall, as well as any other keys loaded on the firewall. Because the master key is used to encrypt all other keys, make sure to store the master key in a safe location. Even if a new master key is not specified, private keys are always stored in an encrypted form on the firewall, by default. This master key option offers an added layer of security.     The Palo Alto Networks firewall's master key should be a string of exactly 16 characters. The firewall will accept any combination of upper-case and lower-case alphanumerical and special characters except "$" and "&".   Note:  If the master key is forgotten or lost, the only way to reset this key is to factory reset the Palo Alto Networks firewall. If a factory reset is necessary, refer to the following document: How to do a Factory Reset in PAN-OS 4.1 and 5.0   Note: If the Life Time expires without a new key having been set, the device will reboot into maintenance mode and will need to be factory reset   owner: sgantait
View full article
HULK ‎06-21-2017 02:21 AM
4,971 Views
2 Replies
Question How to identify the Interface MTU via the CLI? Why dont we see it for all interfaces? Answer Interface MTU size via the CLI can be identified via the following command : > show interface <interface-name>   Example : admin@myNGFW> show interface ethernet1/1 -------------------------------------------------------------------------------- Name: ethernet1/1, ID: 16 Link status:   Runtime link speed/duplex/state: 1000/full/up   Configured link speed/duplex/state: auto/auto/auto             MAC address:   Port MAC address 00:1b:17:00:01:10 Operation mode: layer3 Untagged sub-interface support: no -------------------------------------------------------------------------------- Name: ethernet1/1, ID: 16 Operation mode: layer3 Virtual router vr_internet Interface MTU 1500 Interface IP address: 198.51.100.241/24 Interface management profile: all   ping: yes  telnet: yes  ssh: yes  http: yes  https: yes     snmp: yes  response-pages: yes  userid-service: no Service configured: DHCP SSL-VPN Zone: v1-untrust, virtual system: vsys1 Adjust TCP MSS: n     The command 'show interface <interface-name>', will not populate information unless the interface belongs to a Virtual Router. Some caveats exist:   1. Aggregate Ethernet Layer 3 Interfaces will not show this information considering it is not individually added to the VR but rather relies on the Aggregate Group configuration. admin@myNGFW> show interface ethernet1/20 -------------------------------------------------------------------------------- Name: ethernet1/20, ID: 35 Link status:   Runtime link speed/duplex/state: unknown/unknown/down   Configured link speed/duplex/state: auto/auto/auto             MAC address:   Port MAC address 00:1b:17:00:01:23 Aggregate group : ae1 Operation mode: layer3   2. Dedicated-HA interfaces also will not show this information. admin@myNGFW> show interface dedicated-ha1 -------------------------------------------------------------------------------- Name: dedicated-ha1, ID: 5 Link status:   Runtime link speed/duplex/state: unknown/unknown/down   Configured link speed/duplex/state: auto/auto/auto             MAC address:   Port MAC address 00:1b:17:ff:cf:c5 Operation mode: ha Untagged sub-interface support: no -------------------------------------------------------------------------------- Name: dedicated-ha1, ID: 5 Operation mode: ha Interface IP address: 3.3.3.1/30 Interface management profile: N/A Service configured: Zone: N/A, virtual system: N/A Adjust TCP MSS: no   3. The root Aggregate Group interface is typically not added to a virtual router as tagged sub-interfaces are used to configure IP subnets instead: admin@myNGFW> show interface ae1 -------------------------------------------------------------------------------- Name: ae1, ID: 48 Link status:   Runtime link speed/duplex/state: unknown/unknown/down   Configured link speed/duplex/state: auto/auto/auto             MAC address:   Port MAC address 00:1b:17:00:01:30 Aggregate group members: 2   ethernet1/19 ethernet1/20 Operation mode: layer3 Untagged sub-interface support: no -------------------------------------------------------------------------------- Name: ae1, ID: 48 Operation mode: layer3 Interface management profile: N/A Service configured: Zone: N/A, virtual system: vsys2 Adjust TCP MSS: no While the sub-interface will have MTU information as it is added to the VR: admin@myNGFW> show interface ae1.2 -------------------------------------------------------------------------------- Name: ae1.2, ID: 276, 802.1q tag: 2 Operation mode: layer3 Virtual router tst Interface MTU 9192 Interface IP address: 198.51.100.77/24 Interface management profile: N/A Service configured: Zone: ag-trust, virtual system: vsys2 Adjust TCP MSS: no     To be able to identify the interface MTU for all the dataplane interfaces, regardless of their VR membership you can use the following command:   > show system state filter-pretty sw.dev.interface.config admin@myNGFW> show system state filter-pretty sw.dev.interface.config sw.dev.interface.config: {   TCI: {     hwaddr: 00:1b:17:00:01:0c,     mtu: 9192,   },   ae1: { },   ae1.2: { },   ethernet1/1: {     hwaddr: 00:1b:17:00:01:10,     mtu: 9192,   },   ethernet1/1.20: { },   ethernet1/10: {     hwaddr: 00:1b:17:00:01:19,     mtu: 9192,   },   ethernet1/11: {     hwaddr: 00:1b:17:00:01:1a,     mtu: 9192,   },   ethernet1/12: {     hwaddr: 00:1b:17:00:01:1b,     mtu: 9192,   },   ethernet1/13: {     hwaddr: 00:1b:17:00:01:1c,     mtu: 9192,   },   ethernet1/14: {     hwaddr: 00:1b:17:00:01:1d,     mtu: 9192,   },   ethernet1/15: {     hwaddr: 00:1b:17:00:01:1e,     mtu: 9192,   },   ethernet1/16: {     hwaddr: 00:1b:17:00:01:1f,     mtu: 9192,   },   ethernet1/17: {     hwaddr: 00:1b:17:00:01:20,     mtu: 9192,   },   ethernet1/18: {     hwaddr: 00:1b:17:a0:db:21,     mtu: 9192,   },   ethernet1/19: {     hwaddr: 00:1b:17:00:01:22,     mtu: 1500,   },   ethernet1/2: {     hwaddr: 00:1b:17:00:01:11,     mtu: 9192,   },   ethernet1/20: {     hwaddr: 00:1b:17:00:01:23,     mtu: 1500,   },   ethernet1/3: {     hwaddr: 00:1b:17:00:01:12,     mtu: 9192,   },   ethernet1/4: {     hwaddr: 00:1b:17:00:01:13,     mtu: 9192,   },   ethernet1/5: {     hwaddr: 00:1b:17:00:01:14,     mtu: 9192,   },   ethernet1/6: {     hwaddr: 00:1b:17:00:01:15,     mtu: 9192,   },   ethernet1/7: {     hwaddr: 00:1b:17:00:01:16,     mtu: 9192,   },   ethernet1/8: {     hwaddr: 00:1b:17:00:01:17,     mtu: 9192,   },   ethernet1/9: {     hwaddr: 00:1b:17:00:01:18,     mtu: 9192,   },   ha1: { },   ha2: { },   loopback: { },   loopback.20: { },   loopback.5: { },   tunnel: { },   tunnel.1: { },   tunnel.2: { },   tunnel.230: { },   tunnel.5: { },   vlan: { },   vlan.100: { }, }   Note : MTU information for dedicated HA interfaces is obtained through a different command:   HA1 information can be otained through >show system state filter-pretty ha.net.s0.dedicated-ha1.cfg admin@myNGFW> show system state filter-pretty ha.net.s0.dedicated-ha1.cfg ha.net.s0.dedicated-ha1.cfg: {   broadcast: 3.3.3.3,   disable-dhcp: True,   encrypt: {     enable: False,   },   fips-gated: True,   hwaddr: 00:1b:17:ff:cf:c5,   ifindex: 3,   ipaddr: 3.3.3.1,   mtu: 1500,   netmask: 255.255.255.252,   onboot: True,   routes: { },   up: True,   v6routes: { },   vif: False, }   HA2 interfaces operates a little differently and uses MRU instead: > show system state filter-pretty ha.net.s0.dedicated-ha2.hwcfg   admin@myNGFW> show system state filter-pretty ha.net.s0.dedicated-ha2.hwcfg ha.net.s0.dedicated-ha2.hwcfg: {   farloop: False,   link: Down,   mode: Autoneg,   mru: 10048,   nearloop: False,   pause-frames: True,   setting: 1Gb/s-full,   type: HA, }    
View full article
asampath ‎06-08-2017 08:21 AM
5,761 Views
5 Replies
This article explains how to filter specific static routes from being advertised into OSPF while still advertising all other static routes.   The method highlighted in this article is useful when firewall has a large number of static routes configured and only some of the routes needs to be filtered.     Details:   PA-1 (12.12.12.1)  ------  (12.12.12.2) PA-2   1- Static routes configured on PA-1:       2- Redistribution profile configured on PA-1:        3- This redistribution profile causes all static routes configured on PA-1 firewall to be redistributed into OSPF:           4- Now, suppose we want that all static routes should be advertised to PA-2 except the static route 4.4.4.0/24. This could be achieved by using Priority value in Redistribution Profile:       Profile "Redist-Static" has a priority of 5 and action set to "Redist". New profile, "Filter-Static" has a priority of 1 and action set to "No Redist". When both profiles are referred in OSPF Export rules, profiles would be evaluated according to the priority assigned.   Lower value means higher priority. This would cause Filter-Static profile to be evaluated first and preferred over "Redist-Static" profile hence route 4.4.4.0/24 would  not be redistributed while other static routes would still be redistributed.             Note: Same configuration can be done for routes learned from other source type also e.g. for filtering specific connected routes to be exported into OSPF etc.
View full article
poagrawal ‎06-08-2017 03:03 AM
4,513 Views
0 Replies
1 Like
Symptom The Palo Alto Networks firewall does not advertise an aggregated route to its peer when it receives a prefix falling within the aggregated route range from the same peer.   For example: The Palo Alto Networks firewall has  routes for 10.0.2.0/24, 10.0.3.0/24 and 10.0.4.0/24 in its local-rib. It has been configured with an export policy to aggregate the routes into 10.0.0.0/16 and advertise this /16 route to its peer, as shown below. The peer has a route for 10.0.1.0/24, in its local rib, that it wants to advertise to the Palo Alto Networks firewall. The peer does not learn the aggregated 10.0.0.0/16, but learns the more specific routes 10.0.2.0/24, 10.0.3.0/24 and 10.0.4.0/24 from the firewall.   Cause If the Palo Alto Networks firewall learns a prefix from a peer that is part of the aggregated route that is advertised to the same peer, the firewall advertises the more specific routes under the aggregated route to the peer.   owner: kprakash
View full article
kprakash ‎05-12-2017 01:39 AM
6,748 Views
2 Replies
PAN-OS 6.1   Quality of Service (QoS) is not supported on aggregate interfaces and cannot be configured for them on Palo Alto Networks devices.     PAN-OS 7.0, 7.1, 8.0   support for Quality of Service (QoS) on aggregated interfaces was added and can be configured.   owner: fkhan
View full article
fakhan ‎05-11-2017 01:06 AM
26,837 Views
30 Replies
1 Like
Platform Restrictions The information in this article is not applicable to the Palo Alto Networks 7000 Series firewalls and is not officially supported for bandwidth monitoring.    Due to architectural design of the Palo Alto Networks 7000 platforms (7050 and 7080), the information in this article is not applicable and will not report accurate global throughput of the device.   For all other available platform models supporting QoS, this configuration will return global throughput data. We are evaluating possible code updates to correct this in a future software version as of this time.    Overview Firewall monitoring protocols, such as NetFlow or SNMP, and applications, such as Pan(w)chrome, can be used to view traffic passing through an interface on the Palo Alto Networks firewall. Implementing tools like ntop or nfsen for Netflow, or MRTG or Cacti for SNMP require extra effort to deploy. Additionally, if the NetFlow collector is not application-aware, it may not be able to drill down and graphically represent traffic by application.   Graphical visualization of traffic can be useful when trying to determine a cause for network saturation, or measuring network throughput using tools like iperf. There is an embedded graphing tool in PAN-OS that helps visualize the amount of traffic passing through an interface.   This document describes how to use the graphing tool in PAN-OS and leverage QoS classes to help group the graphing by applications.   Note: This will actually not apply to QoS on that traffic. However, if QoS is desired, see page 345 of PAN-OS Administrator's Guide 6.0 (English).   Steps From the WebGUI go to Network > QoS and click Add: Populate the information, and choose the interface to monitor. The traffic represented in the graph will be what is egressing the interface. If selecting an untrusted interface that is facing the ISP, it will be representing the 'Upload' traffic. This interface may be associated with IPSec tunnels. If IPSec tunnels are present, populate the information for the tunnel interfaces in the 'Tunneled Traffic' tab. Note: Since this will help visualize traffic egressing the interface, to visualize traffic for 'Download' add a QoS Interface for each interface facing the internal network. Commit changes, and select "Statistics" on the right: The following example shows a graphic of current 'Upload' traffic, or traffic egressing the selected interface: Note: All traffic will be classified, by default, as 'class 4.'   Matching Applications to QoS Class A specific application or groups of applications can also be defined on a QoS Policy, which matches them to a specific class. This helps quantify and visualize specific types of traffic egressing the interface.   The following screenshot displays how Peer-to-Peer traffic on Class 8 is observed. Follow the steps below to display Peer-to-Peer traffic: Go to the Applications tab to see which applications are running on the interface. Select the default-group to view a mix-and-match graphic per class.   Defining a Behavior for QoS Classes QoS Profiles can be modified to define a behavior for each QoS class. For further details, refer to Page 338 of   Note: To visualize more than one graphic simultaneously, open a separate browser tab or window.   owner: mivaldi
View full article
mivaldi ‎04-25-2017 12:38 PM
82,178 Views
20 Replies
Overview   When ipsec tunnels terminate on a Palo Alto Networks firewall, it is possible to decrypt the traffic using the keys registered under ikemg.log. This can be very useful for troubleshooting ike, and performance issues with ipsec tunnels such as packet-loss and out-of-order packets.   Details   On this article, we will illustrate how to decrypt ikev1 on main mode and ESP packet using the following topology. The same steps can be used with ikev2. By default, the debugging level of ikemgr is normal. To log the negotiated authentication and encryption keys, we must increase the debugging level to dump.   admin@FW1> debug ike global show sw.ikedaemon.debug.global: normal admin@FW1> debug ike global on dump admin@FW1> debug ike global show sw.ikedaemon.debug.global: dump   Packets can be captured anywhere between FW1 and FW2. On our test setup, we will take packet captures on FW1 following this guide https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Run-a-Packet-Capture/ta-p/62390. To capture clear and encrypted data between User1 and User2 we are going to use the following filters.   admin@FW1> debug dataplane packet-diag show setting -------------------------------------------------------------------------------- Packet diagnosis setting: -------------------------------------------------------------------------------- Packet filter   Enabled:                   yes   Match pre-parsed packet:   no   Index 1: 192.168.112.104[0]->192.168.125.110[0], proto 0            ingress-interface any, egress-interface any, exclude non-IP            ingress-interface any, egress-interface any, exclude non-IP   Index 2: 10.193.121.91[0]->10.193.121.93[0], proto 0            ingress-interface any, egress-interface any, exclude non-IP            ingress-interface any, egress-interface any, exclude non-IP -------------------------------------------------------------------------------- Logging   Enabled:                   no   Log-throttle:              no   Sync-log-by-ticks:         yes   Features:   Counters: -------------------------------------------------------------------------------- Packet capture   Enabled:                   yes   Snaplen:                   0   Stage receive           :  file rx     Captured:     packets - 0          bytes - 0     Maximum:      packets - 0          bytes - 0   Stage transmit          :  file tx     Captured:     packets - 1          bytes - 0     Maximum:      packets - 0          bytes - 0   Stage drop              :  file dr     Captured:     packets - 0          bytes - 0     Maximum:      packets - 0          bytes - 0    At this point, we need to bounce the ipsec tunnel to start a new negotiation process and log the ipsec phase1 and phase2 keys.   admin@FW1> clear vpn ike-sa gateway TO-FW2 admin@FW1> clear vpn ipsec-sa tunnel To-FW2   Then generate Traffic between User1 and User2 and make sure that the tunnel is up.   admin@FW1> show vpn ike-sa gateway TO-FW2   IKEv1 phase-1 SAs GwID/client IP  Peer-Address           Gateway Name           Role Mode Algorithm             Established     Expiration      V  ST Xt P hase2 --------------  ------------           ------------           ---- ---- ---------             -----------     ----------      -  -- -- - ----- 1               10.193.121.93          TO-FW2               Init Main PSK/ DH2/A128/SHA1    Apr.08 21:57:04 Apr.08 22:03:04 v1 12 4  1   Show IKEv1 IKE SA: Total 2 gateways found. 1 ike sa found.   IKEv1 phase-2 SAs GwID/client IP  Peer-Address           Gateway Name           Role Algorithm          SPI(in)  SPI(out) MsgID    ST Xt --------------  ------------           ------------           ---- ---------          -------  -------- -----    -- -- 1               10.193.121.93          TO-FW2               Init ESP/ DH5/tunl/SHA2 B57366C2 B82D7CDE 547B1BD5 9  1   Show IKEv1 phase2 SA: Total 2 gateways found. 1 ike sa found.   Decrypt ikev1 on main mode.   With ikev1, the identification and quick mode messages are encrypted. Sometimes it is necessary to decrypt them to verify which parameters were exchanged between the two peer.   Here is an example of an encrypted identification message.   To decrypt ikev1 messages, we need two pieces of information.   Initiator’s cookie that corresponds to the Initiator SPI on the packet capture. 294ff0e604e73f31 Encryption key that can be found on the ikemgr.log: Search for “cookie:294ff0e604e73f31” and then scroll through the negotiation messages untill you find the final computed encryption key. 2017-04-08 21:57:04 [DEBUG]: oakley.c:3157:oakley_compute_enckey(): final encryption key computed: 2017-04-08 21:57:04 [DEBUG]: oakley.c:3158:oakley_compute_enckey(): 793f8697 cc0e8cdb 5851496c 0acff14c   Next, go to Wireshark > Edit > Preferences > Protocols > ISAKMP > IKEv1 Decryption Table and enter the Initiator’s COOKIE and Encryption key:       And here is the decrypted identification message:        Decrypt ESP packets.   Decrypting ESP packets follows the same principle as ike, but require more parameters.     Protocol: IPv4 Src IP: The source IP of the ESP packets you want to decrypt. For the example above 10.193.121.91 Dst IP: The destination IP of the ESP packets you want to decrypt. For the example above 10.193.121.93 ESP SPI: You can find it on the packet capture under Encapsulation Security Payload. In our example, it is 0xb82d7cde Encryption and Authentication Algorithm: They are part of the output of ‘>show vpn flow ‘ command. admin@FW1> show vpn flow name To-FW2 | match algorithm         auth algorithm:         SHA256         enc  algorithm:         AES128   Encryption and Authentication Key which can be found on the ikemgr.log: 21.93[500]/0, satype=141 (ESP), spi=, wsize=4, authtype=41 (SHA256), enctype=15 (AES128), saflags=0x0, samode=137 (tunl), reqi d=0, lifetime hard time 180, bytes 0, lifetime soft time 146, bytes 0, enckey len=16 [3d6991e6a0f888d240c8d539a54676a7], authkey len=32 [bbac69f722297906c11d7d9038248ba3b509519a0e1e37bb0652752130c8324c]   Next, go to Wireshark > Edit > Preferences > Protocols > ESP Decryption and select “Attempt to detect/decode encrypted ESP payloads”:       Then edit the ESP SAs.     After that you will see the ESP packets decrypted.  
View full article
imsed ‎04-12-2017 12:03 PM
24,732 Views
4 Replies
4 Likes
Overview: This article focuses on explaining the meaning of 'error subcode 5 (Connection rejected)' while establishing BGP between two firewalls.   Details: Excerpt from RFC:   If a BGP speaker decides to disallow a BGP connection (e.g., the peer is not configured locally) after the speaker accepts a transport protocol connection, then the BGP speaker SHOULD send a NOTIFICATION message with the Error Code Cease and the Error Subcode "Connection Rejected".   This means that after initial TCP handshake between the BGP peers, when peer A receives a OPEN message from peer B, and peer A does not recognize peer B, it would send Notification message with Subcode "Connection Rejected"   Assume following topology: PA-1 (192.168.30.1)  -----  (192.168.30.2) PA-2   PA-2 has a misconfigured peer IP address: (instead of 192.168.30.1 it is configured as 192.168.30.3)     As soon as PA-2 (192.168.30.2) receives a OPEN message from PA-1, it sends a Notification message:     PA-1 shows this notification message being received and error code in routed.log:       Resolution: Edit the configuration to include correct peer IP address on the firewall.
View full article
poagrawal ‎04-05-2017 07:36 AM
5,508 Views
0 Replies
Overview This document explains how to calculate the number of SSL proxied sessions for a dataplane on a Palo Alto Networks device.   Details Use this command to show the software buffer pool for Proxy sessions: > debug dataplane pool statistics | match proxy   See this example: > debug dataplane pool statistics | match proxy         Proxy Session : 7055/7936     0x80000000b0dc7be0   The total number of ssl sessions proxied would be 7936 – 7055 = 881.   Note: Without an SSL session in an environment, the counter should show : 7936/7936.   owner: kadak
View full article
kadak ‎04-04-2017 02:48 AM
3,684 Views
1 Reply
Details What is a multi-path TCP? A m ulti-path TCP (MPTCP) is a modification to the TCP stack that allows an application’s data flow to be split over multiple TCP connections, split over multiple ports and/or entirely different interfaces and networks. Because the data flow is split over multiple TCP sessions (possibly over different networks), a given network security device is unable to reliably reassemble the session contents for threat inspection purposes.   The benefits of a multi-path TCP is it is a better resource utilization, better throughput and smoother reaction to failures.   The App/OS that supports multi-path may initiate multiple completely independent TCP sessions out of the local NIC(s), some of which may traverse the Palo Alto Networks firewall, depending on what sessions the endpoint establishes and the presence of multiple NICs on the device.  From a L4 perspective, everything is normal. However, at L7 it will most likely appear as fragments of application traffic if multiple MPTCP sessions are established, and the App-ID and threat scanning may or may not function correctly (leading to unknown-tcp or some other result).   Introduced in PAN-OS 8.0 MPTCP option can be removed to prevent multipath tcp sessions from being established   owner: harshanatarajan
View full article
harshanatarajan ‎03-28-2017 02:00 AM
4,615 Views
3 Replies
Ask Questions Get Answers Join the Live Community