ASA 9.1x Object Groups

[ciscotech45]

Hi,

I am used the older 8.0.X ASA software, so here's another confusion I have with the new 9.1x code. I unfortunately don't have an ASA 9.1x handy to try out these commands.

1. Here below is two different ways of creating the same service object as I understand. The first way is how I am used to doing it in the earlier code. And the second way is how it is with the new 9.1x code, I believe. My question is, what is the difference here ?(other than the fact that the second method allows the same object for both tcp and udp) and more importantly will the new 9.1x code accept either of these formats when I create a service object?

object-group service admin tcp

port-object eq 80

port-object eq 443

object-group service admin

service-object tcp http

service-object tcp https

2. The same question applies when creating network objects. In the two different methods below, will the ASA 9.1x accept either of these commands? also is one method better than the other in 9.1x?

object-group network remote-nets

network-object 10.8.0.0 255.255.0.0

network-object 10.9.0.0 255.255.0.0

object network remote-nets

subnet 10.8.0.0 255.255.0.0

subnet 10.9.0.0 255.255.0.0

Thank you.

[Jouni Forss]

Hi,

To my understanding in the first section where you list the 2 different "object-group" formats the second one is not a valid configuration

It would be

object-group service admin

service-object tcp destination eq http

service-object tcp destination eq https

I have used "object-group" only when there has been a considerable amount of ports needed to be opened. For example I have been tasked sometimes to open a lot of basic ports between internal networks in an internal firewall that sits between some networks. In this kind of "object-group" I have define many TCP/UDP ports and also ICMP.

I have then used it in an ACL in the following way for example

access-list OUTSIDE-IN permit object-group admin object-group SOURCE-NETWORKS object-group DESTINATION-NETWORKS

This has allowed to use a single ACL rule to allow a lot of the required service. Naturally in the "opened" for its still a big ACL rule.

In the second example where you are using "network" type "object-group" and "object" there is also one problem.

Only "object-group network" can contain multiple networks or host addresses under it. An "object network" can only contain a single "host" , "subnet" or "range". So entering the second "subnet" would simple overwrite your earlier "subnet" statement.

The "object" I guess is typically used for simple Auto NAT configurations to contain both the source address(es) and the actual "nat" command.

It can also be a parameter of a Manual NAT command (a "nat" command that is NOT under any "object") to tell either real/mapped source/destination network.

Naturally also if you prefer to have "object-group" and "object" in your ACL instead of the actual IP addresses and networks this might be an option. You can also group "object" under an "object-group".

Notice also that there is "object service". It can also be used in ACLs but also Manual NAT configurations to manipulate ports (can not be used in Auto NAT). As with "object network", the "object service" can only contain single statement but it can contain both source and destination port but this is rarely needed unless you are doing some pretty special NAT

Hope this helps

Feel free to ask more if needed.

- Jouni

[ciscotech45]

Thanks!!

So for creating the service object, will the 9.1x version accept both these formats (below) or should I only use the

"object-group service admin" format?

(OLD FORMAT)

object-group service admin tcp

port-object eq 80

port-object eq 443

(NEW FORMAT)

object-group service admin

service-object tcp destination eq http

service-object tcp destination eq https

[Jouni Forss · Accepted solution]

Hi,

You can use whichever one you like.

Do notice that they are used in a different way in the ACL statement for example.

If I were to use your above examples in an ACL that would allow all HTTP/HTTPS traffic they would look like this

OLD FORMAT

access-list TEST permit tcp any any object-group admin

NEW FORMAT

access-list TEST permit object-group admin-2 any any

I tested the above on my firewall just to give an example. I created the other "object-group" with another name as it naturally would not let me use 2 sama named "object-group".

The actual ACL created above would look like this in the "open" form.

access-list TEST; 4 elements; name hash: 0xd37fdb2b

access-list TEST line 1 extended permit tcp any any object-group admin (hitcnt=0) 0x258ea30a

  access-list TEST line 1 extended permit tcp any any eq www (hitcnt=0) 0xc56dc15e

  access-list TEST line 1 extended permit tcp any any eq https (hitcnt=0) 0x702064c1

access-list TEST line 2 extended permit object-group admin-2 any any (hitcnt=0) 0xd42bcde9

  access-list TEST line 2 extended permit tcp any any eq www (hitcnt=0) 0xc56dc15e

  access-list TEST line 2 extended permit tcp any any eq https (hitcnt=0) 0x702064c1

So the end result in the actual ACL is the same but the configuration format a bit different. I think the option to group all different protocols and ports under a single "object-group" would give a lot more flexibility to make rules. You wouldnt be limited to grouping together just TCP Ports but could combine UDP and ICMP for example.

As you can see the "object-group" you used before is just meant to group together certain TCP Ports and use them at the end of the ACL to tell the ports that need to be opened.

With the new "object-group" configuration option you would actually write "permit object-group admin" instead of "permit tcp". The "object-group" would actually tell what protocol is allowed and what ports belonging to it (if applicable).

So you are free to choose which one to use.

Hope this helps

- Jouni

[ciscotech45]

thanks very much for explanation and actually testing it out!

I also have a similar question regarding the network object group.Which of these (option-A or option-B) would be a better

way of doing it in the 9.1x code? And like in the case the service object, will the ACL syntax differ here also depending on which option  I choose below?

Option-A:

object-group network remote-nets

network-object 10.8.0.0 255.255.0.0

network-object 10.9.0.0 255.255.0.0

Option-B:

object network remote-net1

subnet 10.8.0.0 255.255.0.0

object network remote-net2

subnet 10.9.0.0 255.255.0.0

object-group network remote-nets  (unsure if I have the correct syntax below. I am basically trying to put the two network objects created above into this one object group)

object network remote-net1

object network remote-net2

And another basic question I have is, for the traffic to flow between two separate interfaces (or subinterfaces) on the same ASA which are in different security levels, I will need to do the nat exemption statement if I don't want the traffic to be NAT'd, correct? Just making sure the NAT exemption is not just for the VPN tunnel config..

Thank you.

[Jouni Forss · Accepted solution]

Hi,

The ACL syntax is not really that different compared to when you are using "object-group network" or "object network" in the ACL.

As a combined example allowing traffic from networks under "object-group" to a new under "object" would look like this

access-list TEST permit ip object-group OBJECT-1 object OBJECT-2

access-list TEST permit tcp object-group OBJECT-1 object OBJECT-2 eq www

access-list TEST permit udp object-group OBJECT-1 object OBJECT-2 eq domain

access-list TEST permit icmp object-group OBJECT-1 object OBJECT-2 echo

So only difference is the keyword/parameter "object-group" or "object" depending which type the following object actually is.

If you want to add the 2 created "object network" under an "object-group network" then you would use this format

object-group network remote-nets

network-object object remote-net1

network-object object remote-net2

So as you can see we need the "network-object object" to indicate that we are adding an actual "object" under this "object-group".

With regards to the traffic flow question there are many different situations.

• If you have no ACLs configured to the ASA interfaces then the "security-level" value determines from which interfaces networks you can initiate connections to which interfaces networks. (Allow from higher to lower)
• If you are using ACL on the interface then that will determine how traffic can be initiated. Typically ACLs are attached inbound direction so they only control connections initiated from behind that interface.
• Whether you use interface ACLs or not there are couple of situations where you might need additional commands on the ASA.
  • If you have 2 interfaces with equal "security-level" and want to keep it that way and also want to allow traffic between them you need to have the command "same-security-traffic permit inter-interface"
  • If you have a single interface which has traffic incoming to it and then forwarded back out through that interface then you will need the command "same-security-traffic permit intra-interface". The most common situation for this is when you have VPN Clients which need to connect to the Internet through the VPN connections to the ASA (outside interface) same naturally applies to connections between VPN connections.

In the new software you wont need to configure any NAT between your local interfaces if you dont want to NAT the networks.

The exception to this comes usually with VPN traffic. Then NAT0 is usually needed.  Since both your VPN traffic and Internet traffic usually flow between "inside" and "outside" interface that means that if there is no NAT0 configuration the traffic gets matched to the Dynamic PAT.

Hope this helps

- Jouni