File transfer problems through VPN when Cisco IPS is enabled

Question

We have a Cisco ASA 5510 firewall with the IPS module installed.

We have a customer that we must connect to via VPN to their network to exchange files via FTP. We use the Cisco VPN client (version 5.0.01.0600) on our local workstations, which are behind the firewall and subject to the IPS.

The VPN client is successful in connecting to the remote site. However when we start the FTP file transfer we are able to upload only 150K to 200K of data, then everything stops. A minute later the VPN session is dropped.

I think I have isolated this to an IPS issue by temporarily disabling the Service Policy on the ASA for the IPS with the following command:

access-list IPS line 1 extended permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 inactive

After this command was issued I then established the VPN to the remote site and was successful in transferring the entire file.

While still connected to the VPN and FTP session I issued the command to enable the IPS:

access-list IPS line 1 extended permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

The file transfer was tried again and was once again successful so I closed the FTP session and reopened it, while keeping the same VPN session open. This file transfer was also successful. This told me that nothing with the FTP programs was being filtered or causing the problem. Furthermore, we use FTP to exchange files with many sites everyday without issue.

I then disconnected the original VPN session, which was established when the access-list was inactive, and reconnected the VPN session, now with the access-list active. After starting the FTP transfer the file stopped after 150K.

To me this seems like the IPS is blocking, or somehow interfering with the initial VPN setup to the remote site.

This only started happening last week after the latest IPS signature updates were applied (sig version 407.0). Our previous sig version was 95 days old becuase the system was not auto updating itself.

Any ideas on what could be causing this problem?

Answer 1

Try setting the MTU down on the sending side (in fact both sides will probably need it). Could be there is a device that's either not generating or not passing Path MTU discovery packets correctly. If lowering the mtu to, say, 1350 on both ends fixes it, then investigate whether you have ACLs blocking ICMP.

Answer 2

There is nothing in the 407 signature related to FTP. Generally when you have FTP issues like this, that start and then stop, it's usually related to active vs. passive ftp. What ftp client are you using? Try changing it from active to passive on your FTP client and see if that helps.

In active FTP, the place that you're FTPing to, initiates the data transfer on a different port then the incoming request...which is why it's usually blocked by your firewall.

In passive FTP, YOU initiate the data transfer to the different port and it works because most firewall allow everything outbound to occur.

Edited to add: The signatures are cumulative. While the 407 update doesn't show anything related to FTP, every other update from 95 days ago till now, could have something. I'm not going to research every update to find out for you though ;)

I also have to ask because of your other questions about this...are you using the default inspections on this 5510 in addition to diverting traffic to the IPS module? If you are, you really don't need to.

Answer 3

The fact that it begins the transfer at all indicates that it has no problem establishing the data part of the FTP session, which rules out an ACL blocking the connection in or out. The VPN session itself dropping during the large file transfer does seem to point to an IPS taking action on the connection (although you would think it would just terminate the FTP session, but the actions are configurable so who knows?) If you think it is your IPS dropping the VPN session, you should have logs to look through and IPS alerts if it is your IPS dropping it. Is your IPS running in promiscuous mode (basically IDS mode) or inline mode? As far as I know, it can't drop traffic if it is in promiscuous mode since it only receives a copy of the traffic. Since it has been working with no changes on your end thus far (other than a signature update), I would ask the customer if they changed anything on their end disallowing large file transfers over a certain size; especially since you said you FTP to other sites with no problem. If it is just with this one customer, you can bet the problem is on their end.

Answer 4

MTU or window scaling could be the reasons

Answer 5

If the ftp transfer is PASV you need to enable the packet inspection, and the appropriate ACL's at the firewall.

Take a backup of you running config first!

This is the procedure I took on our cisco ASA 5505's for packet inspection

1. ssh/telnet to firewall
2. enable
3. conf t
4. class-map inspection_default
5. match default-inspection-traffic
6. press ctrl+z
7. conf t
8. policy-map global_policy
9. class inspection_default
10. inspect ftp
11. wr mem

Answer 6

any access list can have multiple entries your vpn clients will have been allocated a subnet

line one of the acl for the IPS should deny inspection of traffic to/from vpn client subnet line two of the acl should enable IPS for other traffic it may be worth excluding other traffic e.g. isakmp, gre, esp, ah etc from being inspected otherwise would need to see more of your config

Answer 7

I'd say forget using Passive or Active FTP. I hate the dual port nature of FTPS and FTP. Instead, download WinSSHD server and run a SFTP server on a single port: port 22 . That way you are only dealing with a single pinhole.

Connect to it using Tunnelier client .

Answer 8

Just had another idea:

There are 2 kinds of Cisco VPN: IPSec over UDP and IPSec over TCP. Most likely you are using the TCP version which can cause packet loss in a NAT scenerio. The UDP version of VPN is stabler because the TCP headers are wrapped differently. Using the TCP version you can have problems with NAT translation. Its very hard to explain but I would try editing the client side protocol VPN type... change it to IPSec over UDP.

Basically, the other answers on this thread are suggesting changing MTU settings to try to hack/workaround the IPSec over TCP issues that can arise in a NAT. Thats not the way. The way is to use IPSec over UDP and then the MTU doesnt matter.