End-of-Life (EoL)
Many of the troubleshooting steps for the VM-Series firewall are very similar to the hardware versions of PAN-OS. When problems occur, you should check interface counters, system log files, and if necessary, use debug to create captures. For more details on PAN-OS troubleshooting, refer to the article on Packet Based Troubleshooting.
The following sections describe how to troubleshoot some common problems:
Basic Troubleshooting
Recommendation for Network Troubleshooting Tools It is useful to have a separate troubleshooting station to capture traffic or inject test packets in the virtualized environment. It can be helpful to build a fresh OS from scratch with common troubleshooting tools installed such as tcpdump, nmap, hping, traceroute, iperf, tcpedit, netcat, etc. This machine can then be powered down and converted to a template. Each time the tools are needed, the troubleshooting client (virtual machine) can be quickly deployed to the virtual switch(es) in question and used to isolate networking problems. When the testing is complete, the instance can simply be discarded and the template used again the next time it is required.
For performance related issues on the firewall, first check the Dashboard from the firewall web interface. To view alerts or create a tech support or stats dump files navigate to Device > Support.
For information in the vSphere client go to Home > Inventory > VMs and Templates, select the VM-Series firewall instance and click the Summary tab. Under Resources, check the statistics for consumed memory, CPU and storage. For resource history, click the Performance tab and monitor resource consumption over time.
Installation Issues
Issues with deploying the OVA
The VM-Series is delivered as a file in the Open Virtualization Alliance (OVA) format. The OVA image is downloaded as a zip archive that is expanded into three files. If you are having trouble deploying the OVA image, make sure the three files are unpacked and present and, if necessary, download and extract the OVA image again.
The ovf extension is for the OVF descriptor file that contains all metadata about the package and its contents. The mf extension is for the OVF manifest file that contains the SHA-1 digests of individual files in the package. The vmdk extension is for the virtual disk image file.
The virtual disk in the OVA image is large for the VM-Series; this file is nearly 900MB and must be present on the computer running the vSphere client or must be accessible as a URL for the OVA image. Make sure the network connection is sufficient between the vSphere client computer and the target ESXi host. Any firewalls in the path will need to allow TCP ports 902 and 443 from the vSphere client to the ESXi host(s).There needs to be sufficient bandwidth and low latency on the connection otherwise the OVA deployment can take hours or timeout and fail.
Why does the firewall boot into maintenance mode?
If you have purchased the VM-1000-HV license and are deploying the VM-Series firewall in standalone mode on a VMware ESXi server or on a Citrix SDX server, you must allocate a minimum of 5GB memory to the VM-Series firewall.
To fix this issue, you must either modify the base image file (see How do I modify the base image file for the VM-1000-HV license?) or edit the settings on the ESXi host or the vCenter server before you power on the VM-Series firewall.
Also, verify that the interface is VMXnet3; setting the interface type to any other format will cause the firewall to boot into maintenance mode.
How do I modify the base image file for the VM-1000-HV license?
If you have purchased the VM-1000-HV license and are deploying the VM-Series firewall in standalone mode on a VMware ESXi server or on a Citrix SDX server, use these instructions to modify the following attributes that are defined in the base image file (.ova or .xva) of the VM-Series firewall.
Important: Modifying the values other than those listed hereunder will invalidate the base image file.
Modify the base image file (only if using the VM-1000-HV license in standalone mode)
Open the base image file, for example 7.0.0, with a text editing tool such as notepad.
Search for 4096 and change the memory allocated to 5012 (that is 5 GB) here: <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:Description>Memory Size</rasd:Description> <rasd:ElementName>4096MB of memory</rasd:ElementName> <rasd:InstanceID>2</rasd:InstanceID> <rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>4096</rasd:VirtualQuantity> <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:Description>Memory Size</rasd:Description> <rasd:ElementName>5120MB of memory</rasd:ElementName> <rasd:InstanceID>2</rasd:InstanceID> <rasd:ResourceType>5</rasd:ResourceType> <rasd:VirtualQuantity>5120</rasd:VirtualQuantity>
Change the number of virtual CPU cores allotted from 2 to 4 or 8 as desired for your deployment: <Item> <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits> <rasd:Description>Number of Virtual CPUs</rasd:Description> <rasd:ElementName>2 virtual CPU(s)</rasd:ElementName> <rasd:InstanceID>1</rasd:InstanceID> <rasd:ResourceType>3</rasd:ResourceType> <rasd:VirtualQuantity>2</rasd:VirtualQuantity> <vmw:CoresPerSocket ova:required="false">2</vmw:CoresPerSocket> </Item> <Item> <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits> <rasd:Description>Number of Virtual CPUs</rasd:Description> <rasd:ElementName>4 virtual CPU(s)</rasd:ElementName> <rasd:InstanceID>1</rasd:InstanceID> <rasd:ResourceType>3</rasd:ResourceType> <rasd:VirtualQuantity>4</rasd:VirtualQuantity> <vmw:CoresPerSocket ova:required="false">2</vmw:CoresPerSocket> </Item>
Alternatively you can deploy the firewall and before you power on the VM-Series firewall, edit the memory and virtual CPU allocation directly on the ESXi host or the vCenter server.
Licensing Issues
Why am I unable to apply the support or feature license?
Have you applied the capacity auth-code on the VM-Series firewall? Before you can activate the support or feature license, you must apply the capacity auth-code so that the device can obtain a serial number. This serial number is required to activate the other licenses on the VM-Series firewall.
Why does my cloned VM-Series firewall not have a valid license?
VMware assigns a unique UUID to each virtual machine including the VM-Series firewall.So, when a VM-Series firewall is cloned, a new UUID is assigned to it. Because the serial number and license for each instance of the VM-Series firewall is tied to the UUID, cloning a licensed VM-Series firewall will result in a new firewall with an invalid license. You will need a new auth-code to activate the license on the newly deployed firewall. You must apply the capacity auth-code and a new support license in order to obtain full functionality, support, and software upgrades on the VM-Series firewall.
Will moving the VM-Series firewall cause license invalidation?
If you are manually moving the VM-Series firewall from one host to another, be sure to select the option, This guest was moved to prevent license invalidation.
Connectivity Issues
Why is the VM-Series firewall not receiving any network traffic?
On the VM-Series firewall. check the traffic logs ( Monitor > Logs). If the logs are empty, use the following CLI command to view the packets on the interfaces of the VM-Series firewall:
show counter global filter delta yes
Global counters:
Elapsed time since last sampling: 594.544 seconds
Total counters shown: 0
In the vSphere environment, check for the following issues:
Check the port groups and confirm that the firewall and the virtual machine(s) are on the correct port group
Make sure that the interfaces are mapped correctly.
Network adapter 1 = management
Network adapter 2= Ethernet1/1
Network adapter 3 = Ethernet1/2
For each virtual machine, check the settings to verify the interface is mapped to the correct port group.
Verify that either promiscuous mode is enabled for each port group or for the entire switch or that you have configured the firewall to Enable Use of Hypervisor Assigned MAC Addresses.
Since the dataplane PAN-OS MAC addresses are different than the VMNIC MAC addresses assigned by vSphere, the port group (or the entire vSwitch) must be in promiscuous mode if not enabled to use the hypervisor assigned MAC address:
Check the VLAN settings on vSphere.
The use of the VLAN setting for the vSphere port group serves two purposes: It determines which port groups share a layer 2 domain, and it determines whether the uplink ports are tagged (802.1Q).
Check the physical switch port settings
If a VLAN ID is specified on a port group with uplink ports, then vSphere will use 802.1Q to tag outbound frames. The tag must match the configuration on the physical switch or the traffic will not pass.
Check the port statistics if using virtual distributed switches (vDS); Standard switches do not provide any port statistics

Recommended For You