Management Articles

Featured Article
If a packet larger than the configured MTU is received, and the DF (Don't Fragment) IP option is set, the Palo Alto Networks firewall returns an ICMP "frag-needed" message, notifying the sender that a smaller MTU is needed.   The sender's TCP/IP stack should be capable of responding with smaller packets. However, certain devices block these ICMP messages which will cause the sender to resend the oversized packet.   To avoid this situation in an IPSec VPN tunnel, the MTU/MSS (Maximum Segment Size) should be changed on the network devices that terminate the tunnel. When a packet passes through an IPSec tunnel that terminates on a Palo Alto Networks device, the device automatically changes the MSS value for the TCP handshake to alleviate such a situation.   > show routing fib       :flow_fwd_mtu_exceeded   forward   Packets lengths exceeded MTU :flow_fwd_ip_df  forward   Packets dropped: exceeded MTU but DF bit present
View full article
Ameya-Kawimandan ‎07-05-2016 01:31 PM
0 Replies
Issue When monitoring Palo Alto Networks firewall bandwidth and network traffic using a Netflow Analyzer, there may be some discrepancy in the 'incomplete' application traffic reported on the Netflow server, versus what is reported on the ACC tab of the firewall.   Details For TCP sessions, the first packet in a TCP handshake does not have any application data to perform pattern matching using signatures to identify the application. Hence, the App-ID cache is used to identify the application on the very first packet. It aids in Policy Based Forwarding rules, in which a routing decision needs to be based on the first packet of a session. In this case, the routing decision is made before an application can be identified, so the App-ID cache provides a mechanism for making a best estimate for forwarding decisions.   The firewall tries to identify the new session's application based on any matching cached entry associated with the same Destination IP/Port. When no match is found, the firewall terms the application as 'none,' which is seen as 'incomplete' in data records sent to the Netflow collector. See this example:   Once the firewall sees further data exchange for this session, it identifies the application based on pattern matching signatures and sends an updated data record for the session to the Netflow collector.   Some Netflow collectors stick to the first identification of the application for a session and do not make further changes in the session's application field. This creates the discrepancy in the amount of 'incomplete' application traffic reported by the firewall versus what is reported by the netflow server.   owner: apasupulati  
View full article
apasupulati ‎02-09-2016 12:53 PM
0 Replies
    In order to find out whether the PA-500 has 1GB RAM or 2GB RAM, run the command "show system resources"   admin@PA-500> show system resources   top - 05:23:04 up 17 days,  6:21,  0 users,  load average: 0.00, 0.03, 0.00 Tasks:  89 total,   1 running,  88 sleeping,   0 stopped,   0 zombie Cpu(s):  2.0%us,  3.6%sy,  6.5%ni, 87.8%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st Mem:   2028576k total,  1972820k used,    55756k free,   154316k buffers Swap:  2212876k total,     3320k used,  2209556k free,   769132k cached   The above output shows that the device has 2GB RAM.   If the firewall had 1GB ram this field would show Mem: 938136k.        
View full article
skumar1 ‎11-24-2015 01:59 PM
0 Replies
Issue There can be two symptoms: The Palo Alto Networks firewall has an incomplete ARP entry for a host on the network (for example, default gateway): > show arp all maximum of entries supported :      2500 default timeout:                    1800 seconds total ARP entries in table :        1 total ARP entries shown :           1 status: s - static, c - complete, e - expiring, i - incomplete interface         ip address      hw address        port              status   ttl -------------------------------------------------------------------------------- ethernet1/4    (incomplete)      ethernet1/4         i      1 The firewall is responding to every ARP request on the network. On the endpoint, select any random IP address, try to ping it and you'll see an ARP entry with the firewall's IP MAC: $ ping -w 2 $ ping -w 2 $ arp -an ? ( at 00:1b:17:00:04:13 [ether] on eth4 ? ( at 00:1b:17:00:04:13 [ether] on eth4 Cause It is likely there is an incorrectly configured source NAT policy with a mask length that is not /32. For example, if an interface is configured with IP address, then the NAT IP should be configured as (with /32 mask). The NAT IP in this example should not be configured as Resolution With a large number of NAT rules, it can be difficult to narrow down the policy. Three methods to identify the NAT rule are described below. The first two are safe to perform, the third option involves enabling debugs on the dataplane and should be used cautiously. Method 1 Identify the offending pool: > show running global-ippool Idx  Type             From                             To              Num   Ref. Cnt ---- ---------------- -------------------------------- --------------- ---   ---------- 3    Dynamic IP/Port    1     1 6    Dynamic IP/Port    256   1 Note: Pool 6 is using 256 addresses in network. To determine which policy, run the following command, then press "/" (slash), then type in: "idx: 6" (there is space between double colon and 6 and if needed go back a little bit by pressing the up arrow key). > show running nat-policy [...] dmz_Out {         from dmz;         source any;         to outside;         to-interface ethernet1/4 ;         destination any;         service  any/any/any;         translate-to "src: (dynamic-ip-and-port) (pool idx: 6)";         terminal no; } See the incorrectly configured rule is dmz_out. Method 2 Run a single command, which basically tells the firewall to output all rule names and src NAT translations, where a range of IPs is used. In this case, the rule name that precedes the translation is the offending rule. > show running nat-policy | match {\|src:[^\(]*- "Rule 1" { smtp04-in { smtp04-out { smtp03-out { "Internet outbound" { dmz_Out {         translate-to "src: (dynamic-ip-and-port) (pool idx: 6)"; "Rule 4" { "Rule 5" { smtp03-in { Method 3 Important! Use cautiously, because this method enables debugs on the dataplane. Enable debug on DP: > debug dataplane packet-diag clear all > debug dataplane packet-diag set filter match non-ip only > debug dataplane packet-diag set filter on > debug dataplane packet-diag set log feature flow arp > debug dataplane packet-diag set log on > debug dataplane packet-diag clear log log After trying to send the communication through the firewall (or pinging from the firewall default gateway): > ping source host Review the DP debug files: > less dp-log pan_task_* It is possible to go to the next file by pressing "n" At some point, the following appears, which may be similar to: Received ARP packet from port ethernet1/4 Packet decoded dump: L2:     00:50:56:a3:10:5a->00:1b:17:00:04:13, type 0x0806 ARP:    hardware type 0x0001         protocol type 0x0800         hardware size 6         protocol size 4         opcode REPLY         sender mac address 00:50:56:a3:10:5a         sender ip address         target mac address 00:1b:17:00:04:13         target ip address ARP packet sent from translated IP in NAT rule index 5 in vsys 1 ARP packet sent to interface ethernet1/4 IP ARP packet parse complete, learn: no, target myself: yes, gratuitous ARP: no In the example above, the firewall states that someone is using the IP address, which firewall it is using in NAT rule index 5. Note: Index 5 means only active policies (disabled policies do not count) and it starts from 0. The easiest way is to again run command " > show running nat-policy " and count policies. Fix Details This is how the rule looked in the WebGUI and CLI:                > show config running [...] dmz_Out {      to outside;      from dmz;      source any;      destination any;      service any;      nat-type ipv4;      source-translation {           dynamic-ip-and-port {                translated-address;           }      }      to-interface ethernet1/4; } At a glance, there is nothing wrong with this rule, however after some investigation see that the is really an object:  {               ip-netmask;             } This would be difficult to find just by browsing through the WebUI. Change the netmask to the appropriate one (most likely /32) and verify. See how the rule looks after the change: > show running nat-policy dmz_Out {         from dmz;         source any;         to outside;         to-interface ethernet1/4 ;         destination any;         service  any/any/any;         translate-to "src: (dynamic-ip-and-port) (pool idx: 7)";         terminal no; } > show running global-ippool Idx  Type             From                             To              Num   Ref. Cnt ---- ---------------- -------------------------------- --------------- ---   ---------- 3    Dynamic IP/Port    1     1 7    Dynamic IP/Port  1     1 In the example above, note a different pool ID used by the very same rule, but only a single IP address is used. This behavior is seen in PAN-OS 6.0 only, but seems to work fine in earlier releases. owner: rweglarz
View full article
RafalWeglarz ‎07-30-2014 07:01 AM
4 Replies
Ask Questions Get Answers Join the Live Community