You are on page 1of 5

Expedition

New Feature: Ghost object identification

Release: ver 1.1.9

A few feature added in the ver 1.1.9 release is the identification of ‘Ghost’ objects which may require
special handling based on the configuration file sources.

This document will discuss the following topics:


• What are Ghost objects
• Handling of Ghost objects

What are ‘Ghost’ objects

Ghost objects are temporary address objects (address objects only) that were learned from the
migration of the Security and NAT policies. The ghost objects are displayed under ‘OBJECTS à Address’
along with a new counter in the project dashboard.

The reasons for address objects being classified as ghost objects is that there were no learned address
objects for them in the source configuration. Expedition creates temporary address objects to alert the
user of their existence, and if needed to take action by transforming the ghost address objects into
actual address objects if needed.

Cases where address objects will be classified as ghost objects:

The addresses were added inline in a policy, as opposed to referencing an address object.

Example:
access-rule from LAN to WAN action allow source address 10.1.1.0/24 service DNS destination address
10.190.1.1/32

1
In the access rule above the source and destination address create addresses inline without using
address object.

This option available in 3rd party firewall configurations but also applies to PanOS firewall configurations
based on the scenario’s below.

1. PanOS allows the adding of address objects inline without having to define address objects
2. PanOS allows the local firewall policy configurations to reference Panorama pushed address
objects. In this scenario the address objects will not be found in the running-config of the
firewall and the address objects will be marked as ghost objects.

To identify the ghost address objects, a predefined filter is available to display only the ghost objects
from within the ‘Address’ display

Handling of ‘Ghost’ objects

Action may need to be taken on ghost address objects based on the origination of the configuration file.

1. If the source configuration file is a PanOS firewall, no action needs to be taken in most cases.
a. If the ghost objects are written inline within a policy, the user can choose to not create
address objects.
b. If the ghost objects are from pushed address objects from Panorama (but used in locally
added policies) then no action should be taken to create the address objects as this will
cause a conflict with the Panorama management of the device.

2. If the source configuration file is a 3rd party firewall and the user is at the beginning phase of a
migration, the user can choose to transform the ghost objects into address objects that we
written into the configuration an can be merged into a Panorama config as well.

To transform the ghost objects into address objects use the steps below.

2
Use the predefined filter to display a list of the ghost objects.

If you were to click on any of the ghost objects a warning will be displayed.

To transform the ghost objects, highlight the objects to be transformed and select the transform option.

3
After transforming the ghost objects to address object you will need to clear the filter to display all
address objects.

The address objects can now be edited and merged into a base config.

The project statistics will also be updated with the ghost object count. The total count for the address
objects will be added to by the transformed ghost objects to address objects.

4
5

You might also like