Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
did you ever find the solution to the problem? –  pcapademic Jan 5 '10 at 9:42
    
Only solutions found was to disable the specfic ruls that was firing. Not really a great solution but I had to get it working. –  Richard West Jan 8 '10 at 1:24
    
can customer deploy a more secure protocol such as scp? FTP is dated and should really be phased out in favour or protocols that don't transmit your password in the clear. –  The Unix Janitor Mar 18 '10 at 17:18
    
@user37899 - this transfer is being preformed over a VPN connection. Therefore it is encrypted already so security is covered. Furthermore, I cannot dictate to a customer what they need to change. I can make suggesstions but that's as far as that can ever go. –  Richard West Mar 23 '10 at 0:31
    
west - what do cisco tac say about the problem? if you can't change what your using, then i'm sure cisco support will be able to help you. –  The Unix Janitor Apr 13 '10 at 21:19
add comment

8 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
    
We are using Ipswitch WS_FTP Pro for the client and we are using passive file transfers. I find passive to be much more firewall friendly. From the troubleshooting it appears that FTP is working OK, and since we don't have problems with FTP to other clients (which are not over a VPN) it lead me to look more at the VPN side of things. Am I chasing a red hearing? –  Richard West Jun 11 '09 at 21:30
    
As GregD asked, are you using the default inspections? –  Daniel Lucas Jun 15 '09 at 19:36
add comment

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.

share|improve this answer
add comment

MTU or window scaling could be the reasons

share|improve this answer
add comment

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
share|improve this answer
add comment

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

share|improve this answer
add comment

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 .

share|improve this answer
    
I'm not in control of the server. That is something that our vendor is in control of. –  Richard West Jan 24 '10 at 0:53
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.