Paul,
It is not uncommon to have varying success with things so it is good to work thru it to make sure it is actually working for you. It is not wrong to add another class-map though to match the traffic. I don't think this would be marked wrong either way. All that matters is that you get it to work in the end. I used XP to test in the end as well to make sure the configuration was working but it also used active FTP. As is stated at the beginning of all the solution guides. This is provided as a sample solution for this Lab. However some sections may have other methods of completing the tasks that still meet the requirements as stated. If you are unsure what a section is asking, or whether an alternate configuration method meets the stated requirements, make sure to ask for clarification. Regards, Tyson Scott - CCIE #13513 R&S and Security Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Cell: +1.248.504.7309 Fax: +1.810.454.0130 Mailto: <mailto:[email protected]> [email protected] Join our free online support and peer group communities: <http://www.IPexpert.com/communities> http://www.IPexpert.com/communities IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: [email protected] [mailto:[email protected]] On Behalf Of Paul Stewart Sent: Monday, September 07, 2009 1:45 PM To: [email protected] Subject: [OSL | CCIE_Security] FTP Deep Packet Inspections In working through Vol 2, Lab 11, I have found that FTP inspections don't work like I would expect them. Specifically in Section 1.6 traffic matching the deny statements do not get inspected with the ftp fixup. I would expect them not to be inspected with the DPI that is tied to CM-FTP. However, failing to match the entire class, one would expect the traffic to be inspected with the "inspect ftp" that is in "inspections_default". However, I cannot make this happen. I am positive that the order of classes are correct and even cleared it and typed line by line according to the detailed solution guide. The net result or what I is that Acitve mode FTP fails, but I think passive mode would still work. I am using a router as the FTP server. The only fix I have found is to create another class to inspect the traffic that should otherwise default to the global inspect rule. Anyone else seen anything similar. I've fought through this for a few hours, tested quite extensively and even looked through the bug toolkit. FTP Matching the DENY statements fail to be inspected. As a result the PORT command does not get translated. Below was my fix. //FTP that will be reset with stou or put access-list FTP extended deny tcp any 8.9.6.0 255.255.255.0 eq ftp access-list FTP extended permit tcp any any eq ftp //FTP that will be permitted with stou or put access-list OTHERFTP extended permit tcp any 8.9.6.0 255.255.255.0 eq ftp class-map OTHERFTP match access-list OTHERFTP class-map CM-FTP match access-list FTP policy-map type inspect dns preset_dns_map parameters message-length maximum 512 policy-map type inspect ftp PM-FTP parameters match request-command put stou reset log policy-map global_policy class OTHERFTP inspect ftp class CM-FTP inspect ftp strict PM-FTP class inspection_default <--snip--> inspect ftp
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
