As we know Cisco ISE does not support increasing the disk space, so if we run out of disk space, then the only option we would have in theory is to re-image the ISE node allocating more disk space. I said in theory because in reality you would be able to increase ISE disk space at the Linux level.
In this post I will share with you one caveat and its fix with redirect ACL with C9300 switches. In the last few months I was working on a project for a medium size customer. The main requirements were to implement Firepower IPS, dot1x, pxGrid, AnyConnect client provisioning and posture assessment for both VPN and local clients. The customer has a few sites spread across the globe, and all of them are connected through VPLS. There are different network devices that we were working on and in one of the sites we had a stack of Cisco C9300 switches. The customer has ISE deployed for identity management.
Recently I came across a command to reset Cisco C9000 switches to factory default. The command is factory-reset and it was introduced in IOS XE 16.8.1a. This command can be handy and harmful. It can be harmful if you use it without paying attention to what option you use with it.
In this post, I am going to show you how to set up FMC external authentication with RADIUS. Why we would need that?!, simply put, to have a scalable solution in our environment that will allow us to manage accesses to our FMC appliance. Even if we configure the FMC with an external authentication server, we do still have the local admin account enabled that we can use in case the external authentication server is down.
In this post, I am going to show you how to run a packet capture on Cisco Firepower Management Center (FMC). As we know, both FTD and FMC are Linux based which means we can rely on a few tools that are embedded in Linux operating system. In fact, when you log into the FMC or when you go into Expert mode on FTD, you will see that the majority of the commands you use are simply Linux commands.
In this post I am going to show you how to configure crypto keypair without configuring host name or domain name on Cisco devices. A few network admins still have some confusion about if configuring the domain name on Cisco devices is a requirement to generate a crypto keypair or not. I believe this confusion comes from the error we get when we try to create a crypto keypair on Cisco devices before we’ve configured the domain name. The error would explicitly ask us to define the domain name first to generate the crypto keypair.
What are Snort HOME_NET and EXTERNAL_NET Variables?! Snort rules rely on variables to know what traffic they should inspect and what to ignore. Each Snort rule has a header where a bunch of variables are defined such as the action to be taken, protocol, source IP, source port, destination IP and destination port. The most important two bits among these variables are the source and destination IP addresses. These two variables define what should be protected and what should not. In Snort language these two variables are called HOME_NET and EXTERNAL_NET. HOME_NET should include all the IP addresses that Firepower should protect which means all our IP addresses whether private or public, but what about the EXTERNAL_NET?! should it be anything else except our protected IP addresses defined in our HOME_NET?! or should it be anything including our HOME_NET?! let’s find out together :).
As we know, there is no preemption in IPsec site-to-site VPN on Cisco ASA to the primary peer. If you configure a crypto map with two peers, one as the primary, and another as the secondary, the ASA will try always to initiate the tunnel with the primary peer. If the primary peer fails and become unreachable, then the ASA will initiate the tunnel with the secondary peer. When the primary comes back online, the ASA will not do anything as long as the secondary is reachable. In other words, the primary peer will not take over the control from the secondary; instead the tunnel will remain initiated with the secondary peer. In a different scenario, that would be an issue, because maybe the secondary peer is located at the edge of a disaster recovery site where you don’t have a complete mirror of your primary site, or maybe the device has less resources, or maybe the link where it is connected is slow.
We know Cisco ISE amazingly supports network devices administration through TACACS+ protocol which allows granting different access levels and managing what command sets could be run in each level. However, this feature requires an additional license called Device Administration to be installed on ISE. TACACS+ has a few advantages over RADIUS when it comes to devices administration. However, in some small/medium environments having different admins access levels might not be required, and the only requirement would be just to give privilege level 15 to all admins that are in a specific AD group. Now the question is, can we accomplish this with ISE without having the device administration through TACACS+ feature enabled?! let’s find out this together! 🙂
One of the security features Cisco ASA provides for new connections is to ensure the 3-Way Handshake is completed between two hosts before allowing any further tcp traffic between the two hosts. The 3-Way Handshake is simply exchanging the SYN, SYN-ACK and ACK between two hosts, each sends the relevant packets based if it acts as a sender or a receiver. If the ASA should see a SYN-ACK packet sent by a host to another before seeing the initial SYN packet, the traffic will be dropped. Similar if the ASA should see an ACK packet before seeing the previous two packets SYN and SYN-ACK exchanged between the two hosts. The ASA does this by inspecting each packet and creating a state for each connection. This a nice feature, however, in some legitimate scenarios it might create some issues and preventing the traffic from being delivered between the two hosts. Let’s see what would be an example scenario for this, and how to apply the fix.