Often when deploying Firepower/Secure Firewall devices I get asked to show that everything is working as expected or to prove that things like the Snort IPS engine are working as advertised.

I can’t, in good conscience, attempt to download some malware or ransomware on their network but how about a simple ping?

Thankfully there’s a built in Snort rule (sid) that can be enabled to trigger a security alert on ICMP Echo Replies, so all we need to do to highlight Snort efficacy and alerting is to enable that particular sid and send some Echo Requests and wait for the Reply.

After recently deploying a new Firepower 3105 HA pair for a client, they decided to move the firewalls to a different rack. Upon powering up the devices, the secondary firewall wasn’t coming online and syncing with the primary.

We plugged a console cable into the device and were greeted with a ROMMON prompt:

rommon 1>

This lines up pretty well with the following BugID:

https://quickview.cloudapps.cisco.com/quickview/bug/CSCvp57772

While the workaround mentions doing a complete reimage of the device, there is a much simpler fix.

While Cisco’s Secure Firewall Management Center is a great tool there’s still some missing functionality here and there. Upgrades, for one, is a great example. How do you know when an upgrade has failed? Why did it fail? Where did it fail?

Sure the Task pane shows us the progress but truthfully that’s about it.

So for today, a quick update on how I monitor the progress of a Firepower Threat Defense upgrade through the command line.

Occasionally you may come across issues with SIP inspection on an ASA or Firepower, leading to problems with SIP/RTP voip audio. As a troubleshooting step, it’s often helpful to disable SIP inspection for testing.

Please read this note from Cisco on disabling SIP inspection to verify you everything in order before doing so:

You would typically disable SIP only if the inspection is causing problems in the network. However, if you disable SIP, you must ensure that your access control policies allow the SIP traffic (UDP/TCP 5060) and any dynamically allocated ports, and that you do not need NAT support for SIP connections. Adjust the access control and NAT policies accordingly through the standard pages, not through FlexConfig.

Ran into an interesting issue the other day setting up a two node ISE deployment. I figured I’d put it up on the blog in case anyone else is pulling out their hair.

After adding a secondary node, the deployment nodes status page lists an error saying “synchronization failed.”

When I consoled into the ISE node I saw multiple failed logins:

Failed to log in 51 time(s)
Last failed login on Tue Oct 15 11:38:37 2019 from 10.102.10.168
ISE3615-1/admin#