%FWSM-4-406002 - Unable to utilize PASV ftp when masquerading

Answered Question
Dec 21st, 2011
User Badges:

Hello,


I'm faced with bit of a problem. I have a setup with an ACE loadbalancer which loadbalances PASV ftp traffic across two ftp-servers. Behind the ACE, we have a firewall, with a dmz where the ftp-servers reside.


When we disable to 'masquerade' feature on the ftp-server, that is we don't inform the ftp-client of the external ip-address on the ACE, but rather send the actual rfc1918 ftp-server address with the PASV respond, it works for some client. Somehow, some clients are able to disregard the rfc1918 address and instead use the public address used during the initial setup. Other clients don't work.


But when we insert the actual public ip on the ftp-server, the connection is broken, when the client attempts to enter PASV mode. The firewall in front of the ftp-server issues the following msg:


%FWSM-4-406002: FTP port command different address: x.x.x.x(y.y.y.y) to z.z.z.z on interface Websrv-DMZ-Prod


x.x.x.x = actual ftp-server address

y.y.y.y = public ftp-server address (masqueraded)

z.z.z.z = nat-address on ACE for client ftp-requests to avoid asymmetric routing


We've tried to diable src.nat on the ACE (the z.z.z.z address is the NAT-address of external client requests), but the problem persists. So far, we attribute this to ftp-inspection, which is enabled. We do not, however, wish to disable ftp-inspection, but rather we're looking into a way to selectively disable ftp-inspection for this particular flow.


Is there any way to achieve this?


thanks


/ulrich

Correct Answer by mirober2 about 5 years 7 months ago

Hi Ulrich,


You are correct that the FTP inspection is causing the problem. If the FWSM inspects the traffic, you should not use the masquerading feature as the inspection will take care of re-writing the server's IP address for you.


To answer your question though, you can use the following to disable FTP inspection for a particular flow:


access-list myftp-acl deny tcp any host x.x.x.x eq 21

access-list myftp-acl permit tcp any any eq 21

!

class-map myftp-class

   match access-list myftp-acl

policy-map global_policy

   class inspection_default

       no inspect ftp

   class myftp-class

       inspect ftp

service-policy global_policy global


The above commands create a custom class-map that matches all FTP traffic except that which is destined to your FTP server and then enables the inspection based on that class.


-Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
mirober2 Fri, 01/06/2012 - 10:16
User Badges:
  • Cisco Employee,

Hi Ulrich,


You are correct that the FTP inspection is causing the problem. If the FWSM inspects the traffic, you should not use the masquerading feature as the inspection will take care of re-writing the server's IP address for you.


To answer your question though, you can use the following to disable FTP inspection for a particular flow:


access-list myftp-acl deny tcp any host x.x.x.x eq 21

access-list myftp-acl permit tcp any any eq 21

!

class-map myftp-class

   match access-list myftp-acl

policy-map global_policy

   class inspection_default

       no inspect ftp

   class myftp-class

       inspect ftp

service-policy global_policy global


The above commands create a custom class-map that matches all FTP traffic except that which is destined to your FTP server and then enables the inspection based on that class.


-Mike

Ulrich Hansen Sun, 01/08/2012 - 14:45
User Badges:

Hi Mike,


Thanks for your reply.


You've got a point and I will definitely look into it. What makes our design a bit problematic is the fact, that the firewall sits behind a loadbalancer, which owns the public ip and does loadbalancing. We've tried to disable masquerading, but when we do, the FTP-server replies with it's own rfc1918-address in the ftp-header and while some clients apparently have the intelligence to disregard this and simply continue to use the public-ip used in the initial dialogue, other clients don't.


Again, thanks for replying.


/Ulrich

Actions

This Discussion