Cisco ASA Breaks Path Visualization
PreviousVirtual Machine with NAT Breaks Path VisualizationNextPath Visualization: Edge Firewall Incorrectly Shows a Single Hop to the Destination
Last updated
Last updated
When a TCP-based Path Visualization view displays forwarding loss at a node representing a Cisco ASA firewall, and white nodes or no nodes beyond the Cisco ASA firewall, a possible cause is the ASA's feature set which attempts to prevent TCP SYN floods and similar denial-of-service (DoS) attacks. The forwarding loss and missing nodes in Path Visualization can be corrected through the use of the ASA's TCP State Bypass feature.
The TCP synchronization (SYN) packets sent in the Path Visualization portion of a test use the same source and destination IP addresses and source and destination TCP port numbers (a "four-tuple"), but each has an initial sequence numbers (ISN) which is incremented by one with each increment of the Time to Live (TTL) field in the IP header (the standard traceroute mechanism). The Wireshark packet capture image below shows an Agent sending Path Visualization packets from source IP address 10.100.10.208 and source port 49221 to the target destination IP address 108.174.10.10 and destination TCP port 80:
As shown in the Info column, the first SYN packet (with Time to Live: 1 in the IP header) has an initial sequence number of 1642740607. Each subsequent SYN packet increments the IP TTL and ISN by one. For example, the next SYN packet has an IP TTL of 2 and an ISN of 1642740608.
(As a reference, the packet capture also displays the response to each SYN packet, which is an ICMP code 11 "time-to-live exceeded in transit" from which we obtain the IP address of the node in the path corresponding to the TTL of the SYN packet.)
When a Cisco ASA receives the first TCP SYN packet, an entry is made in the ASA's embryonic connections table (embryonic TCP connections are connections which are still performing the TCP handshake, i.e. have not reached the "established" state). The entry is based on the four-tuple, but also records the ISN as part of the connection data. When a subsequent SYN packet is received with the same four-tuple but a different ISN, the Cisco ASA considers this a violation of normal TCP behavior, and drops the packet as a possible denial-of-service attack.
Logs from the ASA would be similar to the following:
and
Steadily incrementing counters for dropped packets in the accelerated security path (ASP) can provide additional evidence:
Forwarding loss and missing nodes in Path Visualization can be corrected through the use of the ASA's TCP State Bypass feature, which eliminates the checks for stateful TCP data, and instead uses only the four-tuple to compare against basic access control lists (ACLs) with data such as source and destination IP address and source and destination TCP port.
The TCP State Bypass is configured using one or more ACL's to specify the IP addresses of the Enterprise Agents; a class map to group all such ACLs; and a policy map to specify the TCP state bypass is to be applied to the class of traffic specified in the class map. The policy map is typically applied on a per-interface basis. An example of the configuration is below. Consult the Cisco ASA documentation on configuring the TCP State Bypass for more information.
In the example, we use the following two IP addresses for Enterprise Agents:
10.100.10.208 10.100.20.208
Create the access list called "AgentIPs" with both Agents in the list:
Create the class called "TE-PathViz":
Assign the access list to the class:
Exit to global configuration mode:
Create the policy called "TCP-bypass":
Assign the class to the policy:
Set the policy to bypass TCP state:
Enable ASA to inspect ICMP error messages:
Assign the policy to the interface named "outside":
