cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1038
Views
10
Helpful
4
Replies

FTD leaking traffic

HQuest
Level 1
Level 1

Hi all.

FTD v7.2.0.1 configured from scratch as perimeter firewall, FMC managed. For testing purposes, only two zones, "inside" and "outside".

I created a NAT policy, set up a static "Auto NAT" rule with "inside" as source zone and "outside" as destination zone, and a translation for a server using RFC1918 IP address as original source and a public IP address of my assigned block configured as translated source. With the policy assigned to the FTD, the NAT works like a champ, both ways.

Then, I went to restrict what can go in towards this server. As such, I created an Access Policy, and under "default" section, I granted access from the outside zone into the inside zone, from an "any" source to my internal IP address as destination, to only a few services on the internal server: DNS and HTTPS. Added an implicit "deny all" at the bottom of this default section. Assigned this access policy to this FTD, and while I can see the FMC reporting blocked traffic, it is completely clueless on a large count of packets to ports not allowed still hit my internal server - and I can see them via tcpdump on my server while filtering for SYN and SYN+ACK packets.

Clearly not what I was expecting. And not sure about you but I'm deeply concerned with owning a firewall that doesn't act like one.

Any hints before I hit TAC?

HQuest_0-1661807485770.pngHQuest_1-1661807538518.png

HQuest_2-1661807640987.png

HQuest_3-1661807797055.png

 

 

Edit: And this is exactly why I'm concerned: there is no way on Earth I would allow open SSH access to any internal systems of mine. It took FTD some good count of packets until it realized it was not supposed to allow this to go thru. 

HQuest_0-1661823600829.png

 

4 Replies 4

ACL must use real IP not MAP IP of Server.

I appreciate your suggestion. However even if my policy is incorrect, the explicit “deny all” policy should had been blocking anything towards this box, and it ain’t. Add to the fact the default policy action is also to block all traffic that doesn’t match any policies. So were my policy incorrect, I would not had access to any service. And what I see is the exact opposite. NAT works, the FTD let packets go thru until eventually it wakes up and restricts them.

""it is completely clueless on a large count of packets to ports not allowed still hit my internal server""
that not meaning your FTD is not work but let me give you some note
FTP protocol can be active, meaning that inside the FTP there is Port exchange between Client and Server to make client/server listen to specific port other than know FTP port. 
NOW what this relate to FTD ??
when we do inspect protocol, the FTD check this port (unknown port) and open this port in automatic in ACL.

Not sure why you are describing me how file transfer protocol (FTP) works when this is issue is not related to such protocol but to Firepower Threat Detection (FTD) and the SNORT component. Yes, I am fully aware passive FTP data transfers occurs with dynamic ports and since the ancient days session aware firewalls would open ports on the fly, but this is not related to the problem. As of one of the examples I later added, I had SSH connections being let go thru the FTD, amongst the many portscan type of new sessions incoming, and none of them do not behave in any similar way as FTP.

Review Cisco Networking for a $25 gift card