So many customers and students ask me about how to see the NAT events in their FMC and my answer is no way, nada, nope – not going to happen.
By looking at the detailed packet flow of Cisco FTD devices posted in an earlier post, we can understand why we can’t see the Lina events in the Firepower Management Center (FMC) since the FMC only records Snort events, and not what happened before the Snort engine analysis. Here is the FTD packet flow blog: Cisco FTD Packet Flow
There are two ways to get Lina events: from the CLI of the FTD box with the show logging command, but if you don’t want to watch your CLI 24×7, you can setup a syslog server connection to your FTD. To configure your FTD device(s) to log Lina events, go to Devices>Platform Settings>Syslog on your FMC.
From here there are quite a few settings for Syslog and you’ll have to figure them out based on your own network, but I do want to bring something to your attention, and that is the Syslog Settings tab.
These Syslog ID’s can be hard to figure out and they are all disabled by default, which is probably not what you want.
So, what are these numbers? That’s a good questions and here is the answer:
Its recommended to look at the Messages listed by Severity Level, which is highly informative. Here is a small example, and there are hundreds of pages of output you can search through:
- %ASA-1-105002: (Primary) Enabling failover.
- %ASA-1-105003: (Primary) Monitoring on interface interface_name waiting
- When a user configures FTD logging from Platform Settings, the FTD generates Syslog messages (same as on classic ASA) and can use any Data Interface as a source (including the Diagnostic). Here is an example of the FTD sending a Syslog message via the platform settings direct to the Syslog server:
- However, when Access Control Policy (ACP) Rule-level logging is enabled the FTD originates these logs through the br1 logical interface as a source. The logs are originated from the FTD br1 subinterface:
Step 1. Log in to the FTD console or SSH to the br1 interface and enable capture on FTD CLISH mode using no filter
Please choose domain to capture traffic from:
0 – br1
1 – Router
> support-system capture-traffic
> show capture
Also, from your FTD console, you can use the typical ASA commands to see information and logs:
Syslog logging: enabled
Timestamp logging: enabled
Hide Username logging: enabled
Standby logging: enabled
Debug-trace logging: disabled
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 6581321 messages logged
Trap logging: level debugging, facility 23, 13149628 messages logged
Logging to Inside 10.11.11.250, UDP TX:8317
Global TCP syslog stats::
NOT_PUTABLE: 0, ALL_CHANNEL_DOWN: 0
CHANNEL_FLAP_CNT: 0, SYSLOG_PKT_LOSS: 0
Permit-hostdown logging: disabled
History logging: disabled
Device ID: hostname “ftd19”
Mail logging: disabled
ASDM logging: disabled
FMC logging: list MANAGER_VPN_EVENT_LIST, 0 messages logged
May 17 2018 21:16:43 ftd19 : %ASA-7-710006: EIGRP request discarded from 10.11.12.160 to Outside:220.127.116.11
May 17 2018 21:16:43 ftd19 : %ASA-7-710006: EIGRP request discarded from 10.11.12.60 to Outside:18.104.22.168
May 17 2018 21:16:43 ftd19 : %ASA-7-710006: EIGRP request discarded from 10.11.12.50 to Outside:22.214.171.124
Here is the final output of the Syslog entries from the FTD device showing the new Lina information in detail. You can see what I typed into the FTD CLI.
May 10 16:27:35 172.23.0.8 %ASA-5-111010: User ‘enable_15’, running ‘CLI’ from IP 0.0.0.0, executed ‘ping tcp lina_mgmt 10.31.44.36 4514’
May 10 16:27:35 172.23.0.8 %ASA-5-111008: User ‘enable_15’ executed the ‘ping tcp lina_mgmt 10.31.44.36 4514’ command.
Using that awesome link and messages listed by Severity Level search bar, I can see that ASA-5-111010 is Severity 5 and:
- %ASA-5-111010: User username, running application-name from IP ip addr, executed cmd
ASA-5-111008 is Severity 5:
- %ASA-5-111008: User user executed the command string
ASA-7-710006 is Severity 7 and:
- %ASA-7-710006: protocol request discarded from source_address to interface_name:dest_address
Although those outputs were pretty damn obvious and I didn’t really need to look them up to see what they do, I think you can see how helpful this can be.