Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
New Member

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

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

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: %FWSM-4-406002 - Unable to utilize PASV ftp when masqueradin

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

2 REPLIES
Cisco Employee

Re: %FWSM-4-406002 - Unable to utilize PASV ftp when masqueradin

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

New Member

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

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

883
Views
0
Helpful
2
Replies
CreatePlease to create content