Syslog on ASA

Syslog Packet:

The syslog packet size is limited to 1024 bytes and carries the following information:







Syslog Port numbers:

When sending messages using UDP the destination port is usually 514

When sending messages using TCP the destination port is usually 1468

Syslog Message Format:


This is the text of the syslog message, along with some additional information about the process that generated the message. The syslog messages generated by Cisco IOS devices begin with a percent sign (%) and use the following format:



Following is a description of each field:


FACILITY— Refers to the source of the message, such as a hardware device, a protocol, or a module of the system software. Note that this FACILITY is Cisco specific and is only relevant within the message string. It is different from the facility defined in RFC 3164 for the syslog protocol.

SEVERITY— This is similar to the severity defined in Table 4-2.

MNEMONIC— This is a device-specific code that uniquely identifies the message.

Message-text— This is a text string that describes the message and can contain details such as port numbers and network addresses.

Following is a sample syslog message generated by a Cisco IOS device:


*Mar  6 22:48:34.452 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,

changed state to up

Note that the message begins with a special character (*) and that the timestamp includes the time-zone information. The message was generated by the LINEPROTO facility at severity 5 (Notice). The MNEMONIC UPDOWN along with the message-text describe the event.


The facility allow administrators to logically separate messages (e.g. write them to separate files, forward them to different destinations, etc.)

Each Syslog message includes a priority value at the beginning of the text. The priority value ranges from 0 to 191 and is made up of a Facility value and a Level value.


Syslog messages are broadly categorized on the basis of the sources that generate them. These sources can be the operating system, the process, or an application. These categories, called facility, are represented by integers, as shown in Table 4-1. The local use facilities are not reserved and are available for general use. Hence, the processes and applications that do not have pre-assigned facility values can choose any of the eight local use facilities. As such, Cisco devices use one of the local use facilities for sending syslog messages.

The Facility value is a way of determining which process of the machine created the message. Since the Syslog protocol was originally written on BSD Unix, the Facilities reflect the names of Unix processes and Daemons.

The priority value is calculated using the following formula:

Priority = Facility * 8 + Level


Table 4-1. Facility Values

Facility 0

Kernel messages 1

User-level messages 2

Mail system 3

System daemons 4

Security/authorization messages 5

Messages generated internally by Syslogd 6

Line printer subsystem 7

Network news subsystem 8

UUCP subsystem 9

Clock daemon 10

Security/authorization messages 11

FTP daemon 12

NTP subsystem 13

Log audit 14

Log alert 15

Clock daemon 16

Local use 0 (local0) 17

Local use 1 (local1) 18

Local use 2 (local2) 19

Local use 3 (local3) 20

Local use 4 (local4) 21

Local use 5 (local5) 22

Local use 6 (local6) 23

Local use 7 (local7) 24

Severity Level:

The source or facility that generates the syslog message also specifies the severity of the message using a single-digit integer, as shown in Table 4-2.

The higher severity numbers “include” the lower severity numbers.

Table 4-2: The list of severity Levels:

0       Emergency: system is unusable

1       Alert: action must be taken immediately

2       Critical: critical conditions

3       Error: error conditions

4       Warning: warning conditions

5       Notice: normal but significant condition

6       Informational: informational messages

7       Debug: debug-level messages

Recommended practice is to use the Notice or Informational level for normal messages.


A detailed explanation of the severity Levels:

DEBUG: Info useful to developers for debugging the app, not useful during operations

INFORMATIONAL: Normal operational messages – may be harvested for reporting, measuring throughput, etc – no action required

NOTICE: Events that are unusual but not error conditions – might be summarized in an email to developers or admins to spot potential problems – no immediate action required

WARNING: Warning messages – not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full – each item must be resolved within a given time

ERROR: Non-urgent failures – these should be relayed to developers or admins; each item must be resolved within a given time

ALERT: Should be corrected immediately – notify staff who can fix the problem – example is loss of backup ISP connection

CRITICAL: Should be corrected immediately, but indicates failure in a primary system – fix CRITICAL problems before ALERT – example is loss of primary ISP connection

EMERGENCY: A “panic” condition – notify all tech staff on call? (earthquake? tornado?) – affects multiple apps/servers/sites…

Syslog IDs:

Event(All event classes) Lists:

Event List can be used to filter syslogs IDs (syslog ID or a range) sent to a logging destination.

Logging Filters:

Logging filters are used for logging destinations e.g. Syslog Servers, Email, ASDM, Internal buffers, Console, SSH, SNMP trap and attach the Event List to is as well.

Message/Event Class:

Use the message class in order to send all messages associated with a class to the specified output location e.g. auth, config, ha, snmp, vpn, ssl etc.

Syslog servers:

Simply define the destination IPs to send the logs (usual port number udp/514).


Cisco Labs

CCP Configuration:

ASA ASDM basic config:

Cisco 861/871 basic router configuration:

Cisco IOS DHCP Configuration:

IOS Zone based Firewall configuration:

IOS Site-to-Site IPSec VPN Configuration:

ASA Site-to-Site IPSec VPN:

Cisco VPN Client Configuration – Setup for IOS Router:


Cisco Tools and Applications:

How Does NAT-T (NAT Traversal) work with IPSec?

ESP encrypts all critical information, encapsulating the entire inner TCP/UDP datagram within an ESP header. ESP is an IP protocol in the same sense that TCP and UDP are IP protocols (OSI Network Layer 3), but it does not have any port information like TCP/UDP (OSI Transport Layer 4). This is a difference from ISAKMP which uses UDP port 500 as its transport layer.

Why can’t an ESP packet pass through a PAT device?
It is precisely because ESP is a protocol without ports that prevents it from passing through PAT devices. Because there is no port to change in the ESP packet, the binding database can’t assign a unique port to the packet at the time it changes its RFC 1918 address to the publically routable address. If the packet can’t be assigned a unique port then the database binding won’t complete and there is no way to tell which inside host sourced this packet. As a result there is no way for the return traffic to be untranslated successfully.

How does NAT-T work with ISAKMP/IPsec?
NAT Traversal performs two tasks:
Detects if both ends support NAT-T
Detects NAT devices along the transmission path (NAT-Discovery)

Step one occurs in ISAKMP Main Mode messages one and two. If both devices support NAT-T, then NAT-Discovery is performed in ISKAMP Main Mode messages (packets) three and four. THe NAT-D payload sent is a hash of the original IP address and port. Devices exchange two NAT-D packets, one with source IP and port, and another with destination IP and port. The receiving device recalculates the hash and compares it with the hash it received; if they don’t match a NAT device exists.

If a NAT device has been determined to exist, NAT-T will change the ISAKMP transport with ISAKMP Main Mode messages five and six, at which point all ISAKMP packets change from UDP port 500 to UDP port 4500. NAT-T encapsulates the Quick Mode (IPsec Phase 2) exchange inside UDP 4500 as well. After Quick Mode completes data that gets encrypted on the IPsec Security Association is encapsulated inside UDP port 4500 as well, thus providing a port to be used in the PAT device for translation.

To visualize how this works and how the IP packet is encapsulated:
Clear text packet will be encrypted/encapsulated inside an ESP packet
ESP packet will be encapsulated inside a UDP/4500 packet.

NAT-T encapsulates ESP packets inside UDP and assigns both the Source and Destination ports as 4500. After this encapsulation there is enough information for the PAT database binding to build successfully. Now ESP packets can be translated through a PAT device.

When a packet with source and destination port of 4500 is sent through a PAT device (from inside to outside), the PAT device will change the source port from 4500 to a random high port, while keeping the destination port of 4500. When a different NAT-T session passes through the PAT device, it will change the source port from 4500 to a different random high port, and so on. This way each local host has a unique database entry in the PAT devices mapping its RFC1918 ip address/port4500 to the public ip address/high-port.

What is the difference between NAT-T and IPSec-over-UDP ?
Although both these protocols work similiar, there are two main differences.

When NAT-T is enabled, it encapsulates the ESP packet with UDP only when it encounters a NAT device. Otherwise, no UDP encapsulation is done. But, IPSec Over UDP, always encapsulates the packet with UDP.

NAT-T always use the standard port, UDP-4500. It is not configurable. IPSec over UDP normally uses UDP-10000 but this could be any other port based on the configuration on the VPN server.