Modern Failover Testing on Cisco ASA Post-9.7: A Comprehensive Guide

In modern network environments, ensuring high availability is critical for uninterrupted business operations. Cisco's Adaptive Security Appliance (ASA) offers failover capabilities that help maintain connectivity in the event of hardware or network failures. With the release of **ASA 9.7 and beyond**, there have been significant improvements and best practices to configure and test failover, especially regarding seamless transition and enhanced failover state management.

This blog will guide you through **failover testing on ASA Post-9.7** by explaining the modern approach, configurations, and validation steps.

---

### What's Changed in ASA Post-9.7?

ASA firmware 9.7 introduced several enhancements to the failover process, including:

- **Stateful Failover Improvements:** Failover is more seamless, preserving more session data, including certain stateful connections like VPN, to minimize disruptions.

- **Failover Performance Monitoring (FPM):** Introduced to monitor active failover performance, it gives administrators deeper insights into failover readiness.

- **Enhanced Inspection Engines:** Beyond simple ICMP inspections, stateful inspections for a variety of protocols are now more efficient, improving traffic continuity during failover.

These features improve reliability and performance during failover scenarios, but it's crucial to properly test the setup.

---

### Prerequisites for Modern Failover Testing

Before conducting a failover test, ensure that you meet the following prerequisites:

1. **Correct Failover Configuration:** Primary and Secondary ASAs must be properly configured with both LAN failover and Stateful failover interfaces.

   

2. **ICMP Inspection Enabled:** Enable ICMP inspection (though Post-9.7 ASA has enhanced protocol inspections, ICMP remains a lightweight, effective way to test connectivity during failover).

3. **Monitoring & Alerts:** Enable failover monitoring with SNMP traps or syslog to track failover events in real-time.

---

### Failover Test: Step-by-Step Guide

Here is how you can test ASA failover post-9.7, ensuring a more advanced and detailed validation of your high-availability setup:

#### 1. **Configure Stateful Failover**

   Ensure stateful failover is enabled on both the primary and secondary ASAs.

   

   failover

   failover lan unit primary

   failover lan interface LANFAIL GigabitEthernet0/3

   failover link STATEFULFAIL GigabitEthernet0/4

   failover interface ip LANFAIL 192.168.1.1 255.255.255.0 standby 192.168.1.2

   failover interface ip STATEFULFAIL 192.168.2.1 255.255.255.0 standby 192.168.2.2

   failover key ***** 

   

   This ensures that the state information for connections is transferred from the active to the standby ASA.

#### 2. **Enable ICMP Inspection**

   Enabling ICMP inspection helps you test connectivity between two routers (R1 and R2) across the ASAs. However, if your test involves other protocols (HTTP, TCP, etc.), make sure their respective inspections are enabled.

   

   policy-map global_policy

   class inspection_default

   inspect icmp

   

#### 3. **Start Continuous Ping**

   Initiate a continuous ping from R1 (inside the network) to R2 (outside the network). This will give you a simple but reliable way to monitor failover functionality.

   On **R1**:

   

   ping 192.168.2.10 -t

   

   This will keep pinging R2 to track any loss of connectivity.

#### 4. **Trigger Failover**

   Force a manual failover to switch from the active ASA to the standby ASA. 

   On the **Primary ASA** (Active):

   

   no failover active

   

   Alternatively, if you want to simulate hardware failure or network disconnection, you can disconnect the interface cables from the active ASA.

#### 5. **Verify Failover & Connectivity**

   **a. Checking Failover Status**

   On the newly Active ASA (previously Standby), run the following commands to verify that the failover has occurred and the system is operating normally:

   

   

   show failover

   

   Example output:

   

   Failover On

   Active time: 5 minutes

   This host: Primary - Standby Ready

   Other host: Secondary - Active

   

   You can also use:

   

   

   show failover state

   show failover history

   

   

   These commands give insights into how the failover occurred, the current status of both units, and any state replication issues.

   **b. Verifying Connection State:**

   Post-9.7, ASA improves stateful failover, so you should experience **minimal to no packet loss** during the failover event. While the failover occurs, monitor the pings running from R1 to R2. There may be a single packet loss, but connectivity should immediately resume.

   **c. Reviewing Logs:**

   

   Check syslogs or SNMP traps for failover events:

   

   

   show log | include failover

   

   This will provide you with detailed information about the failover event.

---

### Failover Testing Best Practices Post-9.7

1. **Minimal Downtime Expectations:** With enhanced stateful failover and FPM monitoring, expect very minimal downtime. A single dropped ping is typically the worst-case scenario.

   

2. **Use Various Protocols:** ICMP is a great initial test, but for a comprehensive failover validation, ensure that you test multiple protocols (e.g., TCP, HTTP, FTP). ASA now better handles these transitions.

3. **Monitor Failover Events:** Utilize SNMP or syslog alerts to monitor real-time failover events and ensure proper transitions. Post-9.7 introduces better tracking and alerting mechanisms.

4. **Scheduled Failover Tests:** It's important to schedule routine failover tests to ensure high availability and the health of both active and standby units.

---

### Conclusion

Failover testing on ASA Post-9.7 is a more robust and efficient process, thanks to improvements in stateful failover and monitoring. With minimal packet loss during failover, organizations can ensure business continuity even during critical infrastructure transitions. Following the steps and best practices outlined above will help you thoroughly validate your failover configuration and ensure that your ASA devices are properly securing and managing your network.

By performing routine tests and utilizing the enhanced features, you can be confident that your failover setup will operate as expected when it matters most.

Securing ICMP Traffic and Preventing Information Disclosure in Cisco ASA Post-9.7

ICMP (Internet Control Message Protocol) is a critical part of the internet’s communication infrastructure, as it helps in diagnosing issues, detecting errors, and managing the flow of traffic. Common tools like `ping` and `traceroute` rely on ICMP messages to provide feedback on network connectivity and performance. However, ICMP can also inadvertently expose sensitive network information, especially in environments using NAT (Network Address Translation) on devices like Cisco ASA firewalls.

In the past, ICMP inspection was used not only to allow ICMP traffic through the firewall without requiring ACLs but also to modify ICMP packet contents to prevent sensitive information leakage. This is particularly useful in mitigating the risks associated with `traceroute` tools, which can reveal internal network IP addresses.

In ASA versions post-9.7, the process of protecting network information from ICMP-related exposure has been refined. This blog explores how ICMP inspection works in modern ASA firewalls and how to prevent traceroute tools from exposing internal IP addresses using ICMP error inspection.

---

### Understanding the Problem: ICMP and Information Disclosure

ICMP messages such as **time-exceeded** and **port unreachable** play a vital role in the `traceroute` tool, which is often used to map the path packets take across the network. Here’s a breakdown of how traceroute typically works and why it can become an issue in networks using NAT:

- **Traceroute Mechanism**:

  - Traceroute sends UDP packets with incrementally increasing TTL (Time-To-Live) values. Each hop along the path decreases the TTL by 1, and when TTL reaches zero, the device that discarded the packet sends back an **ICMP time-exceeded** message.

  - When the final destination is reached, an **ICMP port unreachable** message is sent back.

- **The Problem with NAT**:

  - When NAT is configured, internal IP addresses are mapped to a public IP address. Without proper inspection, the ICMP messages generated in response to traceroute requests (like time-exceeded or port unreachable) can expose the internal (real) IP addresses of hosts behind the firewall.

  - This information can be valuable to attackers who may use it to map out internal network structures and identify potential targets for attack.

### The Old Approach: ICMP Error Inspection

In older ASA versions, ICMP inspection was enabled to ensure that ICMP traffic passed through the firewall smoothly. It was also used to modify sensitive details within ICMP messages. When NAT was in place, ICMP inspection could rewrite the source IP addresses of ICMP error messages (like time-exceeded) to prevent internal IP addresses from being exposed to external networks.

Enabling **ICMP error inspection** ensured that the ASA firewall translated ICMP error messages in line with NAT rules. This prevented internal IP addresses from being included in the error responses, reducing the risk of information leakage during a traceroute.

However, this method required significant manual configuration and often left room for human error or configuration mismatches.

---

### The Modern Approach: ASA Post-9.7

With the introduction of ASA 9.7 and later, Cisco has made managing ICMP traffic more secure and easier to configure, particularly when it comes to NAT environments. ICMP error inspection has become more efficient, and the firewall is now better equipped to handle both outbound and inbound ICMP traffic without exposing sensitive network details.

#### 1. **ICMP Inspection for Traffic Handling**

   In ASA post-9.7, ICMP inspection is still used to allow ICMP packets to flow without the need for ACLs on returning traffic. When ICMP inspection is enabled, the ASA dynamically tracks ICMP request and response messages, allowing return traffic (such as replies to `ping` requests) to pass through the firewall automatically.

   The configuration for enabling ICMP inspection remains straightforward:

   policy-map global_policy

      class inspection_default

         inspect icmp

   This ensures that ICMP traffic from inside the network to outside (and vice versa) is correctly inspected and allowed without exposing internal IP addresses during normal traffic flow.

#### 2. **Enhanced ICMP Error Inspection to Prevent Traceroute Exposure**

   The key enhancement in ASA post-9.7 comes in how ICMP error inspection works with NAT. When ICMP error inspection is enabled, the ASA rewrites the source IP addresses in ICMP error messages (such as time-exceeded or port unreachable) according to the NAT translation rules. This ensures that when internal hosts generate these ICMP errors, their private IP addresses are not revealed to external users.

   To enable ICMP error inspection in modern ASA, the configuration involves both enabling ICMP inspection and ensuring the NAT rules are correctly defined. Here’s how you can configure ICMP error inspection:

   1. **Ensure NAT Rules Are Correctly Configured**:

      NAT rules should map the internal network to the appropriate public IP address pool for external traffic. When these rules are in place, ICMP error inspection automatically applies the necessary translations to error messages.

      Example NAT rule:

      object network INTERNAL-HOST

         host 192.168.1.10

         nat (inside,outside) static 203.0.113.10

      This NAT rule translates the internal host’s private IP (`192.168.1.10`) to a public IP (`203.0.113.10`) for traffic passing between the inside and outside interfaces.

   2. **Enable ICMP Error Inspection**:

      Once the NAT rules are defined, ICMP error inspection can be enabled to modify error messages according to the NAT rules. This prevents internal IP addresses from being exposed in responses to traceroute requests or other ICMP-related traffic.

      Example configuration:

      policy-map global_policy

         class inspection_default

            inspect icmp error

      The **inspect icmp error** command tells the ASA to inspect ICMP error messages and apply the necessary translations. This ensures that ICMP error messages such as **time-exceeded** or **port unreachable** are rewritten with the correct public IP address instead of exposing the internal network’s private IP addresses.

#### 3. **How ICMP Error Inspection Prevents Information Disclosure**

Let’s say someone on the outside is performing a `traceroute` to an internal host behind the ASA. Without ICMP error inspection, the time-exceeded or port unreachable messages generated by the internal devices could include their private IP addresses. With ICMP error inspection enabled, the ASA modifies the IP address in the ICMP response, replacing the internal IP with the translated public IP.

This means that even if traceroute reaches an internal device, the response will always reflect the public IP address defined in the NAT rules, effectively hiding the internal network structure.

### Additional Best Practices

While ICMP error inspection is a powerful tool for preventing information leakage, it’s important to complement it with other best practices:

1. **Disable Unnecessary ICMP Traffic**: ICMP traffic can be limited based on the organization’s security needs. For example, you can block ICMP types that are not required, such as certain ICMP redirects, to further reduce the attack surface.

2. **Monitor ICMP Traffic**: Regularly monitor ICMP traffic using the ASA’s logging and monitoring features. This can help you detect unusual patterns or attempts to map out your network using tools like traceroute.

3. **Harden NAT Configuration**: Ensure that NAT rules are properly defined and regularly reviewed. Incorrect or overly permissive NAT configurations can expose internal IP addresses or cause traffic misconfigurations that might compromise security.

---

### Conclusion

In ASA versions post-9.7, managing ICMP traffic has become more streamlined, especially in NAT environments where information disclosure can be a concern. By enabling **ICMP error inspection**, the ASA can rewrite ICMP error messages such as **time-exceeded** and **port unreachable**, ensuring that internal IP addresses remain hidden from external users. This helps prevent network mapping through traceroute tools while allowing essential ICMP functionality.

As networks continue to grow and evolve, maintaining strong ICMP security practices is critical. Leveraging the improvements in ICMP error inspection in ASA post-9.7 ensures your network remains both functional and secure against potential threats.