e logs can be substantial. While logging to the ASA buffer may seem like a good idea, the logs can scroll by SO fast that the buffer becomes all but unusable. If you log too much detail to the console, you can impact the firewall's performance. If you log to the monitor (your Telnet ses- sion), the logs will update SO frequently that you'll end up turning them off SO you can work. I like to send all my ASA firewall logs to a syslog server. I generally use some flavor of Unix to do this, though, of course, you are free to use whatever you like. Two steps are required to enable logging: you must enable logging with the logging on command, and you must specify one or more logging destinations. When configuring logging destinations, you must also specify the level of logging for each destination. The levels Miscellaneous 0 - System Unusable 1 - Take Immediate Action 2 - Critical Condition 3 - Error Message 4 - Warning Message 5 - Normal but significant condition 6 - Informational 7 - Debug Message The useful logging information regarding traffic traversing the firewall is found in level 6. Here's a sample of level-6 logging: 302015: Built outbound UDP connection 3898824 for outside:11.1.1.1/123 (11.1.1.1/123) to inside: 192.168.1.5/123 10.1.1.5/334) 302013: Built inbound TCP connection 3898825 for outside: 12.2.2.2/2737 (12.2.2.2/2737) to inside:192.168.1.21/80 (10.1.1.21/80) 302013: Built inbound TCP connection 3898826 for outside: 13.3.3.3/49050 (13.3.3.3/49050) to inside: 192.168.1.21/80 (10.1.1.21/80) 304001: 15.5.5.5 Accessed URL 10.1.1.21:/lab/index.html/ On a live network, this information will probably scroll by SO fast that you won't be able to read it. Unfortunately, debug messages are a higher log level, SO if you need to run debugs on the ASA, the output will be buried within these other log entries. Here, I've enabled logging and set the console to receive level-5 logs, while all other logging destinations will receive level-7 logs: logging on logging console notifications These commands apply only to th