Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Alby23
Contributor II

Pieces of configuration purged... what is the source...?

I'm a little bit confused.

In a FortiOS 5.4.0 appliance I've suddendly lost firewall policies and routing and in event logs I see these entries (attached image).

 

Same second... 4 commands. Any ideas???

11 REPLIES 11
pyy
New Contributor III

Purge means that someone delete all the section config

 

ex

config firewall policy

edit x

next .

.

.

edit y

next

 

edit 10

mpla mpla

next

purge

 

purge will delete x,y,10

 

So the admin add a static route/fw policy and  instead of use delete in order to delete the entry he use the purge and delete all the section

 

 

ede_pfau

Probably an upgrade gone wrong. Upgrades do not only comprise firmware code but transformation procedures as well. Somehow these went wild, that's where the 'purge' commands come in.

 

The routes and OSPF config etc. is just the last part of a config file. The FGT will boot with a partial config file just fine, surprisingly.

 

I'd rebuild the flash disk from scratch via the boot manager (connect via serial port, stop the boot process, reformat the disk, reload firmware via TFTP, reload the config).


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
emnoc
Esteemed Contributor III

I would use the cfg revision to see 'exactly' what was b4 and after. The log seems to show this was a "admin" event, so if that is true at least the log systems will have the address of the user.

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau

Just because of the 'admin (unidentified)' message I am speculating that this is an automatic sequence of code transformation, not a manual user action. 'purge' does make sense if you want to wipe some part of the config to immediately overwrite with the intended commands.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
emnoc
Esteemed Contributor III

Could be but the detail event log will show "who" admin really was if it was a admin  for each and every transaction log id. 

 

e.g 

Event Log> System 

  ( apply a filter or not depending on how busy your firewall is )

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Tiago_Aquino

The exact same issue happened to me. Have you found out anything about it?

Alig0r

Hi All,

 

just to close this thread, to help others concerned by this weird issue.

 

A customer of mine had got the same issue.

 

After creating a case to the FORTINET support team, post incident, it appeared that maybe the customer used the wizard to make some things. We should not use the wizard on a already configured fortigate, as it could delete / purge entire conf parts, conclusions of FORTINET Support team.

 

Best regards.

 

Alig0r

 

 

Tiago_Aquino

Hi. This might be true in your particular case. In ours, we use tacacs. A very few people know the admin password. And this admin user was the one, according to log, that did it. I suppose something not yet known, not someone, triggered the wizard events.
Jasb

I Just did this yesterday. Oops! I remember going through the wizard to see what it did. But I don't recall hitting finish or apply. I'm assuming the cancel but changed to finish on the last step and I clicked it. Either way the logs showed my IP and similar logs were produced. Apparently it deleted all the static routes and created two new default routes with the directly connected devices. Thanks to my counterpart --TD! Saved my (_)_)

 

Labels
Top Kudoed Authors