Management Articles

Featured Article
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,266 Views
0 Replies
User-created disk-image/machine-image backups to restore a VM-series firewall instance are not supported across all hypervisors, including public cloud platforms. This includes all functions that allow creating a copy of the disk and memory state of the instance.   To restore a VM-Series firewall, import a backup of the PAN-OS configuration on to a newly deployed VM-series firewall instance from a base image file or from the public cloud marketplace.
View full article
oconnellm ‎07-02-2018 06:25 AM
1,965 Views
0 Replies
Symptoms Currently, if you want to assign 4 CPU cores to a Palo Alto Networks VM series firewall inside VMWare ESXi version 6.5.0 build 4887370,  you are limited to 2  CPU cores, per socket. The only way that it will allow you to use 4 CPU cores is by using 2 cores per socket.  Please see image below. VM edit screen VMWare ESXi version 6.5.0 build 4887370 showing number of CPU Cores and Sockets. Diagnosis It has been discovered that this issue is specific to VMWare ESXi version 6.5.0 build 4887370.  NOTE: This is NOT a Palo Alto Networks VM issue, this is an issue withVMWare. You can apply as many CPU cores with VMWare ESXi version 6.5.0 update01 build 5969303.   Solution You have 2 options: You can upgrade the ESXi software to VMWare ESXi version 6.5.0 update01 build 5969303. As a workaround, the OVA file (Example:  PA-VM-ESX-8.0.5.ova), can be modified to alow a higher number of cores. See the following example of what was changed in the OVA file.   Old Entry:         <vmw:CoresPerSocket ovf:required="false">2</vmw:CoresPerSocket>   New Entry :         <vmw:CoresPerSocket ovf:required="false">16</vmw:CoresPerSocket>   Edit screen showing 4 CPU cores and 1 socket. NOTE: If more than two sockets are used, then you might experience performance issues because the packets may have to travel across the sockets.
View full article
hshah ‎01-11-2018 06:55 PM
3,030 Views
0 Replies
Symptoms Runtime link state (speed/duplex) shows 'unknown/unknown' when you run a command 'show interface management' on VM-Series Firewalls.   > show interface management   ----------------------------------------------------- Name: Management Interface Link status:   Runtime link speed/duplex/state: unknown/unknown/up   Configured link speed/duplex/state: auto/auto/auto   Diagnosis Solution This is expected behaviour in PAN-OS 8.0 and earlier.   You can find the speed/duplex state from the message in sysdagent.log which is generated when the link negotiation is performed or the link settings are changed.   When changing speed/duplex settings of management interface to '100Mbps-full-duplex':  2017-08-01 13:19:47.826 +0900 NET: HW config: eth0: { 'mode': 2, 'setting': 5, }  2017-08-01 13:19:47.826 +0900 NET: Changing eth0 to auto 0 adv 0x80 speed 100 duplex 1 When changing speed/duplex settings of management interface to '10Mbps-half-duplex':  2017-08-01 16:51:21.261 +0900 NET: HW config: eth0: { 'mode': 2, 'setting': 2, }  2017-08-01 16:51:21.261 +0900 NET: Changing eth0 to auto 0 adv 0x80 speed 10 duplex 0 When changing speed/duplex settings of management interface to 'auto-negotiate' (10GB full) :  2017-08-01 13:25:00.407 +0900 NET: HW config: eth0: { 'mode': 1, 'setting': 1, }  2017-08-01 13:25:00.407 +0900 NET: Changing eth0 to auto 1 adv 0xbf speed 10000 duplex 1  
View full article
anishinoya ‎10-25-2017 08:56 AM
1,725 Views
0 Replies
Question In a Multi VSYS configuration. when a user is logged in as vsys admin, that user is unable to see Interfaces and Zones assigned to that vsys. The Network Tab displays the following error message: Panel for undefined not registered.   Answer 1. Log in to the Web UI of the firewall. 2. Open a new tab in the same browser and navigate to https://<Management IP>/debug --which automatically navigates to the debug script.   3. Uncheck the option Minimize Javascript and click on Clear Preferences. 4. Close the browser, open a fresh window, and log in to the Web UI again.
View full article
ankumar ‎09-07-2016 03:53 PM
1,615 Views
0 Replies
Communication between two vsys via a transit vsys is not supported. Packet will be dropped by the firewall. Flow basic will show " packet dropped, from/to zone unavailable for policy lookup " Firewall will not be able to find the destination zone.   Workaround Lets say vsys1 wants to communicate to vsys 2 via vsys3.     Move the traffic from vsys1 to vsys3 and then out of the firewall. Now bring back the traffic from outside of the firewall to vsys3 and then to vsys2.   When Host1 tries to ping "ping 10.50.242.180" Host ping does not work.  The traffic will be dropped by the firewall. In order to make this work we have to do source + destination NAT on FW63 (using the topology above) and Host1 should ping to 10.50.244.180.   VSYS1 has one external zone TrustExternal, one Trust-L3 zone, TrustVR. VSYS1 has visisbility to VSYS VSYS2 has one external zone DMZExternal, one DMZ-L3 zone, DMZVR. VSYS2 has visisbility to VSYS3 VSYS3 has one external zone UntrustExternal one Untrust zone, UntrustVR. VSYS2 has visisbility to VSYS1, VSYS3   VSYS are configured as follows:     Zones are configured as follows:   DMZVR, TrustVR have a default route pointing towards UntrustVR. UntrustVR has a return route for 10.50.240.0/24 pointing towards TrustVR. UntrustVR has a return route for 10.50.242.0/24 pointing towards DMZVR :     Interfaces are configured as follows:     Security polices   VSYS1 has the following security policy to allow inbound and outbound traffic:     VSYS2 has the following security policy to allow inbound and outbound traffic:     VSYS3 has following security policy to allow inbound and outbound traffic:     VSYS3 source NAT:   Now we have to add 4 routes on FW63 Original subnet 10.50.240.0/24, 10.50.242.0/24 and NATed subnet 10.50.244.0/24, 10.50.245.0/24 pointing back to VSYS3:       NAT rule on FW63   When FiW63 receives a ping initiated from Host1 the source of that traffic will be 10.50.241.57 and the destination will be 10.50.244.180. Now we have to change the destination to 10.50.242.180 so that VSYS3 send traffic to Host2. We have to source NAT to FW63's interface IP. If the source NAT is not done then the VSYS firewall will drop the traffic because the return traffic will have source 10.50.242.180 and destination will be 10.50.241.57.  
View full article
pankaku ‎06-23-2016 07:05 PM
3,851 Views
0 Replies
All PAN-OS up to and including 7.0   VMware Tools is not supported on the Palo Alto Networks virtual firewall, because various security standards dictate that third-party software cannot be installed on a security device. The same is true for the Palo Alto Networks hardware firewalls, it does not allow the installation of third-party software on hardware firewalls.     From PAN-OS 7.1 and above, VMWare tools will be supported please refer to this article for more details: PAN-OS 7.1 Support for VMware tools on PA-VM platforms and Panorama VM     owner: rvanderveken
View full article
rvanderveken ‎04-15-2016 02:23 PM
5,360 Views
2 Replies
Details In a multi-vsys configuration, system and configuration logs are not visible on a per vsys basis. To view configuration and system logs, switch context to 'All' rather than specifying a particular vsys, as shown in the screenshots below.     Note: This is not based on the admin role of the account logged in as. Even with a superuser account, the system and configuration logs become unavailable upon switching the context from All to a specific vsys.   owner: sodhegba
View full article
sodhegba ‎09-08-2015 06:08 PM
3,493 Views
1 Reply
1 Like
Overview This document describes how to reinstall the current running PAN-OS software if the "Install" action is unintentionally clicked for a different software version and the Palo Alto Networks firewall is not rebooted.   For example, the firewall is currently running PAN-OS 6.0.6 software:   The "Install" link for a different software version (for example, 6.0.5) has been unintentionally clicked:   The Reboot Device dialog appears, but "No" is selected.   Details In order to revert back to 6.0.6 after canceling the reboot, the "Reinstall" option should be be clicked for the 6.0.6 software.   The following is the output of the debug swm status command before 6.0.5 has been mistakenly installed:   The following output is viewed when 6.0.5 has been mistakenly installed:   When the 6.0.6 "Reinstall" option is clicked, this software will be installed on the other sysroot partition:   With this action, version 6.0.6 will be loaded if the firewall is rebooted, instead of mistakenly installed 6.0.5.   owner: gbogojevic
View full article
gbogojevic ‎09-08-2015 12:35 PM
3,944 Views
2 Replies
1 Like
Issue With SFP links, setting the link-state down does not cause the link to go down. Hence, the virtual wire still shows as up.   Resolution Fiber links cannot be administratively down. The link state is determined only by actual link status. A virtual wire with one link fiber and other copper will inherit the characteristics of the fiber link.   owner: rkim
View full article
panagent ‎09-04-2015 10:59 AM
2,256 Views
0 Replies
No, it is not possible to restart a single VSYS without restarting the entire Palo Alto Networks firewall.   owner: ppatel
View full article
ppatel ‎08-31-2015 11:43 AM
1,917 Views
0 Replies
Issue When link state pass through is enabled in VWire, why do the logs only show one interface down?    Resolution  This is expected behavior.  As an example, if two interfaces, Ethernet 2/1 and  Ethernet 2/2, are configured as a VWire pair with link state pass through enabled, if Ethernet 2/1 goes down for any reason, Ethernet 2/2 will also go offline automatically. The Ethernet 2/1 event will be logged in the system logs but not the automatic link state change of  Ethernet 2/2     Only the link which triggered the failure is recorded in order to identify the link with the problem. One can confirm that Ethernet 2/2 is down either from the WebGUI by looking at the interface state or from CLI with the following command:  > show interface Ethernet 2/2.   owner:  sdurga
View full article
sdurga ‎08-27-2015 11:49 AM
3,197 Views
0 Replies
Issue Users are unable to access network resources. Even though the interface is properly configured the interface remains in a gray state. Resolution When troubleshooting the VM-Series firewall make sure that all the physical Interfaces are connected within the ESXi host. No traffic will be able to traverse the firewall if the interfaces are not connected within the ESXi host. To check this setting connect to the ESXi host using SSH or ESXi Console.  Navigate to Configure Management Network > Network Adapters, then verify that the interfaces in question are displayed as connected. Verify the vSwitch configuration by using the vSphere Client to connect to vCenter or directly to the ESXi host. Verify that the vSwitch or Port Group is configured to accept Promiscuous mode, MAC Address Changes, and Forged Transmits. Verify each vSwitch to have a physical NIC from the ESXi host to which it is assigned. In the example below Vmnic1 is connected to the ISP router and vmnic0 is connected to an internal switch. The vSwitch environment must be configured properly to pass traffic and in this scenario each vSwitch much connect to a separate physical VMNIC. owner: jperry
View full article
jperry1 ‎12-28-2014 08:25 PM
3,209 Views
0 Replies
1 Like
Symptom Dynamic Block List or External Block List (EBL) does not show list of IP's. For example: > request system external-list show name DYNAMIC_BLOCKLIST1 Server error : external list file not found Cause If Multi-VSYS is enabled on the Palo Alto Networks firewall and the Dynamic Block List is created on another VSYS, then the block list can be viewed by entering the appropriate VSYS. Run the following CLI commands to enter the target VSYS and view the block list: Verify that multi-vsys is turned on: > show system setting multi-vsys on Enter target VSYS > set system setting target-vsys vsys1 Session target vsys changed to vsys1 Display the dynamic block list > request system external-list show name DYNAMIC_BLOCKLIST1 vsys1/DYNAMIC_BLOCKLIST1: Next update at: Mon Jul 29 15:00:24 2013 IPs: 2.56.0.0/14 5.72.0.0/14 5.180.0.0/14 14.129.0.0/16 14.192.48.0/21 14.192.56.0/22 31.11.43.0/24 31.14.103.0/24 31.222.200.0/21 To configure a Dynamic Block List, go tot Objects > Dynamic Block Lists and click Add. For example: owner: jlunario
View full article
pagmitian ‎09-17-2013 08:07 AM
4,358 Views
0 Replies
Overview When running the show routing route command or when the virtual router runtime stats are viewed, a set of flags are displayed next to each route. This document defines the displayed routing flags. Details Routes that start with A are active AS - Active and static AR - Active and learned via RIP S - Not active due to a higher metric and static AC - Active and a result of an internal interface (connected) - Destination = network AH - Active and a result of an internal interface (connected) - Denstinaion = Host only A?B - Active and learned via BGP O1 - OSPF external type-1 O2 - OSPF external type-2 Oi - OSPF intra-area Oo - OSPF inter-area owner: jteetsel
View full article
jteetsel ‎01-18-2013 05:13 PM
14,028 Views
4 Replies
2 Likes
Overview A null route (blackhole route) is a network route (routing table entry) that goes nowhere. Matching packets are dropped (ignored) rather than forwarded, acting as a kind of very limited firewall. The act of using null routes is often called blackhole filtering. There is no Null interface as such on the Palo Alto firewalls, that can be used to point the routes out to, something like: set route 10.251.240.0/21 interface null preference 250 Workaround Create an unnumbered dummy tunnel interface (tunnel interface with out an IP) and point the route on that interface, with the next hop option selected as "none". owner: kprakash
View full article
kprakash ‎01-16-2013 02:31 PM
8,135 Views
4 Replies
Issue There were multiple static routes in the virtual router (VR) to the same destination and no metric was specified. The default metric for static routes is 10. Resolution Delete the route through configure mode of the CLI, then add it back in with the proper metric. On the CLI: # delete network virtual-router <VR name> routing-table ip static-route <static route name> # set network virtual-router default routing-table ip static-route <static route name> interface <interface value> destination <ip/netmask> metric <value> nexthop ip-address <ip> On the WebUI: Go to Network > Virtual Routers. Select the appropriate VR. Go to the IPv4 tab within Static Routes: owner: jseals
View full article
panagent ‎01-03-2012 02:23 PM
2,776 Views
0 Replies
Overview When a Palo Alto Networks firewall is enabled with multiple virtual system (multi-vsys) capability in the device management Web GUI or on the CLI, users are able to select the desired vsys to view or amend policies and objects. Users must have 'Superuser,' 'Device administrator,' or 'Device administrator (read-only)' access level. This command is not available for 'Virtual system administrator' nor 'Virtual system administrator (read-only).' Steps By default, the CLI starts in global mode where system statistic and global counters are accumulated from all vsys. Certain configurations such as security, NAT, and PBF do not have a "global" setting. Instead the CLI will return the configuration for the first default vsys1. To determine if the firewall has multi-vsys enabled use this command: > show system info | match vsys multi-vsys: on To view a list of vsys configured on the firewall use this command: > set system setting target-vsys ? none     none vsys1    vsys1 vsys2    vsys2 <value>  <value> To switch to a particular vsys, use the following CLI command to select a virtual system (VSYS). This enables the issuing of commands and collection of data specific to one virtual system (VSYS): > set system setting target-vsys <value> Use this command to switch to vsys2: admin@PA> set system setting target-vsys vsys2 The CLI will return the following if the vsys name is valid. Session target vsys changed to vsys2 admin@PA-vsys2> Note: The "-vsys2" in the command prompt indicates which vsys mode is active. Verify that it is in fact the correct and intended vsys before issuing a configuration change. The vsys name is case-sensitive. See this example: >admin@PA> set system setting target-vsys VSYS2 Server error : set -> system -> setting -> target-vsys 'VSYS2' is not an allowed keyword To return to default view use this command: > set system setting target-vsys none See this example: >admin@PA-vsys2> set system setting target-vsys none The session target vsys changed to none. >admin@PA> Note: The -vsys is no longer in the command prompt. This command is not persistence. Once the admin is logged off and/or logged on to a new session, the system will start in the default global mode. There is no option to set a "default vsys" for CLI. See Also Virtual Systems (VSYS) owner: spriromruen
View full article
nrice ‎01-22-2010 12:29 PM
27,388 Views
3 Replies
Ask Questions Get Answers Join the Live Community