cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5168
Views
0
Helpful
7
Replies

FTP poblem in Site to Site IpSec VPN

nikolag21
Level 1
Level 1

Hi all...

I need some help...

Ok, I have 1 PIX and 1 ASA Firewall, both ver. 8.0.4. Between them I have Site to Site VPN and defined interesting traffic in crypto maps. For now everything is ok,

except when I try to ftp from one perticular server to another. Let me explain this better.

Lets say, Client A has ip address of 192.168.1.1 and server B has the Ip address of  192.168.101.1. I have defined interesting traffic in crypto map for site to site VPN  (source: 192.168.1.1 , destination 192.168.1.101.1 , service : IP protect.) . I log in from the ftp client to the ftp server , I can see the tunnel is created and there is flow inside. If I do a list of some folder with a couple of files it ok.But when i try to do a list of some folder with more files(more data for ftp server to send to a client)  ,then ftp sesson stucks. I did some pakcet capure and I can see duplicate ack on the side of the ftp client and restansmition attempts of the side of the ftp server, but the data dont get to the ftp client. On the PIX where the ftp server resides I can also see that the packets are leaving the tunnel but on the side of the ASA where the fto client resides I cannot see those pacets. If I remove this ftp trafic from the ftp tunnel everything is ok.

Please help,

Best Regards

1 Accepted Solution

Accepted Solutions

The ASA usually adjusts the MSS "automatically" to 1380 - as the SYN  packet goes from "inside" to "outside", it should adjust it from  (usually) 1460 down to 1380.  If you did a packet capture on the remote  end for the SYN, you will probably see the MSS at 1380.  The same is  true of the return packet - the SYN-ACK - the MSS should also be  adjusted down to 1380.  You could verify this by capturing the SYN-ACK  on the local end.  This is done to accommodate the IPSEC header.

To further troubleshoot why the ASA is not adjusting the MSS (if that is the case) or why the upstream IOS device is/isn't dropping the packet, please feel free to open a case with TAC.

If you could, please be sure to mark this thread as "answered".

Best Regards,

Kevin

View solution in original post

7 Replies 7

Kevin Redmon
Cisco Employee
Cisco Employee

What is the MSS as seen in the SYN/SYN-ACK for the secondary data connection?  What is the current MTU for the outside interface of the ASA?  Remember, whatever the size of the packet is, we will need to add an IPSEC header prior to putting it on the wire.  If we are exceeding the MTU, the packet will need to be fragmented - assuming the DF bit is NOT set (not sure what the default behavior is).

By default, the ASA should change the MSS bi-directional on the SYN/SYN-ACK messages to be 1380.  This 1380+IPSEC header must be lower than the MTU as configured on the interface.

Any syslogs that you can provide at the time of the issue will be helpful.  If this answers your question, please be sure to mark this question as answered.

Best Regards,

Kevin

First of all than you for your quick reply.

MSS size in SYN/SYN-ACK of ftp-data (20) is 1460 bytes and flag is set to "Don't fragment". MTU of the outside interface is 1500. Maybe this is the problem,the payload of the IpSec is more then MTU of the outside interface? And if so, how can I set ftp-data to be fragmented ?


Best Regards

I did a little research on the internet and i solved the problem with this article:

http://msdn.microsoft.com/en-us/library/ms817967.aspx

I didi the following on the Windows 2003 server where my ftp server resides:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters key:

  • EnablePMTUBHDetect. This value  adjusts the PMTU discovery algorithm to attempt to detect noncompliant  routers, also called PMTU black hole routers. PMTU black hole detection  is disabled by default but can be enabled by adding this value to the  registry key and setting it to 1.

  • EnablePMTUDiscovery. This value  enables or disables the PMTU discovery mechanism, helping to diagnose  problems with black hole routers. PMTU discovery is enabled by default  but can be disabled by adding this value to the registry key and setting  it to 0.

But I don't know why this happened in the first time, why MSS is not lower by default?

Your answer was very very helpfull !

Cheers,

I did some readings on the internet so the question is :

The question is why didnt ASA sent any ICMP Error Message to the ftp server to re adjust MSS size ? Is pmtud enabled by default ? And 3rd question, what is recomended MTU size of IpSec vpn interfaces, currently mine is set to default 1500 ,maybe I should change this on both sides to avoid sometning similar to happen ?

Waiting for reply,

Regards

The ASA usually adjusts the MSS "automatically" to 1380 - as the SYN  packet goes from "inside" to "outside", it should adjust it from  (usually) 1460 down to 1380.  If you did a packet capture on the remote  end for the SYN, you will probably see the MSS at 1380.  The same is  true of the return packet - the SYN-ACK - the MSS should also be  adjusted down to 1380.  You could verify this by capturing the SYN-ACK  on the local end.  This is done to accommodate the IPSEC header.

To further troubleshoot why the ASA is not adjusting the MSS (if that is the case) or why the upstream IOS device is/isn't dropping the packet, please feel free to open a case with TAC.

If you could, please be sure to mark this thread as "answered".

Best Regards,

Kevin

Yes,I can see that in SYN/SYN,ACK there is 1380 and actually, this one is used for MSS. But still packets are dropped until on the ftp server I've done modifications I mentioned above. I cannot realize why this happened in the first place...

Can you please give me some guides about should I increase MTU on the VPN interfaces to avoid this kind of issues in the future? We are tolking about 2 mb dll connection between these 2 firewalls?

Thank you so much for your help,

Best Regards

It is probably not a good idea to increase the MTU much above 1500.  1500 is the "default" that I've seen on most routers so the traffic will either be fragmented now...or later.  Most applications will honor the exchanged MSS, not requiring you to modify the MTU on the ASA.  Seemingly, the FTP server didn't honor this exchanged MSS.

If you need to modify MTU in the future, you can use the command 'mtu ':

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/m.html#wp2040442

Best Regards,

Kevin

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card