Tag Archives: asa

Using Objects with Access Lists

What if you are asked to use objects in access lists. Note we are saying objects here – not object groups. The big difference is that an object can only contain a single entity. Let’s take a look at a sample configuration. In fact – let’s allow a return ping from a device on the outside like we did in earlier access list posts, but this time, we will use objects. I am using real gear in this example since my crappy little GNS3 image does not support the use of objects, only object groups.

ASA Topo

object network INSIDEHOST
 host 10.10.10.1
object network OUTSIDEHOST
 host 192.168.1.1
object service PINGREPLY
 service icmp echo-reply
access-list OUT_IN permit object PINGREPLY object OUTSIDEHOST object INSIDEHOST
access-group OUT_IN in interface outside

Sure enough – this config worked great:

Rack4R1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Rack4R1#

In fact – if you look at the access list – you see it is enumerated normally:

ASA3# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list OUT_IN; 1 elements; name hash: 0x16c2190a
access-list OUT_IN line 1 extended permit object PINGREPLY object OUTSIDEHOST object INSIDEHOST (hitcnt=0) 0x088a9534 
  access-list OUT_IN line 1 extended permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply (hitcnt=1) 0x088a9534 
ASA3#

ASA Access Control Lists Basics Part 2 of 2

This is a follow up to our previous post – please check that one out as we are going to pick up right where we left off.

Screenshot 2015-03-28 08.46.12

Let’s now add an outbound access list on that outside interface and see if we do indeed start to break other types of access through the ASA. We will create one that permits Web traffic outbound:

access-list OUT_OUT permit tcp host 10.10.10.1 host 192.168.1.1 eq www
access-group OUT_OUT out interface outside

Now we just created a bit of a nightmare. Telnet is indeed broken from the inside as it is hitting this access list and getting dropped:

R1#telnet 2.2.2.2
Trying 2.2.2.2 ...
% Connection refused by remote host 
R1#

We can certainly see why it is most common to use inbound access lists on the ASA.

Now Cisco understands that this can all get a bit confusing…inspection, access-lists, access-list direction…so they provide a very powerful tool on the ASA to help you in troubleshooting. The Packet Tracer.

In our previous post – we said that R2 should be able to respond to pings from the inside. We chose to test that by actually going to the device (R1) and initiating the ping. But we could have stayed right on the ASA and confirmed things with Packet Tracer as follows:

ASA1# packet-tracer input outside icmp 192.168.1.1 0 0 10.10.10.1
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.10.10.0      255.255.255.0   inside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUT_IN in interface outside
access-list OUT_IN extended permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply 
...
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
ASA1#

Another powerful tool you can utilize if you are troubleshooting your access lists on the ASA is logging. In our case, the results of our packet tracer above show that the ECHO REPLIES from R2 will be permitted, but of course we have an access list outbound on the outside interface that will actually drop the ECHO packets. In order to see this, I will enable logging and send the results to the console and then try our ping…

ASA1(config)# logging on

ASA1(config)# logging console 7

So now, this is what shows up on the ASA when we try the ping:

%ASA-4-106023: Deny icmp src inside:10.10.10.1 dst outside:192.168.1.1 (type 8, code 0) by access-group "OUT_OUT" [0x0, 0x0]

We love this kind of reporting, letting us know exactly why R1 can no longer ping R2!

I hope you enjoyed this two part series on basic access list usage on the ASA.