ASA 5540 FTP problem

Answered Question
Dec 18th, 2009

I am having problem on ASA 5540 during FTP data transfer between DMZ's.  ASA 5540 is configured one interface for INSIDE, the second for OUTSIDE (internet) and the third interface for three DMZ's by creating subinterfaces. When ever I initiate FTP from INSIDE to one of DMZ's and start data transfer, all other connection from INSIDE to DMZ including traffic to OUTSIDE will be very very slow  or some times time out. But when data transfer is finished, every thing will be normal.

I checked the configuration including NAT/PAT, IPS, access-lists but found nothing wrong. show perfmon also shows normal stats. There is also nothing change on memorey or cpu utilization during the problem.  When checking connectivity from the ASA it self  to DMZ ,it is also pefect. the problem is only on Inter DMZ communication.

Any comment apreciated!

thanks

I have this problem too.
0 votes
Correct Answer by Poonguzhali Sankar about 4 years 4 months ago

From the captures that you posted. ICMP replies were sent out the inside interface but, your host didn't receive it. Why?

I don' t believe this is a firewall problem. What happens after the replies leave the firewall? Can we run a span on the switch? Is there a layer 3 device on the inside doing some sort of QoS/Policing?

-KS

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (2 ratings)
sachinraja Fri, 12/18/2009 - 08:52

Hi Jemal

I think on the ASA, you checked what you can, incl CPU, xlate, acl etc... i hope all these parameters are under control.. which IOS version are you running on the ASA ? Did you check for open caveats etc ?  Since the DMZs are on subinterfaces, did you check the switchport which is connected to the DMZ interface for errors, duplex issues , stp issues etc ? did you say you just have issues connecting one DMZ to another, when FTP transaction takes place ?

Raj

Poonguzhali Sankar Fri, 12/18/2009 - 09:38

Pls. make sure you are following this:

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/intrface.html#wp1049451

If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets. This property is also true for the active physical interface in a redundant interface pair. Because the physical or redundant interface must be enabled for the subinterface to pass traffic, ensure that the physical or redundant interface does not pass traffic by leaving out the nameif command. I

Best thing is to collect packet captures and see what he issue may be.

capture command has a match keyword now to make it each to configure.

cap capdmz int dmz match ip ho 10.10.10.1 host 192.168.2.1

cap capin int inside match ip ho 10.10.10.1 host 192.168.2.1

sh cap capin

sh cap capdmz

to view the captures and issue

clear cap capin

cle cap capdmz

to clear them and collect fresh packets.

-KS

alhabesha Sat, 12/19/2009 - 04:57

Thanks kusankar,

The DMZ physical interface is not configured with the command nameif.It is configured only on subinterfaces. Atached is partial configuration of it.

I tried to capture packets (ping and telnet between DMZ's)  before and during FTP data transaction, it seems the same on ASA  but I can see  high latency or time out on nodes during inter DMZ communications when the FTP data transaction occured.

Before FTP data transaction started!

Header 1Header 2
C:\>ping 172.16.30.126 -t

Pinging 172.16.30.126 with 32 bytes of data:

Reply from 172.16.30.126: bytes=32 time=4ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3ms TTL=252
Reply from 172.16.30.126: bytes=32 time=7ms TTL=252
Reply from 172.16.30.126: bytes=32 time=4ms TTL=252
Reply from 172.16.30.126: bytes=32 time=4ms TTL=252
Reply from 172.16.30.126: bytes=32 time=4ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3ms TTL=252
Reply from 172.16.30.126: bytes=32 time=4ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3ms TTL=252
Reply from 172.16.30.126: bytes=32 time=4ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3ms TTL=252
ASA-01(config)# sh capture capin
44 packets captured
   1: 11:21:17.848726 192.168.8.214 > 172.16.30.126: icmp: echo request
   2: 11:21:17.851274 172.16.30.126 > 192.168.8.214: icmp: echo reply
   3: 11:21:18.850297 192.168.8.214 > 172.16.30.126: icmp: echo request
   4: 11:21:18.851579 172.16.30.126 > 192.168.8.214: icmp: echo reply
   5: 11:21:19.852494 192.168.8.214 > 172.16.30.126: icmp: echo request
   6: 11:21:19.853776 172.16.30.126 > 192.168.8.214: icmp: echo reply
   7: 11:21:20.852876 192.168.8.214 > 172.16.30.126: icmp: echo request
   8: 11:21:20.854173 172.16.30.126 > 192.168.8.214: icmp: echo reply
   9: 11:21:21.853151 192.168.8.214 > 172.16.30.126: icmp: echo request
  10: 11:21:21.854585 172.16.30.126 > 192.168.8.214: icmp: echo reply
  11: 11:21:22.853532 192.168.8.214 > 172.16.30.126: icmp: echo request
  12: 11:21:22.855027 172.16.30.126 > 192.168.8.214: icmp: echo reply
  13: 11:21:23.853318 192.168.8.214 > 172.16.30.126: icmp: echo request
  14: 11:21:23.854585 172.16.30.126 > 192.168.8.214: icmp: echo reply

During FTP data transaction!

Header 1Header 2
Reply from 172.16.30.126: bytes=32 time=3563ms TTL=252
Reply from 172.16.30.126: bytes=32 time=3588ms TTL=252
Reply from 172.16.30.126: bytes=32 time=259ms TTL=252
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 172.16.30.126: bytes=32 time=285ms TTL=252
Request timed out.
Reply from 172.16.30.126: bytes=32 time=3540ms TTL=252
Reply from 172.16.30.126: bytes=32 time=109ms TTL=252
Request timed out.
Request timed out.
Reply from 172.16.30.126: bytes=32 time=12ms TTL=252
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
ASA-01(config)# sh capture capin
64 packets captured
   1: 11:26:14.567872 192.168.8.214 > 172.16.30.126: icmp: echo request
   2: 11:26:14.570374 172.16.30.126 > 192.168.8.214: icmp: echo reply
   3: 11:26:19.920362 192.168.8.214 > 172.16.30.126: icmp: echo request
   4: 11:26:19.921888 172.16.30.126 > 192.168.8.214: icmp: echo reply
   5: 11:26:20.921140 192.168.8.214 > 172.16.30.126: icmp: echo request
   6: 11:26:20.922590 172.16.30.126 > 192.168.8.214: icmp: echo reply
   7: 11:26:21.921232 192.168.8.214 > 172.16.30.126: icmp: echo request
   8: 11:26:21.922590 172.16.30.126 > 192.168.8.214: icmp: echo reply
   9: 11:26:26.000015 192.168.8.214 > 172.16.30.126: icmp: echo request
  10: 11:26:26.001418 172.16.30.126 > 192.168.8.214: icmp: echo reply
  11: 11:26:27.000686 192.168.8.214 > 172.16.30.126: icmp: echo request
  12: 11:26:27.001922 172.16.30.126 > 192.168.8.214: icmp: echo reply
  13: 11:26:32.421303 192.168.8.214 > 172.16.30.126: icmp: echo request
  14: 11:26:32.423012 172.16.30.126 > 192.168.8.214: icmp: echo reply
  15: 11:26:35.989557 192.168.8.214 > 172.16.30.126: icmp: echo request

Thank you again!

alhabesha Fri, 12/18/2009 - 23:43

Thanks Raj,

ASA software version running is  8.0(3). Yes I have checked ports both on the switch and ASA for errors,duplex issues....which shows normal status.

The issue is  when ever there is FTP transaction from one of DMZ servers to INSIDE, all other traffic (except the already opened  ftp data transaction) in inter DMZ communication like from INSIDE to other DMZ's and OUTSIDE is very very slow(will be above 500ms or time out which was 1ms during normal time). As soon as data transfer is finished and when there is no FTP data transfer, every thing works fine.

couldn't find open caveats for this spesfic case..

thanks again..

Correct Answer
Poonguzhali Sankar Sat, 12/19/2009 - 06:05

From the captures that you posted. ICMP replies were sent out the inside interface but, your host didn't receive it. Why?

I don' t believe this is a firewall problem. What happens after the replies leave the firewall? Can we run a span on the switch? Is there a layer 3 device on the inside doing some sort of QoS/Policing?

-KS

alhabesha Sun, 12/20/2009 - 23:22

Hello  Kusankar,

As you said,  It was not a firewall problem..There was packet shaper which is directly connected to the inside Interface with policing enabled..when shapping feature is disable from it , every thing works fine..

it realy helps me alot..

Thank you very much

Actions

Login or Register to take actions

This Discussion

Posted December 18, 2009 at 12:43 AM
Stats:
Replies:7 Avg. Rating:5
Views:1119 Votes:0
Shares:0
Tags: asa_5540
+

Related Content

Discussions Leaderboard

Rank Username Points
1 7,861
2 6,140
3 3,170
4 1,473
5 1,446