Object groups on the ASA allow you to group similar types of components within a single heading.  You can use this heading for access-lists, which in turn can be used for access control, NAT, encryption, and traffic classification.

The two main object groups I use are network and service.

The network object group is where you put subnets and hosts, while the service object group is for protocols and ports.

As a best practice I use specific groups on most installs, they are:

INSIDE_NETWORKS
VPN_NETWORKS
HTTP_SERVERS
HTTPS_SERVERS
SMTP_SERVERS

HTTP_SERVERS, HTTPS_SERVERS and SMTP_SERVERS all would contain their specific hosts.  Using these for access-control you may have a configuration that looks like the following:

object-group network HTTP_SERVERS
  network-object host 1.1.1.1
  network-object host 1.1.1.2

access-list OUTSIDE_IN_ACL permit tcp any object HTTP_SERVERS eq www

This would allow anyone port 80 access to servers with an external address of 1.1.1.1 or 1.1.1.2.

Should I need to add additional web servers in the future, I just create the NAT and add the host to the object group.

If this were written out individually it would look like (you can see this in a “show access-list”):

access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.1 eq www
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.2 eq www

I would follow suite using HTTPS_SERVERS for port tcp 443 and SMTP_SERVERS for tcp port 25 and would have access-list entries for each type.

Should a server need to be in all three, such as an Outlook Web Access server running on a single node exchange environment, you would add this server to each of the three object groups.
Some people react with “why not create an object group with all three ports in it and have one line that allows all the ports?”

My feeling is how often are these three ports mixed?  There are instances where every server that is HTTP is HTTPS as well, and then it may make sense to make a network object group called WEB_SERVERS for all of the hosts and a service for the ports allowed to these servers.  Such a configuration would look like the below:

object-group network WEB_SERVERS
  network-object host 1.1.1.1
  network-object host 1.1.1.2
object-group service WEB_SERVER_POTS
  service-object tcp eq 80
  service-object tcp eq 443

access-list OUTSIDE_IN_ACL permit object WEB_SERVER_PORTS any object WEB_SERVERS

if this were to be broken out it would look like

access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.1 eq 443
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.1 eq 80
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.2 eq 443
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.2 eq 80

This is great as long as all of your web servers are always both http and https, but if you have some that are https only, then using the broken out model with HTTP_SERVERS and HTTPS_SERVERS is the most secure method.

So how do you use this for ease of NAT and Encryption?  Here is a common scenario:

I have insider users at 10.15.10.0/24 and 10.17.10.0/24 and vpn users attached to my ASA with a range of 10.25.10.0/24 and 10.27.10.0/24.  These wireless users can be either dial-in or lan to lan tunnels, in this case lets use dial-in and discuss LAN to LAN and multiple sites later.  Either way when the internal users want to communicate with them I don’t want their traffic to be NATed, but when the internal users communicate to the internet, I need to NAT them so it will correctly route.  On top of this my dial-in users will use their local internet (split-tunneling) as opposed to tunneling all their internet traffic to the ASA.

In this case I would use my object groups INSIDE_NETWORKS and VPN_NETWORKS extensively to server multiple functions.

So lets talk about the INSIDE_NETWORKS first.  I want to list all of my internal networks here, in this case

Object-group network INSIDE_NETWORKS
network-object 10.15.10.0 255.255.255.0
network-object 10.17.10.0 255.255.255.0

For my VPN networks, same thing using the VPN_NETWORKS group

object-group network VPN_NETWORKS
network-object 10.25.10.0 255.255.255.0
network-object 10.27.10.0 255.255.255.0

Now I have a foundation I can build on.  From here I have many purposes to fill.  Lets start with NAT to the internet.

First thing is to create an access-list that defines the traffic to be NATed.

access-list INSIDE_NAT permit ip object INSIDE_NETWORKS any

Then we need to setup our NAT

nat (inside) 1 access-list INSIDE_NAT
global (outside) 1 interface

In this I allowing only my internal networks to NAT to the outside interface global IP when I go to the internet.  This helps with spoofing addresses, because if I am not NATting it it should not be routable on the internet.  Of course reverse route verify is also a great tool for this.

Next lets look out using these for my split-tunneling on the VPN.  Again the first thing is to create access-list, this will look the same as my NAT access-list, but I will create another just for management purposes.

access-list VPN_SPLIT_TUNNEL permit ip object-group INSIDE_NETWORKS any

I would then use this in my group-policy to split tunnel.

group-policy DEMO internal
group-policy DEMO attributes
  vpn-idle-timeout none
  vpn-tunnel-protocol IPSec
  split-tunnel-policy tunnelspecified
  split-tunnel-network-list value VPN_SPLIT_TUNNEL

Now as I add new objects to the INSIDE_NETWORKS group, they are automatically entered into my split tunnel as well as my NAT (first example).

So that brings us to VPN no nat.  In this case I want to have my real IP addresses show up to my dial-in users, in order to do this I have to bypass the NAT when going only to my VPN users and not when going to the internet.  Again, I start with an access-list.

access-list NO_NAT permit ip object-group INSIDE_NETWORKS object-group VPN_NETWORKS

Then I configure my NAT

nat (inside) 0 access-list NO_NAT

Again, as I add networks to my INSIDE_NETWORKS or new pools and networks to my VPN_NETWORKS the NO_NAT access-list is automatically updated.  I don’t have to update this in multiple places in order for it to take effect in many parts of the ASA configuration.

So now let’s make it a bit more complicated.  I have multiple sites running on an MPLS with Site to Site VPNs and remote access vpns as well.  This is handled with object groups, but with a bit more refinement.

Lets say I have Miami, Alpharetta and Las Vegas locations on an MPLS with the internet all coming from the Alpharetta ASA.  I also have 2 remote sites, New York and Chicago over site to site VPNs terminating on the ASA.  The networks are below.

MPLS Sites:
Miami – 10.64.0.0/16 and 10.65.0.0/16
Alpharetta – 10.32.0.0/16 and 10.33.0.0/16
Las Vegas – 10.96.0.0/16 and 10.97.0.0/16

Remote Sites
New York – 10.128.0.0/16 and 10.129.0.0/16
Chicago – 10.160.0.0/16 and 10.161.0.0/16

My VPN users are at 10.192.1.0/24 and 10.192.2.0/24

In this case I would create the following object groups to manage all of this.
object-group network ALPHARETTA_NETWORKS
network-object 10.32.0.0 255.255.0.0
network-object 10.33.0.0 255.255.0.0
object-group network MIAMI_NETWORKS
network-object 10.64.0.0 255.255.0.0
network-object 10.65.0.0 255.255.0.0
object-group network LAS_VEGAS_NETWORKS
network-object 10.96.0.0 255.255.0.0
network-object 10.97.0.0 255.255.0.0
object-group network NEW_YORK_NETWORKS
network-object 10.128.0.0 255.255.0.0
network-object 10.129.0.0 255.255.0.0
object-group network CHICAGO_NETWORKS
network-object 10.160.0.0 255.255.0.0
network-object 10.161.0.0 255.255.0.0
object-group network REMOTE_VPN_USRES
network-object 10.192.1.0 255.255.255.0
network-object 10.192.2.0 255.255.255.0

You can then nest object groups within each other to come back to your two major network categories from above, VPN_NETWORKS and INSIDE_NETWORKS.

object-group network VPN_NETWORKS
group-object REMOTE_VPN_USERS
group-object CHICAGO_NETWORKS
group-object NEW_YORK_NETWORKS
object-group network INSIDE_NETWORKS
group-object ALPARETTA_NETWORKS
group-object MIAMI_NETWORKS
group-object LAS_VEGAS_NEWORKS

With this setup I can now be very granular on access control as well as VPN tunnel setup.  From an access control standpoint I can control per site the access to a DMZ off the ASA or specific sites using access-lists and the specific object group for that site.  For instance, I can put an access-list on the inside that allows only Miami networks to 10.1.1.1 on the DMZ

access-list INSIDE_IN_ACL permit ip object-group MIAMI_NETWORKS host 10.1.1.1

I can utilize the INSIDE_NETWORKS like I did before for NAT and split tunneling and the VPN_NETWORKS group for no nat along with the INSIDE_NETWORKS again.

For my crypto maps for my site to site VPNs I need to create access-lists for the match commands that determine the specific interesting traffic.  Lets say I want to create an access list for my crypto MAP to New York.  It is one line.

access-list NEW_YORK_CRYPTO permit ip object-group INSIDE_NETWORKS object-group NEW_YORK_NETWORKS

At each remote site I would have similar object groups and access-lists, but switch around a little.  So the New York site, the object-group INSIDE_NETWORKS would only contain the NEW_YORK_NETWORKS object group and the VPN_NETWORKS would contain ALPHARETTA_NETWORKS, MIAMI_NETWORKS and LAS_VEGAS_NETWORKS.

Utilizing Cisco Security Manager and having everything named the same, you can now make single changes to object groups and have your NAT, Crypto MAPs, No NATs and remote users vpn split tunnels updated all at the same time.  If you are doing it by hand, the same script can be applied to all of your remote sites should you add a network in on location, thus reducing total cost of ownership and increasing productivity.

Troubleshooting is also much easier as your access-lists are smaller and if you are using well named object-groups, they are easy to follow.  If you use the command “show run access-list” you only see typed lines of the access-list, so all of the lines that are broken out because of the object group are not seen, making it easier to read your configuration.

An ASA using these best practices is easy to use and far more secure.

Author: Alex Jerrold, Cisco CCIE Security

Posted at Geeknick

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Filed under: Network Security

Like this post? Subscribe to my RSS feed and get loads more!