How ASA Real Time Log Viewer Displays Connections

This post will help you to understand how sessions / connections in ASA are built and teared down in ASA and how they are displayed in Real Time Log Viewer..

Outside router is connected to Internet directly and MGT cloud used here is only to get ASDM access to ASA. If you want to configure this lab, click here to go to the post which explains how to setup ASDM access to an ASA.

Interfaces on ASA are configured as following..

Service Policy to inspect ICMP & ICMP error is configured on ASA.





Configuration on R1..

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.10.254

R1(config)#int e0/0
R1(config-if)#ip address 192.168.10.1 255.255.255.0

Configuration on R2..

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.3
R2(config)#ip route 192.168.10.0 255.255.255.0 192.168.20.254

R2(config)#int e0/0
R2(config-if)#ip address 192.168.20.2 255.255.255.0
R2(config)#int e0/1
R2(config-if)#ip address 192.168.23.2 255.255.255.0

Configuration on R3..

R3(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.2
R3(config)#ip route 192.168.10.0 255.255.255.0 192.168.20.2

R3(config)#int e0/0
R3(config-if)#ip address 10.1.1.10 255.255.255.0
R3(config-if)#ip nat inside
R3(config)#int e0/1
R3(config-if)#ip address 192.168.23.3 255.255.255.0
R3(config-if)#ip nat outside

R3(config)#access-list 10 permit any
R3(config)#ip nat inside source list 10 interface Ethernet0/0 overload

What happens when I send ICMP packets from R1?

Let's now ping 8.8.8.8 from R1 and see how it is displayed in Log Viewer..
(click on the image to view in full readable size)

Connection is built from source of 192.168.10.1 to the destination of 8.8.8.8
Connection is Teared down from source of 8.8.8.8 to the destination of 192.168.10.1
You can see that the port numbers are 0 because ICMP works at network layer.
However there can be a source port number sometimes for the 192.168.10.1 from the next time you send traffic.

Only these 2 lines will be displayed even for 1000 packets sent continuously because an ASA session is created for a flow, not to a single packet..

What happens when I send TCP packets from R1?

Let's try to telnet 8.8.8.8 from R1..

Connection is built from source of 192.168.10.1 to the destination of 8.8.8.8
Connection is Teared down from source of 8.8.8.8 to the destination of 192.168.10.1
You can see that the destination port number is 23 on google.

What happens if an ACL blocks the outgoing traffic on path?

R3's e0/0 is configured with an ACL as following..

R3(config)#access-list 20 deny any
R3(config)#int e0/0
R3(config-if)#ip access-group 20 out

I am pinging 8.8.8.8 from R1. 5 denies imply the 5 icmp packets generated from R1.

Connection is built from source of 192.168.10.1 to the destination of 8.8.8.8
Next 5 logs say it is denied from 192.168.23.3 which is the firewall side interface of R3
Final log says Connection is Teared down from source of 8.8.8.8 to the destination of 192.168.10.1 which means that tearing down log does not really say its a packet originated from 8.8.8.8, It is built from the ASA..

What happens if an ACL blocks the incomming traffic on path?

Now I removed the access-group command on e0/0 interface and applied it in e0/1 interface on R3.

It is the same as before. That means if it is blocked from an ACL on any interface on a router in the path, that router will send the deny log from its firewall side interface.

Is this "Deny" log comes just because it is denied from an ACL?

Well let's findout, I just deleted the ACL 20 from R3 router and shut the e0/0 interface of OUT.

It looks like the "Deny" log is not just saying it is blocked by an ACL. It just says it is unreachable..

But if you looked closer you will notice that the details say Type 3 Code 13 for the ACL blocking instances & it says Type 3 Code 1 when the interface is shut.

Let's see what are those, (source from iana.org)

Ah, now you can say what has really happened ryt? It's an Administration Prohibit when it is blocked by an ACL and it is a destination unreachable when the e0/0 is shut.

If that was a TCP session, how will it be displayed?

Well, let's telnet to 8.8.8.8 while e0/0 of R3 is down..

It looks almost same. Denied packets will display an ICMP error & the connection will be displayed as a TCP connection.

What will be displayed if  the firewall side interface is down on a router?

Now let's see what will happen when the e0/1 interface of R3 is down..

Well, you don't see any issue. It looks exactly like it is working correctly. But It is not.

Let's continue the lab..

What will happen if a route is missing to the incoming path?

Let's findout, I removed the ip route 192.168.10.0 255.255.255.0 192.168.23.2 route from R3.

Well it looks like working too. But really it is not.. Let's continue with another scenario before we come to a conclusion..

What will happen if a route is missing to the outgoing path?

I removed the ip route 0.0.0.0 0.0.0.0 10.1.1.2 route from R3.

It is just same as scenario which the e0/0 of R3 was down. A destination unreachable from the firewall side interface of R3.

So it looks like  you can't really say it is working just by looking the log viewer. Log will not say anything if the firewall side interface of a router is down or a route to the firewall side is missing in the path.. Aslo the final tearing connection down log will be sourced from the real destination which the connection was to be initiated even though it was a failure, that one is just a firewall log (does not tell it is a packet came from a real host)