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.
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.
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. However, let’s say hypothetically your requirement is to use the ASA as you DNS server for the hosts located on your internal segment, would that be possible? the answer is yes & no :). Although the ASA will never be acting as a real DNS server, you can still apply a little trick with NAT that would make the ASA to result as your hosts DNS server. From the hosts perspective they would think that the DNS server is the ASA, however, in reality the ASA would be just acting as a transporter of DNS requests between the internal hosts and the external public DNS server. Here is the trick of how you can accomplish this.
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: