How to use fixup to allow passive ftp with non standard port as well as keeping regular ftp

[HWangLoyalty_2]

There is a FWSM (version 3.2(10)) in our enviornment. We also turn on "inspect ftp" for our ftp traffics. Right now a user wanted to connect the external ftp server with passive mode. The port of ftp is non standard port like 5959. The ports of ftp-data are random. I thought I could use the following commands to fix the issue with old version.
==

fixup protocol ftp 21

fixup protocol ftp 5959

===

But right now the command is changed as inspect. If I create a new class-map like this:

access-list ftp-list extended permit tcp any any eq 5959
class-map ftp-class
  match access-list ftp-list
policy-map global_policy
  class ftp-class
   inspect ftp

===

I suspected the following commands could not apply with "global_policy" again

==

class inspection_default
   inspect ftp

===

But how to keep regular FTP traffics (like port 21) to enable fixup? please give me some suggestions. Thanks a lot!

I just researched some documents as the same as the topics, Did you think the following commands could fix our issue?

=========================

access-list ftp-list extended permit tcp any any eq 21

access-list ftp-list extended permit tcp any any eq 5959
class-map ftp-class
  match access-list ftp-list
policy-map global_policy
  class ftp-class
   inspect ftp

[Panos Kampanakis]

access-list ftp-list extended permit tcp any any eq 21

access-list ftp-list extended permit tcp any any eq 5959
class-map ftp-class
  match access-list ftp-list
policy-map global_policy
  class ftp-class
   inspect ftp

is exactly what you want.

You knew the answer already!

PK

[HWangLoyalty_2]

Thanks Pk's response!

I still have another question. During our maintenance with fixup, would the regular ftp sessions with port 21 be deconnected? Will they have to reconnect to FTP server? Thx again!

[Panos Kampanakis]

Existing FTP sessions will not be subject to the new policy. Only new ones will.

So it should be transparent for all passive tp sessions.

PK

[HWangLoyalty_2]

Thanks again!

class inspection_default
......

  inspect ftp

How to deal with inspect ftp under inspection_default? Could it coexist with the new class? Hopefully it is the last question about this topic

[HWangLoyalty_2]

It looked like my soultion did not work. The following is our configration:

access-list ftp-list extended permit tcp host 172.21.4.5 host 216.22.55.55 eq 4822 (4822 is ftp command port,once the connection established, the data port will be random on server end).

class-map ftp-class
  match access-list ftp-list
policy-map global_policy
  class ftp-class
   inspect ftp

when I try to connect their server, the denied traffics still were found on the firewall. But I could find some packets hit on the poilcy, like:

sh service-policy global

Global policy:
  ....

     Class-map: ftp-class
      Inspect: ftp, packet 257, drop 0, reset-drop 0

Did you think let me know why the issue happened? Is it on the server end?

Thx a lot!

[Panos Kampanakis]

It should have worked.

You could enable ftp debugs and try again.

Also you could capture packets and see what was failing? also logs to see if there are denies would help.

Was only 4822 ftp breaking or both 21 and 4822?

PK

[HWangLoyalty_2]

I got the following logs on the firewall, hopefully it is useful

Apr 26 2010 15:55:51: %FWSM-6-302013: Built outbound TCP connection 145767822990905379 for inside:172.21.4.5/1223 (159.12.25.38/31286) to outside:216.22.55.55/4822 (216.22.55.55/4822)
Apr 26 2010 15:55:52: %FWSM-4-106023: Deny tcp src inside:172.21.4.5/1224 dst outside:216.22.55.55/65044 by access-group "acl_inbound-inside" [0x0, 0x0]
Apr 26 2010 15:55:55: %FWSM-4-106023: Deny tcp src inside:172.21.4.5/1224 dst outside:216.22.55.55/65044 by access-group "acl_inbound-inside" [0x0, 0x0]
Apr 26 2010 15:56:01: %FWSM-4-106023: Deny tcp src inside:172.21.4.5/1224 dst outside:216.22.55.55/65044 by access-group "acl_inbound-inside" [0x0, 0x0]
Apr 26 2010 15:58:04: %FWSM-6-302014: Teardown TCP connection 145767822990905379 for inside:172.29.3.35/1223 to outside:216.22.55.55/48221 duration 0:02:12 bytes 5223 TCP Reset-O

BTW, I setup the following ACL:

access-list acl_inbound-inside extended permit tcp host 172.21.4.5 host 216.22.55.55 eq 4822

Pls advice! THx a lot

[HWangLoyalty_2]

Do you think the current situation is bug (CSCta58464) related? If my configration is fine

The version of FWSM is 3.2(10).

Thx a lot!

[HWangLoyalty_2]

Any update for my question? Anybody know it?

Thx a lot

[Jennifer Halim]

Please confirm if it's is clear text FTP, or it's secure SFTP connection?

From the logs, it was denied on the FTP data as it didn't dynamically open the data connection, which makes me to believe that either the FTP inspection is broken, or it is secure FTP connection, hence FWSM can't inspect what port it uses for the passive FTP, therefore, it does not dynamically open the port for the data connection.

[HWangLoyalty_2]

Thanks for your response.

You are right. We did not transfer files with clear text. Based on the FTP server's settings, we chose it as "FTPES". It is smiliar with FTPS.

As you mentioned, FWSM will not inspect dynamic ports if the command channel is encrypted. Is it right?

[Jennifer Halim · Accepted solution]

You are absolutely correct. As it is encrypted FTP, the FWSM is unable to look into the packet, therefore, unable to dynamically open pinhole for the FTP data connection.