FTD Control Plane ACL

  • Post author:
  • Post category:Cisco / FTD

Traffic usually traverses a firewall and routed between interfaces; in some circumstances it is beneficial to deny traffic destined “to” the FTDs interface. Like with the Cisco ASA, the Cisco FTD can use a control-plane ACL to restrict traffic “to” the FTD. An example of when a control-plane ACL can be useful, would be to control which peers can establish a VPN (Site-to-Site or Remote Access VPN) tunnel to the FTD.

Important Considerations regarding Control Plane ACLs

  • As of FMC/FTD 7.0, a control-plane must be configured using FlexConfig, using the same command syntax used on the ASA.
  • The keyword control-plane is appended to the access-group configuration, which will enforce traffic “to” the FTD’s interface. Without the control-plane word appended to the command, the ACL would restrict traffic “through” the FTD, from outside to inside.
  • A control-plane ACL will not restrict SSH, ICMP or TELNET inbound to an FTD’s interface. These are processed (permitted/denied) according to the Platform Settings Policies and have a higher precedence.
  • Rarely used in production.
  • A Control Plane ACL restricts traffic “to” the FTD itself, whereas the Access Control Policies controls traffic “through” the FTD.
  • Unlike a normal ACL, there is no implicit deny at the end of the ACL.
  • FTD Geolocation feature cannot be used to restrict access “to” the FTD.

Configuration

This post covers the steps used to configure a control-plane ACL, using the Cisco Firepower Management Centre (FMC) and will restrict a peer from establishing a VPN tunnel to the FTD.

  • Login to the FMC GUI
  • Navigate to Objects > Object Management > FlexConfig > FlexConfig Object
  • Click Add FlexConfig Object

Add the access-list and access-group commands as per the syntax in the screenshot below. The control-plane ACL will be configured inbound on the outside interface(s). Ensure the control-plane syntax is appended to the access-group.

NOTE – The ACL can be more specific, restricting on protocol/port instead of “ip”.

  • Click Save once complete.
  • Navigate to Devices > FlexConfig
  • Modify the existing FlexConfig Policy or create a new policy
  • From the User Defined FlexConfig objects, select the previously configured FlexConfig object and click
  • Click Save

  • Deploy the policy to the FTD.

Testing/Verification

Once the policy has been deployed to the FTD, we can login to the CLI. Run the command show running-config | include CPLANE. From the output below we can confirm that the access-list has been deployed and configured on both outside interfaces.

A VPN is already configured between from a remote ASA (2.2.2.1) to the FTD (1.1.1.8). The output below is from the ASA, we can determine that the ASA was unsuccessful at setting up a tunnel.

From the CLI of the FTD, run the command show access-list CPLANE, note the hitcnt on line 1 = 5. This confirms that inbound traffic from the source IP address of the ASA (2.2.2.1) was denied.

Establish a VPN from an IP address other than 2.2.2.1. From the output below we can determine hits on line 2 of the control-plane ACL, thus permitting the traffic. We can determine that an IKEv2 SA has been established between the FTD (1.1.1.8) and another device on 2.2.2.2.

As demonstrated a control-plane ACL is a simple way to restrict access to the FTD’s interface, bear in mind the considerations mentioned above and know the difference between “to” and “through” the FTD.

Tags: , , ,