Monitoring and Troubleshooting the Transparent Firewall

Cisco ASA provides show commands to ensure that the transparent firewall is working as expected. In the event of a problem, you can enable relevant debugs (which are discussed later in this section).

Monitoring

If transparent firewall mode is configured, first verify that the system is recognizing this mode. You achieve this by using the show firewall command, as shown in Example 10-13.

Example 10-13. Output of show firewall

Brussels# show firewall

Firewall mode: Transparent

Second, confirm that the system is running in the configured single or multiple mode, as shown in Example 10-14.

Example 10-14. Output of show mode

Brussels# show mode

Security context mode: multiple

Once you have verified that the system is switching packets in the correct mode, monitor the status of the L2F table, as demonstrated in Example 10-15. By using show mac-address-table, verify the entries in the bridge table if they look accurate, including static and dynamic entries. There are four dynamic L2F entries learned on the outside interface. There is also a static L2F entry pointing to the outside interface with no aging time.

Example 10-15. Checking the L2F Table

Brussels# show mac-address-table

interface          mac address    type   Age(min)

-----------------------------------------------------------

outside          00d0.c0d2.8030    dynamic  1

outside          0040.8c5c.0e92    dynamic  4

outside          000b.cdf0.8e39    dynamic  4

outside          000e.8315.0bff    dynamic  2

outside          00ff.fff0.003e    static

show arp-inspection displays whether ARP inspection is enabled or disabled on all interfaces. Example 10-16 shows that ARP inspection is enabled on the outside interface with the no_flood option if a miss occurs on the static ARP table. ARP inspection is disabled on the inside interface.

Example 10-16. Checking the Interfaces for ARP Inspection

Brussels # show arp-inspection

interface           arp-inspection           miss

-------------------------------------------------------------

inside              disable                  -

outside             enable                   no_flood

If everything looks good yet traffic is still not flowing, verify the hit counts on the configured interface ACL. Example 10-17 shows 10 hit counts for IPX traffic.

Example 10-17. Monitoring ACLs

Brussels# show access-list

access-list inside ethertype permit ipx (hitcount=10)

access-list inside ethertype permit bpdu (hitcount=0)

access-list inside ethertype deny any (hitcount=0)

For TCP-, UDP-, and, optionally, ICMP-based traffic passing through the security appliance, you can use the show conn command and verify the connection status. As shown in Example 10-18, a connection is established from 192.168.1.10 to a Telnet server located at 192.168.1.1.

Example 10-18. Output of show conn

Brussels/admin# show conn

1 in use, 1 most used

TCP out 192.168.1.1:23 in 192.168.1.10:11018 idle 0:00:02 bytes 90 flags UIO

Troubleshooting

For troubleshooting purposes, Cisco ASA includes a number of important debug and syslog messages to help isolate the issue. This section discusses three troubleshooting scenarios related to the transparent firewalls:

Hosts are not able to communicate� As shown in Figure 10-6, when the web client is not able to communicate with the web server located at 192.168.2.5, the administrator can take the following steps to isolate the issue:

Step 1.	Ping the global IP address of the transparent firewall to ensure that the connectivity exists between the web client and the transparent firewall. If successful, move to Step 2; otherwise, check the cable and VLAN assignments if a switch is placed between the host and the transparent firewall. Additionally, check the L2F table on the appliance by using the show mac-address-table command to ensure that the host is being learned on the correct interface. If the MAC address is not learned, you can enable debug mac-address-table, which is used to view L2F table updates. The appliance uses this table to forward a packet out to an interface. This is shown in Example 10-19, where the security appliance adds a MAC address of 0003.a088.da86 in the table on the inside interface. Example 10-19. Debugging the L2F Table Entries Brussels# debug mac-address-table add_l2fwd_entry: Going to add MAC 0003.a088.da86. add_l2fwd_entry: Added MAC 0003.a088.da86 into bridge table thru inside. add_l2fwd_entry: Sending LU to add MAC 0003.a088.da86. set_l2: Found MAC entry 0003.a088.da86 on inside.
Step 2.	Ping the IP address of the gateway router (192.168.1.1) from the web client. If successful, move to Step 3. If unsuccessful, check the inbound ACL and outbound ACL on the security appliance. If the ACLs look properly configured, enable debug arp-inspection to determine if the ARP requests are being forwarded and inspected through the transparent firewall. Example 10-20 shows the output of debug arp-inspection, where the appliance is forwarding the ARP requests from 192.168.1.5 destined to 192.168.1.1 located on the outside interface. Example 10-20. Output of debug arp-inspection Brussels# debug arp-inspection arp_in_forward: Forwarding arp request from 192.168.1.5 to 192.168.1.1 smac 0003.a088.da86 learn_and_forward_arp_request: Forwarding arp request to outside
Step 3.	Ping the remote gateway (192.168.2.1) from the web client. If it fails, check the inbound ACL and outbound ACL on the router for the ICMP traffic. If it works, make sure that the ACLs allow TCP and UDP connections necessary for browsing the website. Ports such as UDP 53 for DNS resolution and TCP 80 for web browsing should be opened.

Moved host is not able to communicate� If a host is moved from an outside interface to the inside interface, or vice versa, and is not able to communicate after the move, check to ensure that a static L2F entry does not point to the old interface. Additionally, debug l2-indication can be enabled to verify the processing of Layer 2 indications such as miss, learn, host move, and refresh of IP packets. Example 10-21 shows the output of debug l2-indication when a static entry is defined for a MAC address 00e0.b06a.412c toward the outside interface and the host is moved toward the inside interface. The Cisco ASA indicates a host move to the inside interface from the outside interface.

Example 10-21. Output of debug l2-indication

Brussels# debug l2-indication

debug l2-indication enabled at level 1

f1_tf_process_l2_hostmove:HOST MOVE: Host move indication cur_ifc outside, new_ifc

inside mac address: 00e0.b06a.412c

HOST MOVE: cur_vStackNum 0, new_vStackNum 1

HOST MOVE: Host move indication for static entry 00e0.b06a.412c

f1_tf_process_l2_hostmove:HOST MOVE: Host move indication cur_ifc outside, new_ifc

inside mac address: 00e0.b06a.412c

f1_tf_process_l2_hostmove:HOST MOVE: cur_vStackNum 0, new_vStackNum 1

f1_tf_process_l2_hostmove:HOST MOVE: Host move indication for static entry

00e0.b06a.412c

If the security appliance dynamically learns the MAC address of a host on a particular interface and the host is moved to another interface, the dynamic entries associated with an interface can be removed by using clear mac-address-table followed by the name of the interface. As shown in Example 10-22, the administrator wants to clear the L2F entries associated with the outside interface.

Example 10-22. Clearing the L2F Table Associated with the Outside Interface

Brussels# clear mac-address-table outside

Additionally, all dynamic entries in the entire table can be removed by issuing the clear mac-address-table command.

General syslogging� The ASA includes four syslog messages to assist in preventing either MAC spoofing or ARP inspection issues. The ASA logs an L2F message when

- A host is moved from one interface to another. This is known as host move.
- The ASA detects MAC spoofing in the L2F table. MAC spoofing is similar to host move but the original MAC address was statically mapped to an interface.
- The L2F table gets completely full.
- The ARP packets are dropped because they fail the ARP inspection check.