cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
820
Views
0
Helpful
0
Replies

Protocol Inspection/Pin-holing on Threat Defense 6.2.0 (4110 Chassis)

betfred.com
Level 1
Level 1

Hi,

I've recently configured and deployed a brand new FirePOWER 4110 chassis running the new FTD unified image at software version 6.2.0. Pretty much all required features from ASA work, I even managed to get EIGRP working correctly first time with redistribution and route-maps using the FlexConfig implementation.

However, I'm having a number of issues with protocol inspection and I'm not even sure if it's a supported feature within FTD completely (I know enabling/disabling protocol inspection is supported via FlexConfig). Thought I'd see if anyone else has had anything similar and if there's actually an effective work-around.

So I've got two scenarios I need help with:

1) I've got various hosts connecting to a load-balancer for FTP services, they just grab small files (KB) and upload some reports every so often. The clients are using active FTP and this worked fine with inspection on the old ASA & on the LB (Cisco ACE - don't ask...). Looking at my logs, I can see the connection build from client to server fine on TCP21, also I can see a standard reply from the LB on port 20 (FTP Data). Inspection policy for FTP is also showing multiple hits on the FTD CLI. Now this connection is built when I look at the standard ASA-type Syslogs (I appreciate they're not technically identical), and then I get a "Block" Action in the Event Viewer in FTD (see attachments). This in turn eventually produces a SYN Timeout Syslog as if the ASA is just waiting for its reply. Does the FTD aspect of the device not account for ASA inspection? I would imagine that was a key point in why they created a unified image? I may be wrong, but I need an answer as if I just have to allow reverse-path flows via ACLs, it shows me that inspection is nigh-on useless at this point.

2) VoIP phones are also causing me a headache. I can see in logs again that the initial Skinny session opens fine (TCP2000) and I can see hits on the inspection policy on the FTD CLI. From there it then attempts to setup up RTP/RTCP streams as per normal call behaviour. Similar to the FTP, this return traffic is not permitted via ACL on the FTD, as I would expect inspection to allow the secondary flow. This doesn't seem to be the case however (logs attached again).

So basically, I would like to know if anyone has had similar issues with this and if there is any way of fixing this with the use of traditional inspection? If there isn't and I just have to allow ports back through on the ACL then so be it, not a great fix, but something that will work at the very least.

Any help would be greatly appreciated. Want to make sure I'm not running down a long dead-end path.

Phil

0 Replies 0
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card