Reading through the detailed solutions guide more thoroughly showed me that you had the exact issue that I had. It presents on ASA1b as "FTP port command different address" (page 24). This is due to the fact when ASA1a is configured as per the detailed solutions guide, it does not inspect ftp traffic that fails the deep packet inspection class map and falls through to the inspection_default. Personally, I think it is a bug but is not documented. The result is that the ftp fixup code does not modify the port command as the traffic flows through ASA1a. This made me pull my hair out. The traffic that matches the deny statement should be able to use the stou and put commands. The problem is it is inspected as generic tcp instead of ftp. The cleanest way have have found to resolve this is as follows:
On ASA1a access-list VLAN6FTP extended permit tcp any 8.9.6.0 255.255.255.0 eq ftp access-list FTPTRAFFIC extended permit tcp any any eq ftp class-map VLAN6FTP match access-list VLAN6FTP class-map FTPTRAFFIC match access-list FTPTRAFFIC policy-map type inspect ftp FTPTRAFFIC parameters match request-command put stou reset log policy-map type inspect ftp FTPTRAFFIC parameters match request-command put stou reset log policy-map global_policy class VLAN6FTP inspect ftp class FTPTRAFFIC inspect ftp strict FTPTRAFFIC class inspection_default <--snip--> I used R6 8.9.56.6 for ftp and changed the ACL's around to test. This makes the error that is documented in the dsg on page 24 go away. On Mon, Sep 7, 2009 at 3:05 PM, Tyson Scott <[email protected]> wrote: > 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: [email protected] > > > > Join our free online support and peer group 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
