Using ACLs with Debug

[Anonymous]

I was attempting to see if a VMware server was syncing time with a internet time server.  I could not ping the timeserver from the router so I wanted to be sure the request was leaving the outside interface of my router.  I setup an ACL to look for UDP port 123 traffic.  I would run a debug on that ACL and it wouldn't catch the traffic.  I finally, and with greater ease, called up my Private security policy sessions and saw that the traffic was NATed to the internet.

What is the correct method of using Debug with ACLs?  Do they need to be applied to a security policy before they work?

Thanks,

Dan

[Anonymous · Accepted solution]

Thank you for asking this question.  There are several ways to monitor traffic by using access-control lists (ACLs) for debugging purposes.  One way is to use the debug access-list <name> command to activate debug messages (for a specified list) associated with ACL operation. Debug messages are displayed (real time) on the terminal (or Telnet) screen. The debug access-list <name> command provides debug messages to aid in troubleshooting ACL issues. These debug messages are populated by traffic matches that occur when traffic is filtered through the ACL. The ACL must have the logging feature enabled in order to populate the debug message; however, the ACLs do not have to be used in the firewall security policy.  Here is an example:

---------------------------------------------------

To capture the traffic to and from a particular peer:

ip access-list extended CAPTURE

  permit ip any host 10.1.1.1 log

  permit ip host 10.1.1.1 any log

debug access-list CAPTURE

---------------------------------------------------

Another way to debug traffic with ACLs is with the debug ip packet <access-list name> detail command.

NOTE: It is NOT recommended to run this command without referencing an access-list.  Therefore, create an ACL that matches the traffic you want to capture.  In this example the ACL, named CAPTURE, will select traffic both to and from the host 10.1.1.1 to be captured when the debug ip packet CAPTURE detail command is issued. (when enough traffic has been captured type undebug all to stop the capture)

---------------------------------------------------

To capture the traffic to and from a particular peer:

ip access-list extended CAPTURE

  permit ip any host 10.1.1.1

  permit ip host 10.1.1.1 any

debug ip packet CAPTURE detail

---------------------------------------------------

To see if traffic is being matched going through the firewall you can issue the command debug ip firewall.  This command will show all the traffic traversing the firewall.  It will display what interface the packet arrived on, what interface it left, and what action the firewall performed on the packet.  Be cautious of using this command, because it will show all traffic traversing the firewall, not only a specific ACL, as the other commands shown above.

Finally, you can see a snapshot of the traffic traversing the firewall with the command show ip policy-sessions.  This command displays a list of current Internet Protocol version 4 (IPv4) access control policy (ACP) associations.  The output is segmented into policy-classes, and displayed in numerical order by source IP address.

I hope this information makes sense, but please do not hesitate to reply to this post with any additional information or questions.  I will be happy to help in any way I can.

Levi

Message was edited by: levi (The Packet Capture feature was released in firmware version R10.1.0:  https://supportforums.adtran.com/docs/DOC-5042)

[Anonymous]

Levi,

From your respnse I see where I went wrong.  I did not mark the ACL to be logged with the word "log" at the end of each statement.  This prevented me from seeing the ACL matches in my debug.

Also, thank you for the additional information on the "detail" command!

The show ip policy-sessions command is what I eventually used to find out if the NTP traffic was being processed by the router.

Thanks again!

Dan