I have added my firewalls in a panorama. but sometimes i am getting the below commit error:-
VPN-SSL is not a newly created object. it was there since i added the firewall in the panorama. And the issue occurs intermittently.
Panorama version - 9.1.2
Firewall version- 9.0.8
your suggestions appreciated.
The messages seem to be when you are pushing from panorama TO a FW, vs just committing locally to only the Panorama.
The error you get appears that the object is NOT located in some area.
So, do you need to create the service HTTPS object?
If you want to say the Panorama xml is corrupted, that would be fine by me.
You generally asking if we have seen this issue and how to resolve it.
How do you want to proceed? Do you want to fool the Panorama and manually add objects that are not seen?
If the objects are seen on the Panorama, do you want to delete the object and then re-create it?
We are here to help you. What response are you looking for.
Before you go out and chase a possible XML corruption issue or anything like that, simply update Panorama. 9.1.2 is incredibly early in 9.1's branch and multiple validation and config errors were addressed in 9.1.4. Install the current recommended release (9.1.6) and report back if that doesn't fix your issues. It should.
Yes, this error occurs while pushing the configuration from panorama to the firewall.
yes, you are right, when i check the object the location is showing "local" not a "shared". example(Firewall-1).
This issue occurs intermittently because at the morning i tried to commit 2 times it failed and the 3rd time is succeded without any changes i believe i need to upgrade the panorama.
I have upgraded the panorama up to 9.1.6 yesterday. and today i was facing the same issue again. while i try to commit and push from panorama getting the below error:-
For the solution, i reconfigure the address object(VPN-SSL) and it is working fine. but i am suspecting this issue is occurring intermittently and not able to find the cause of this issue.
I would open a TAC case if you see the same behavior again. It looks like the address object itself isn't known within the configuration for some reason. You could do a compare between the functional and non-functional XML files if you took a copy of the candidate config prior to fixing the issue, as there might be something that isn't being read correctly.
Regardless, you would really need to dive into the logs to fix the issue. That's not something we can really do over the community, but is something that TAC can help you with.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!