cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
892
Views
2
Helpful
6
Replies

ASA ≥ 9.18.4.x: object dependency checks are broken

Bernd Nies
Level 1
Level 1

I noticed a new odd behaviour of ASA 9.18.4.22. Object-group and object duplicate and dependency checks no longer work. It used to complain when one edits an object-group and adds an object that already existed. Now nothing shown at all. Also it used to complain when deleting an object that it could not be deleted because it was still in use by an object-group or an access-list. 

 

 

firewall1/context2/act# show run object-group id Some-Object-Group
object-group network Some-Object-Group
network-object 1.0.0.0.0 255.0.0.0
network-object 2.0.0.0.0 255.0.0.0
network-object 3.0.0.0.0 255.0.0.0

firewall1/context2/act#  conf t
firewall1/context2/act(config)# object-group network Some-Object-Group
firewall1/context2/act(config-network-object-group)#  network-object 3.0.0.0.0 255.0.0.0
firewall1/context2/act(config-network-object-group)# exit

 

 

On a firewall with an older release (e.g. Version 9.16(3)23) adding a duplicate network-object shows a warning like this:

 

 

WARNING: Adding obj (network-object 3.0.0.0 255.0.0.0) to grp (Some-Object-Group) failed; object already exists

 

 

Don't know if that was before on that version, but definitely not on a version prior to 9.18.4.x. We don't have this behaviour on ASA firewalls running 9.16.x.

On ASA 9.18.4.24 deleting an network-object that was used in an object-group showed no error that the network-object is still used in an object-group. Instead ASA adds a duplicate network-object in same object-group:

 

 

firewall1/context2/act(config)# show run object-group id dummy-group-1
object-group network dummy-group-1
 network-object object dummy-object-1
 network-object object dummy-object-2

firewall1/context2/act(config)# show run object id dummy-object-1
object network dummy-object-1
 host 1.0.0.0

firewall1/context2/act(config)# show run object id dummy-object-2
object network dummy-object-2
 host 2.0.0.0

firewall1/context2(config)# no object network dummy-object-1

firewall1/context2(config)# show run object-group id dummy-group-1
object-group network dummy-group-1
 network-object object dummy-object-1
 network-object object dummy-object-2
 network-object object dummy-object-1

 

 

Removing duplicate causes firewall to panic and reboot.

 

 

firewall1/context2/act(config)# object-group network dummy-group-1
firewall1/context2/act(config-network-object-group)# no  network-object object dummy-object-1

Coredump starting....
Corehelper: /opt/cisco/csp/cores/core.lina.10.1266.1717407923
Waiting for Corehelper to finish....
Livecore: generating coredump of 1266
[New LWP 1377]
[New LWP 1378]
[New LWP 1379]
[New LWP 1380]
[New LWP 1382]
[New LWP 1383]
[New LWP 1384]
[New LWP 1385]
[New LWP 1386]
[New LWP 1387]
[New LWP 1388]
[New LWP 1389]
[New LWP 1390]
[New LWP 1391]
[New LWP 1392]
[New LWP 1393]
[New LWP 1394]
0x000000fff79a474c in pthread_cond_timedwait () from /lib64/libpthread.so.0
warning: target file /proc/1266/cmdline contained unexpected null characters

 

 

 

1 Accepted Solution

Accepted Solutions

Bernd Nies
Level 1
Level 1

Cisco declared this bug as a new feature since 9.18.1 ...

Firewall Features

Forward referencing of ACLs and objects is always enabled. In addition, object group search for access control is now enabled by default.

You can refer to ACLs or network objects that do not yet exist when configuring access groups or access rules.

In addition, object group search is now enabled by default for access control for new deployments. Upgrading devices will continue to have this command disabled. If you want to enable it (recommended), you must do so manually.

Caution

 

If you downgrade, the access-group command will be rejected because it has not yet loaded the access-list commands. This outcome occurs even if you had previously enabled the forward-reference enable command, because that command is now removed. Before you downgrade, be sure to copy all access-group commands manually, and then after downgrading, re-enter them.

We removed the forward-reference enable command and changed the default for new deployments for object-group-search access-control to enabled.

https://www.cisco.com/c/en/us/td/docs/security/asa/asa918/release/notes/asarn918.html

I wonder why this behaviour was changed. Getting ready for integrating ASA into Firewall Management Center from FTD?

View solution in original post

6 Replies 6

Bernd Nies
Level 1
Level 1

Does somebody else encounter this bug or know in which release it will be fixed? We have it on ASA 9.18.4.22.

Bernd Nies
Level 1
Level 1

It also affects objects and object-groups used by access-lists. An object or object-group used by an access-list can be removed without an error. The access-list line still exists, but points to a non-existing object or object group.

Bernd Nies
Level 1
Level 1
I setup today an ASAv from scratch on our VMware environment for testing various releases. Upgraded from ASAv 9.12.3.12 to 9.16.4. There all the object dependencies check still work. After upgrading to base 19.18.4 and then also latest interim 9.18.4.29. Dependency checks do not work. Same issue with 9.20.2.22.
 
That bug is in the entire ASA release from 19.18.4 and above!
 

Please tell us bug id if TAC opens one.

 

Bernd Nies
Level 1
Level 1

I will. They probably name the bug after me. I found so many.

Bernd Nies
Level 1
Level 1

Cisco declared this bug as a new feature since 9.18.1 ...

Firewall Features

Forward referencing of ACLs and objects is always enabled. In addition, object group search for access control is now enabled by default.

You can refer to ACLs or network objects that do not yet exist when configuring access groups or access rules.

In addition, object group search is now enabled by default for access control for new deployments. Upgrading devices will continue to have this command disabled. If you want to enable it (recommended), you must do so manually.

Caution

 

If you downgrade, the access-group command will be rejected because it has not yet loaded the access-list commands. This outcome occurs even if you had previously enabled the forward-reference enable command, because that command is now removed. Before you downgrade, be sure to copy all access-group commands manually, and then after downgrading, re-enter them.

We removed the forward-reference enable command and changed the default for new deployments for object-group-search access-control to enabled.

https://www.cisco.com/c/en/us/td/docs/security/asa/asa918/release/notes/asarn918.html

I wonder why this behaviour was changed. Getting ready for integrating ASA into Firewall Management Center from FTD?

Review Cisco Networking for a $25 gift card