I noticed numerous amount of CLDAP traffic to one of my DC starting 3/17/20. The device is a Firepower 1010 running FTD 220.127.116.11. The FTD has no open ports and only two NAT rules. One rule for a site to site VPN and the other rule for devices from the inside to the outside. From vFMC, I can see the connections attempt from the outside source (Initiator) hitting my internal DC at 192.168.50.5 (Responder) with my Firepower rule to block udp/389, see Figure 1. Figure 2 is Wireshark capture prior to the block rule which seems to indicate the DC is repsonding to the CLDAP queries.
How is this network connection possible if there are no open ports on the FTD and no NAT to public IP? Am I reading this correctly?
Did you work with Cisco on this or were you able to determine this on your own. I had a TAC case opened and Cisco told me the connection started from the inside which xlate then allowed back in. This was after 3 hours of going to packets trace. However, I wasn't fully convince.
Have you confirmed with Cisco this is a bug or at the very least this is "as expected" behavior"?
I figured it out on my own by combing through various Firepower reports, specifically the connection events. I had an inspect rule that was ingesting traffic for inspection (I followed Lammle's configuration videos); however, that rule somehow allowed outside CLDAP traffic to reflect off a domain controller on the inside network. This reflection ramped up recently to the point where my carrier was dropping packets to throttle me.
Great, I'm new to these FTD and so far I'm not that happy with them especially the separate management interface to connect to FMC. I thought by switching from the ASA with Firepower to these FTD, it would be easier to manage as in updates and such. So far, I've had nothing but problems. Would you mind sharing your link as to know where to adjust these inspection rules?
I'm using a virtual FMC. I went to Policies - Access Control and edited an "inspect all traffic" rule I made about a year ago. I learned that rule was at fault when I checked connection events and drilled into one of the many CLDAP events.
With my FP2110s, I followed Todd Lammle's video series for configuration (I recommend it). FTD is sluggish and arcane, but if you update your boxes fully and understand their quirks, they're decent.