Paul,

 

Thank you for bringing it back to memory.  Sorry I did forget about that
problem.  Understood.  I will go back and revisit it soon.

 

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> 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: Paul Stewart [mailto:[email protected]] 
Sent: Tuesday, September 08, 2009 10:33 AM
To: Tyson Scott
Cc: [email protected]
Subject: Re: [OSL | CCIE_Security] FTP Deep Packet Inspections

 

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> 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

Reply via email to