Why a forced Target Negate No?

[BobNida]

I've had a case open with Palo Alto support for over a month and the person I got says they've not seen this issue before. I doubt we are blazing new trails here and I just don't understand how this can actually be unfamiliar.

Our Palo Alto is a recent install of a converted configuration from a different firewall platform. The implementation vender is no longer available.

I alter a Security Policy Rule to remove one single address object (a /32) from the source tab, removing one single object and leave the 8 other remaining incumbent source objects.

When I go to Commit and Push (from Panorama) and Preview Changes, Panorama is adding changes I did not make. It adds this Target Negate No, in the form of the following.

target {
negate no;
}

I have a number of questions.

1. Why is the management system installing commands I did not select?
2. If it is necessary for the platform to work, why isn't it already in the configuration.
3. If I allow Panorama to insert this command, which I did not explicitly select, what is the expected outcome? Is there an interruption to communication?

[S.Cantwell · Accepted solution]

Hello there

You are fine to push your configuration and it should not interrupt, presuming you are running 9.1 on the FWs and Panorama. 

As for the negate line... it is boolean logic that is pretty much programmed on every security device, only here, we get to see what is being pushed. 

For example, I do not want any foreign (non-USA) country inbound to my FW.

So I use the negate lines to say allow [(not=yes) USA] inbound.

In your case, the Panorama is deploying allow [(negate=no) and your 8 IPs).  Perfectly acceptable.

After 10 years of experience on the platform, please allow me to alleviate your hesitancy.  I often see the XML is changed when pushing from Panorama, and I am confident that your configuration should be acceptable/valid and will work.

What other questions can we answer?

[BPry · Accepted solution]

@BobNida 

1. Why is the management system installing commands I did not select?

Like most GUI based management solutions, Panorama is programmed to manipulate the configuration in a very specific manner. It's not uncommon (in fact, it's extremely common) for someone using CLI/API for the majority of the configuration work and mixing in GUI to see changes like this take place in the XML configuration.

Whoever did your initial configuration migration likely did it through expedition, which is similar to directly modifying the configuration file. Or they did it through CLI/API. When you modify it in the GUI of Panorama, Panorama simply inputs what it's been programmed, which includes including a negate no entry.
2. If it is necessary for the platform to work, why isn't it already in the configuration.

It's absolutely not necessary for the configuration to work or pass validation. If it isn't included the configuration is parsed as if the <negate>no</negate> is present. 
3. If I allow Panorama to insert this command, which I did not explicitly select, what is the expected outcome? Is there an interruption to communication?

Absolutely not. No interruption to communication will take place. Panorama is simply adding a statement that it expects to be present. The fact that it isn't already present is making it automatically default to <negate>no</negate> because that's already the default implied status. 

[BobNida]

Thanks both of you for your prompt assistance.  I opened a case with PA support over a month ago.

After I posted this question in this community, the PA support person on the case suggested I "upgrade" from 9.1.7 to 9.0.10 in response to my ticket's initial request about this inserted command.  It is my understanding that the implementer started us out on 9.1, therefore we would not have a 9.0.x saved config to restore to (what I understand from the steps in a document I find on PA's website)....