FTP Inspection with port redirection

[chris.grammer]

I have a single FTP server behind and ASA 7.2 firewall.

The FTP server is our primary FTP server and listens on the standard control port 21 using passive FTP.

We need to use the same server to run a separate instances of FTP but on control port 2121.

The first thing I thought of was to use port translation to translate 2 separate public IP addresses to the backend private IP server.

My problem is not know how exactly NAT and FTP inspection work on the ASA in this situation.

Currently my NAT configuration is 63.x.y.50 -> 172.10.254.50 with FTP inspection on port 21.

Everything works fine.

I would like to change the NAT from a standard 1 to 1 NAT to a Port Redirect translation:

172.10.254.50:21 -> 63.X.Y.50:21

And

172.10.254.50:2121 -> 63.X.Y.190:21

The backend server IP is the same with different ports. The public IPs are different with the same ports.

The question is will the ASA inspection engine still allow both FTP sessions secondary data connection and keep the connections straight.

If this was a standard source/destination port application, I believe this would work fine, but with the secondary FTP connection that must be opened and allowed using FTP inspection, I am not sure what will happen and I don't have a pix to test with.

Thanks for everyone's help in advance.

Chris

[sachinraja]

Chris

theoritically speaking this should work..I dont see any problems in it, unless something crazy happens at application layer.. You can use a static PAT, and configure something like this:

hostname(config)# static (inside,outside) tcp 63.X.Y.50 ftp 172.10.154.50 ftp netmask

255.255.255.255

hostname(config)# static (inside,outside) tcp 63.X.Y.190 ftp 172.10.154.50 2121 netmask 255.255.255.255

Depending on the user request, appropriate translations happen, and the request is processed ! First connection (passive FTP) anyway would work with all inspections in place.. I think the second one should also work fine, with appropriate ACL's in place.. All the best.. Even I dont have a PIX to test this :(

Let us know

Raj

[chris.grammer]

My concern is how the inspection process will handle the translation from 21 to 2121 and will it allow the secondary data connection. My understanding of how FTP inspect works is that it actually observes the control channel and creates a dynamic hole in the firewall that it sees as a result of the PASV command from the client. The inspect process is watching specifically port 21, but the question is where does it observe the packet? Before or after translation? This may require an addition to the inspection rule.

Next, if the inspection where to allow the secondary connection, what translation will it use?

[sachinraja]

Chris

I think the translation would happen first... for sure.. when a request comes onto port 21 (second instance), the ASA knows that this is a passive ftp connection, translates (to port 2121), applies inspection and forwards it to the server. the server then responds with a non-standard port connection for the data.. I think you might need to add an inspection rule for nonstandard ftp ports, since the packets are translated to 2121, before inspection (hopefully :))

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

!

class-map ftp-class

match access-list ftp-list

!

policy-map global_policy

class ftp-class

inspect ftp

Try this and let us know.. interesting scenario :) Netpro always helps everyone to learn ;)

Regards

Raj

[manue.elf]

Sorry... can't understand why you're saying 'when a request comes onto port 21 (second instance), the ASA knows that this is a passive ftp connection'. As long as the control channel only is open you cannot tell if ftp session will be active or passive, since the very first connection is (apart from specific cases) always made over tcp 21.

I mean:

ACTIVE FTP

control channel

source client tcp gt 1023 > destination server tcp 21

data channel

source server tcp 20 > destination client tcp gt 1023

PASSIVE FTP

control channel (same as above)

source client tcp gt 1023 > destination server tcp 21

data channel

source client tcp gt 1023 > destination server tcp gt 1023

Please clarify, maybe I misunderstood your statement.

thanks

[chris.grammer]

OK I'll try to make it is clear as possible.

Active FTP is not used.

This is only passive FTP.

There is a single FTP server in a DMZ of a ASA 7.2 firewall. Its real IP address is 172.x.y.50. That server has 2 Instances of FTP running. One instance is listening on the standard FTP control port 21. The second instance is listening on control port 2121.

There will be two configured static port translations from outside to DMZ. There will be two separate Public IP addresses with one DMZ private address.

63.x.y.50:21 - 172.x.y.50:21

63.x.y.150:21 - 172.x.y.50:2121

Any FTP connection to 63.x.y.50:21 will be port translated to 172.x.y.50:21.

Any FTP connection to 63.x.y.150:21 will be port translated to 172.x.y.50:2121.

I fully anticipate the FTP control session to open fine. But, the data channel should not work because there is not a translation for the data channel ports that will be dynamically negotiated between the client and server.

The "Fixup / Inspection" FTP function in a firewall will open a dynamic permit in the outside access-list to allow the data channel. The firewall discovers the dynamically negotiated ports by monitoring the FTP control channel. My question is this:

Does the fixup / inspection function also allow the translation to take place even though there is not a static translation for the dynamically negotiated data channel?

For most instances, this is not a concern because most people would use a 1 to 1 IP NAT translation and the ports do not matter. But, in my instance I want to use multiple instances of FTP on different control ports on the same DMZ FTP server with a single private IP address, but use a different Public IP address for each instance on port 21 and translate 21 to the proper control port.

[manue.elf]

Ok, supposing that you'r going to use several PAT instead of 1 to 1 NAT

63.x.y.50:21 - 172.x.y.50:21

will work perfectly with PASSIVE ftp, be 100% sure.

For your understanging, you will need static port translation AND access-list (outside tcp 21) for command channel ONLY, don't worry about data channel, ftp inspection will dynamically manage BOTH port translation AND access-list for data channel.

63.x.y.150:21 - 172.x.y.50:2121

I still can't give an accurate answer, but I'd say yes, and in case it should the explanation would be the same as above, while in case it shouldn't work I'd try adding a specific inspection rule as suggested by sachinraja, in order to 'force' ftp inspection for non-standard ftp command channel (i.e. over tcp 2121)

Anyway, your problem was already quite clear to me (sorry not to have given my opinion before) but my concern was to understand from sachinraja the way he was considering ftp active or passive... :)

[sachinraja]

manue.. u are right.. passive is known only when the server responds. the first connectivity will establish in 21 ! I think I had my wordings wrong :)

BTW, did this work out ? As manue said, it should work.. Otherwise have a second NIC card for the server, with a different IP address, and do a static for that :) no complications..hehe

Raj

[chris.grammer]

I have decided to go with the second NIC in the server and simply use a 1 to 1 NAT with an individual internal and external IP for both NICs.

I wish I had the environment to test this. I think both will fail on the data side and both will work on the control side The reason I believe the data channel will fail is there will be no port translation for the negotiated dynamic ports of the data channel of either connection. I cant verify if the Fixup function dynamically creates a port translation as well as makes a dynamic permit for the outside access-lists.

[sachinraja]

Way to go Chris :)