How to Fix Intermittent Connectivity Caused by FTD Proxy ARP

300-710 Last updated Oct 4, 2026

Configure security policies such as access control, DNS, identity, and network analysis policy in Secure Firewall Management Center

Short answer

B Review the NAT policy and disable incorrect proxy ARP configuration to stop the FTD from responding to inside ARP requests.

Question

A network administrator is deploying a new Cisco Secure Firewall Threat Defense (FTD) firewall. After Cisco Secure FTD is deployed, inside clients have intermittent connectivity to each other. When reviewing the packet capture on the Secure FTD firewall, the administrator sees that Secure FTD is responding to all the ARP requests on the inside network. Which action must the network administrator take to resolve the issue?

Review the access policy and verify that ARP is allowed from inside to inside.
Review NAT policy and disable incorrect proxy ARP configuration. Correct Answer
Convert the FTD to transparent mode to allow ARP requests.
Hardcode the MAC address of the FTD to IP mapping on client machines.

Key Takeaways

The question tests identifying Proxy ARP behavior on a Cisco Secure FTD, where the common trap is assuming an access policy or transparent mode is needed to fix ARP issues.

When a Cisco Secure FTD responds to all ARP requests on the inside network, it causes intermittent client connectivity due to Proxy ARP. This page establishes that disabling incorrect Proxy ARP configurations in the NAT policy resolves the issue.

Common mistake: Choosing C (transparent mode) because of a misunderstanding of how FTD handles ARP in routed mode versus the actual cause, which is NAT Proxy ARP.

Expert Analysis

Why the Answer Is Correct

When a Cisco Secure FTD in routed mode responds to ARP requests for IP addresses it does not own, it is performing Proxy ARP. This behavior is typically triggered by NAT rules where Proxy ARP is enabled by default on the destination interface. By reviewing the NAT policy and disabling the incorrect Proxy ARP configuration, the FTD stops intercepting ARP requests meant for other inside hosts, restoring normal connectivity.

Why the Other Options Are Wrong

Access policies (Option A) do not control Proxy ARP behavior, as ARP is a Layer 2 protocol handled before the access control policy evaluation. Converting to transparent mode (Option C) is an extreme measure that changes the deployment architecture and is unnecessary when a simple NAT configuration adjustment can fix the issue. Hardcoding MAC addresses (Option D) is an unsustainable administrative workaround that does not address the root cause of the FTD improperly answering ARP requests.

Community Comment Notes

Commenters correctly identified the NAT policy's Advanced settings as the source of the problem, specifically noting the "Do not proxy ARP on Destination Interface" checkbox. One user incorrectly suggested transparent mode, arguing that "the issue is with inside client to client", but this ignores that the FTD is actively responding to ARP due to NAT, not blocking it. Another user mistakenly thought an access policy could control inside-to-inside ARP traffic.

Official Reference

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/760/management-center-device-config-76/i.html

Exam Strategy

When FTD is responding to ARP requests for IPs it doesn't own, immediately suspect Proxy ARP caused by NAT rules. Look for options that modify NAT policy settings rather than changing deployment modes or access rules.

Community Votes

83%

17%

83% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 6 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.

From public community threads 6

tinyJoe 👍 3 Answered B

The answer is definitely B. I completely agree with Alex_morgan. I'd like to add something. First of all, the “incorrect proxy ARP configuraiton” is specifically the “Do not proxy ARP on Destination Interface” checkbox in the Advanced tab of the FMC's NAT policy. https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/760/management-center-device-config -76/interfaces-settings-nat.html#:~:text=Do%20not%20proxy%20ARP%20on%20Destination%20Interface As an example, this option is used when identity NAT is used to identify VPN traffic. In that case, if this checkbox is not turned on, the local LAN will attempt to respond to ARP even for requests that can be handled by the local LAN.
Alex_morgan 👍 2 Answered B

Disable proxy ARP in Advanced setting NAT rules.
Doris8000 👍 1

Additional details By default, all ARP packets are allowed between bridge group members. You can control the flow of ARP packets by enabling ARP inspection. ARP inspection prevents malicious users from impersonating other hosts or routers (known as ARP spoofing). ARP spoofing can enable a “man-in-the-middle” attack. For example, a host sends an ARP request to the gateway router; the gateway router responds with the gateway router MAC address. The attacker, however, sends another ARP response to the host with the attacker MAC address instead of the router MAC address. The attacker can now intercept all the host traffic before forwarding it on to the router. https://www.cisco.com/c/en/us/td/docs/security/firepower/610/configuration/guide/fpmc-config-guide-v61/platform_settings_for_firepower_threat_defense.html#:~:text=all%20ARP%20packets%20are%20allowed%20between%20bridge%20group%20members.
d0980cc 👍 1 Answered C

The issue could be related to NAT and proxy ARP to destination interface (outbound), but the issue is with inside client to client. Therefore since it's a new deployment, I'd change it to Transparent Mode. I choose C
gwb 👍 1

My choice is "ACP for ARP inside to inside". I guess that NAT is not usually implemented between inside and inside.