Menu Close

ASA TCP State Bypass

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.

Adding a Secondary ISE Node

Depending on ISE deployment if small, medium or large, you might need to add additional nodes with different Personas. The Persona in ISE cube is just a fancy name to define what services would be running on a node. The main three Personas are Administration (PAN), Policy Service (PSN) and Monitoring and Troubleshooting (MnT). The primary/secondary concept exists only with PAN and MnT Personas, however, this is not applicable with PSN Persona. The maximum number of PANs and MnTs in any ISE cube you can get is two, however, you can have plenty of PSNs.

ASA DNS Server

As we know the Cisco ASA supports DHCP server feature but not the DNS server. The reason behind this would be to have less services running on the appliance that would expose any potential vulnerabilities that would be exploited which would turn in successful threats, especially when the running services are interacting directly with the internet. A scenario where having a DNS server running on the ASA would be handy would be when the DHCP server is running on the same appliance, and where the DNS server in use would be a public DNS, but to be honest the fact that the ASA does not support the DNS server is not an issue at all, because you can still push an external DNS server IP address through the DHCP lease managed by the ASA.

CLI Administrator in Cisco ISE

In this post I’m going to show you how to configure Windows AD as the external authentication server for Identity Services Engine (ISE) CLI access. When you deploy ISE for the first time, you use the command “setup” at the login prompt to start the bootstrap process which will take you through a list of required steps to complete the appliance initial configuration. Once that is completed, the appliance will be ready for the next level of configuration which will be done through the GUI. One of the required steps during the bootstrap process is to configure the CLI admin account. You can choose to create a new admin account or you can accept the default account which is “admin”. This default account cannot be deleted, it can be disabled or downgraded to a read-only account though.

ASA Gets Stuck on Boot in EVE-NG

In this post I’m going to share with you how to fix the issue that you might have came through with ASAv images in EVE-NG that would prevent the ASAv from booting up.

Basically you would see the ASA getting stuck during the boot process at the very beginning and it won’t move on. Here is what you would see on the terminal screen when the ASAv is stuck:

NAT Trick on Cisco IOS Devices

In this post I’m going to talk about NAT exemption. As we know NAT plays a very important role in our networks today, however, with all the benefits we get from NAT’ing, sometimes we don’t need it, or more specifically we need to bypass it. A common case scenario would be for VPN traffic where we don’t want to translate the original IP addresses. In this post I’m going to show you how to exempt NAT by applying a tricky configuration on IOS without having to go through the common way of doing it.

VLAN1 and Vlan Hopping Attack

You might have read many times during your studies that changing the native VLAN1 on Cisco switch trunk ports is highly recommended. Some documentations do not give any explanation about this recommendation, others might give a hint associating the recommendation to security, and still others might give a brief explanation referring to preventing VLAN Hopping Attack.

Scroll To Top