12-18-2009 12:43 AM - edited 03-11-2019 09:50 AM
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
Solved! Go to Solution.
12-19-2009 06:05 AM
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
12-18-2009 08:52 AM
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
12-18-2009 09:38 AM
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
12-19-2009 04:57 AM
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 1 | Header 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 1 | Header 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!
12-18-2009 11:43 PM
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..
12-19-2009 06:05 AM
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
12-20-2009 11:22 PM
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
12-21-2009 05:54 AM
Very glad to hear. Thanks for rating the post.
-KS
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide