Using and Configuring PIX/ASA/FWSM Object Groups

Posted on 12:10 AM by Bharathvn


This document discusses object groups, a feature introduced in PIX code version 6.2. Object grouping allows objects such as IP hosts or networks, protocols, ports, and Internet Control Message Protocol (ICMP) types to be collected into object groups. Once configured, an object group can then be used with the standard conduit or access-list PIX commands in order to reference all objects within that group. This reduces the configuration size.

Note: You cannot rename the object groups. You need to delete them and apply them again with the changes.

Note: Once the access-list is created with object groups, it must be applied to the interface with the access-group command.



There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco PIX Software Release 6.2(2) and later

  • Cisco 515 PIX Firewall (any PIX model works with these configurations)

  • Cisco ASA with Software release 7.0 and later

  • Cisco Firewall Service Module (FWSM) that runs software version 1.1 and later

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Related Products

The information in this document is also applicable to the Cisco 5500 Series Adaptive Security Appliance (ASA) that runs software version 7.0 and later.


For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Use Object Groups

When you use an object group within a command, you must use the keyword object-group before the group name, as shown in this example.

access-list 100 permit object-group protocols object-group
remotes object-group locals object-group services

In this example, protocols, remotes, locals, and services are previously defined object group names. Object groups can also be nested, where you can include one object group as a subset of another object group.

The command set is shown in this output.

object-group grp_id

object-group description description_text

group-object object_grp_name

object-group icmp-type grp_id

icmp-object icmp_type

object-group network grp_id

network-object host host_addr

network-object net_addr netmask

object-group protocol grp_id

protocol-object protocol

object-group service grp_id {tcp|udp|tcp-udp}

port-object eq service

port-object range begin_service end_service

Configure Object Groups

ICMP-Type Configuration

The ICMP-type object group is used in order to specify specific ICMP types for use only with ICMP access control lists (ACLs) and conduits. A full list of ICMP types is located in the PIX command reference for the object-group command.

(config)#object-group icmp-type icmp-allowed
(config-icmp-type)#icmp-object echo
(config-icmp-type)#icmp-object time-exceeded

(config)#access-list 100 permit icmp any any object-group icmp-allowed

Network Configuration

Use the network object group in order to specify host IP addresses or subnet ranges that you want to define in an ACL or conduit. Host IP addresses are prefixed with the keyword host, and can be either an IP address or a hostname already defined with the name command. You can use this object group as either the source or destination in the associated ACL/conduit.

(config)#name myFTPserver

(config)#object-group network ftp_servers

(config-network)#network-object host
(config-network)#network-object host myFTPserver


(config)#access-list 101 permit ip any object-group ftp_servers

If this list consists only of FTP servers, this specific example applies.

(config)#access-list 101 permit tcp any object-group ftp_servers eq ftp

Protocol Configuration

Use the protocol object group in order to specify a protocol(s) that you want to define in an ACL or conduit. You can use this object group as the protocol type only in the associated ACL or conduit. Note that the allowed protocols for this object group are only the standard PIX protocol names allowed in an access-list or conduit command, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Generic Routing Encapsulation (GRE), Enhanced Interior Gateway Routing Protocol (EIGRP), Encapsulating Security Payload (ESP), Authentication Header (AH), and so on. Protocols that sit on top of TCP or UDP cannot be specified with a protocol object group. Instead, these protocols use an object group, as shown in this example.

(config)#object-group protocol proto_grp_1

(config-protocol)#protocol-object udp
(config-protocol)#protocol-object tcp
(config-protocol)#protocol-object esp

(config)#access-list 102 permit object-group proto_grp_1 any any

Service Configuration

Use the service object group in order to specify specific or ranges of TCP and/or UDP ports that you want to define in an ACL or conduit. You can use this object group as either the source port(s) or destination port(s) in the associated ACL/conduit, as shown in this example.

(config)#object-group service allowed_prots tcp
(config-service)#port-object eq ftp
(config-service)#port-object range 2020 2021

(config)#object-group service high_ports tcp-udp
(config-service)#port-object range 1024 65535

(config)#access-list 103 permit tcp any object-group
high_ports any object-group allowed_prots

Note: Enhanced service object-groups were introduced with the release of software version 8.0. Enhanced service object-groups enable the ASA/PIX to combine IP protocols together in the same service group, which eliminates the need for protocol and icmp-type specific object groups. The protocol type must not be specified in order to configure an enhanced service object-group.

(config)#object-group service RTPUsers
(config-service)#service-object icmp echo-reply
(config-service)#service-object icmp echo
(config-service)#service-object tcp http
(config-service)#service-object tcp https
(config-service)#service-object tcp http
(config-service)#service-object tcp pptp
(config-service)#service-object udp domain
(config-service)#service-object udp isakmp
(config-service)#service-object esp
(config-service)#service-object gre
(config)#access-list acl_inside permit object-group RTPUsers any

(config)#show access-list acl_inside
access-list acl_inside line 1 extended permit object-group RTPUsers any
access-list acl_inside line 1 extended permit icmp any echo-reply (hitcnt=0)
access-list acl_inside line 1 extended permit icmp any echo (hitcnt=0)
access-list acl_inside line 1 extended permit tcp any eq www (hitcnt=0)
access-list acl_inside line 1 extended permit tcp any eq https (hitcnt=0)
access-list acl_inside line 1 extended permit udp any eq domain (hitcnt=0)
access-list acl_inside line 1 extended permit esp any (hitcnt=0)
access-list acl_inside line 1 extended permit gre any (hitcnt=0)
access-list acl_inside line 1 extended permit udp any eq isakmp (hitcnt=0)
access-list acl_inside line 1 extended permit tcp any eq pptp (hitcnt=0)

Object-Group Nesting Configuration

Only object groups of the same type can be nested within another. For example, you cannot nest a protocol-type object group within a network-type object-group.

In order to nest a group within a group, issue the group-object subcommand. In this example, you can use the all_hosts group in an ACL or conduit in order to specify all four hosts. Or, you can use either host_grp_1 or host_grp_2 in order to specify only the two hosts within each group.

(config)#object-group network host_grp_1

(config-network)#network-object host
(config-network)#network-object host

(config)#object-group network host_grp_2

(config-network)#network-object host
(config-network)#network-object host

(config)#object-group network all_hosts

(config-network)#group-object host_grp_1

(config-network)#group-object host_grp_2



This section provides information you can use in order to confirm your configuration works properly.

Certain show commands are supported by the Output Interpreter Tool ( registered customers only) , which allows you to view an analysis of show command output.

  • show running-config object-group—Shows the currently defined ACLs.

  • show access-list —Shows the ACL and the associated hit counter for each line. This command shows the expanded ACL entries for each object group defined.

  • clear object-group [grp_type]—When entered without a parameter, the clear object-group command removes all defined object groups that are not used in a command. The use of the grp_type parameter removes all defined object groups that are not used in a command for that group type only.



This error message appears:

error message: "ERROR: Unable to add, access-list config limit reached"


This error message indicates that the security appliance is close to the limit on the ACL for this context.

Refer to Specifications for information about how the FWSM allocates its resources.

The mapping between the rules and the memory allocation is not a one to one mapping. It actually depends on the rule, and how it is programmed in hardware. There are two options available in order to maximize the use of your ACE memory:

Simplify ACE Antries

These recommended practices allow you to summarize and simplify your ACE entries:

  • Use contiguous host addresses whenever possible. Aggegrate host statements in ACEs/object-groups into networks.

  • Use 'any' instead of networks, and use networks instead of hosts when possible.

  • Try to simplify object-groups. This can potentially save hundreds of ACEs when the ACLs are expanded.

    Group together individual port statements into a range, for example.

Repartition Memory Allocation

Another option is to repartition the memory allocated for ACE on each partition. This option requires that you reboot the FWSM. Use caution with this approach and make sure you accommodate your current ACE.

The FWSM basically partitions the memory allocated for ACE into 12 partitions, and it allocates memory for each. This is done automatically.

In 2.3(2) and later, you can use the resource manager in order to re-allocate the memory based on the number of contexts you have. Complete these steps:

  1. In order to determine how many contexts you have, issue the show context count command.

  2. Verify this with the configuration. Then, issue the show resource acl-partition command.

    This command informs you of the number of partitions you have.

  3. If you have more partitions than your defined context, issue the resource acl-partition command in order to match the number of partitions to the number of contexts.

  4. Save the configuration and reboot the FWSM.

This command gives you a bit more memory for the ACE, whether this is enough depends on the ACE you add to the context.

One drawback of this remapping is that if you want to add another context, you must reallocate the memory mapping again. This causes less memory to be available to each context and can break current ACE definitions. The memory allocated to the FWSM is a finite amount of 20MB, and it is carved out accordingly on a predetermined manner or through this manual resource allocation. You can not borrow memory from other parts of the module for this.