ftp connection error on ASA but not on PIX

[jdlcisco1]

I recently upgraded from a PIX to ASA 5510. The configuration is almost identical the only difference I can see is the software version number.

Cisco PIX Security Appliance Software Version 7.1(2)
Device Manager Version 5.1(2)

Cisco Adaptive Security Appliance Software Version 8.2(1)
Device Manager Version 6.2(1)

after moving to the ASA I found that it broke FTP. we have an internal server that connects daily to and external server on the public internet via ftp. everything works just fine when running throught the PIX below is the config.

PIX

--------------------------------------------------------------------------------

jdlfw# sh run | grep ftp
ftp mode passive
access-list acl_in extended permit tcp any any eq ftp
access-list acl_in extended permit tcp any any eq ftp-data
  inspect ftp
  inspect tftp

ASA

------------------------------------------------------------------------------

ftp mode passive
access-list inside extended permit tcp any any eq ftp
access-list inside extended permit tcp any any eq ftp-data
  inspect tftp
  inspect ftp

after carefully inspecting traffic I realized that if after connecting we manually specify the passive command before asking to send data all is well. however our software does not typically work like this and even running a manual FTP session over command line does not do this by default.

attached is a text file of the working connection and two packet captures showing the failure and success of both the ASA and PIX

anyone with any ideas?

[Kureli Sankar]

I remember I briefly looked at the capures a while ago but, forgot to post my comments.

I believe this could be only with ftp server.  Are you seeing ftp breaking for other ftp servers?

You can quickly download file zilla server as well as client. Put the server on the inside and use the client on a laptop from the outside and try to download files.  Do the other way around as well. This will prove if this is all ftp or just the one that you have trouble with.

Also make sure to issue this command and make sure ftp inspection will be hit when the inside server goes out to the outside ftp server.

sh service-pol flow tcp host i.i.i.i host o.o.o.o eq 21

where i.i.i.i is the inside server ip address

and o.o.o.o is the outside server ip address.

-KS

[jdlcisco1]

thanks for your reply. this does break on multiple FTP sites.

this is the result from the ASA

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Match: default-inspection-traffic
      Action:
        Input flow:  inspect ftp
    Class-map: class-default
      Match: any
      Action:
JDL#    Output flow:

________________________________________________________

from my PIX (which works 100%)

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Match: default-inspection-traffic
      Action:
        Input flow:  inspect ftp

___________________________________

does this look reasonable? also I have updated too just to be sure

Cisco Adaptive Security Appliance Software Version 8.2(3)
Device Manager Version 6.3(3)

[Kureli Sankar]

Very strange. I believe when you upgarded the code, the unit did get reloaded so, it fails even after a reload with proper ftp inspection con

figured to multiple ftp sites.  Very strange..

The fact that passive ftp works and active fails when the client is on the inside is even strange as the data connection will be initiated by the client on the high security interface going out to the ftp server which should be automatically allowed whether you have ftp inspection or not.

If you have an acl applied on the high security interface, try to remove that and see if this works.

http://slacksite.com/other/ftp.html - Active VS Passive ftp

-KS

[Kureli Sankar]

You mentioned passive ftp works but active fails.. correct? When the client is on the inside, we most certainly need ftp inspection configured and applied globally for active ftp to work. Passive will continue to work even without inspection when the client is on the higher security interface.

When active ftp fails - what do the logs show? Pls. copy and paste the syslogs.

-KS

[jdlcisco1]

I have mad bold 192.150.149.190 this is the external IP of the FTP server I am testing with

EDT: %ASA-session-6-302013: Built outbound TCP connection 2465375 for outside:192.150.149.190/21 (192.150.149.190/21) to inside:10.10.10.119/59475 (198.109.219.254/34350)

2010-08-24 14:02:19    Local4.Info    10.10.10.245    :Aug 24 14:02:19 EDT: %ASA-session-6-302013: Built outbound TCP connection 2465396 for outside:192.150.149.190/20 (192.150.149.190/20) to inside:10.10.10.81/11141 (198.109.219.254/11141)
2010-08-24 14:02:19    Local4.Info    10.10.10.245    :Aug 24 14:02:19 EDT: %ASA-session-6-302014: Teardown TCP connection 2465396 for outside:192.150.149.190/20 to inside:10.10.10.81/11141 duration 0:00:00 bytes 0 TCP Reset-I

2010-08-24 14:02:19    Local4.Info    10.10.10.245    :Aug 24 14:02:19 EDT: %ASA-session-6-302013: Built outbound TCP connection 2465398 for outside:192.150.149.190/20 (192.150.149.190/20) to inside:10.10.10.81/53462 (198.109.219.254/53462)
2010-08-24 14:02:19    Local4.Info    10.10.10.245    :Aug 24 14:02:19 EDT: %ASA-session-6-302014: Teardown TCP connection 2465398 for outside:192.150.149.190/20 to inside:10.10.10.81/53462 duration 0:00:00 bytes 0 TCP Reset-I
2010-08-24 14:02:19    Local4.Info    10.10.10.245    :Aug 24 14:02:19 EDT: %ASA-session-6-305012: Teardown dynamic UDP translation from inside:10.10.10.217/58840 to outside:198.109.219.254/48604 duration 0:00:30

2010-08-24 14:02:20    Local4.Info    10.10.10.245    :Aug 24 14:02:20 EDT: %ASA-session-6-302014: Teardown TCP connection 2436621 for outside:192.150.149.190/21 to inside:10.10.10.119/59148 duration 0:25:11 bytes 329 FIN Timeout

[Diego Armando Cambronero Arias]

What do you have connected directly in the inside of the firewall? a Router or a L2 switch.  Do you have a DMZ? have you tried to access the outside server from your DMZ?

Looks like something is resetting the tcp conn in ur inside -> TCP Reset-I

[Kureli Sankar]

%ASA-session-6-302014: Teardown TCP connection 2465396 for outside:192.150.149.190/20 to inside:10.10.10.81/11141 duration 0:00:00 bytes 0 TCP Reset-I

Reset-I means that the reset has come from the higher security interface (inside interface). Now, the client itself 10.10.10.81 or any other device like an L2 scanning device, websense can send a reset for these active IP connections.

The only way to get the MAC address that is sending the reset is by collecting captures on the ASA.

Since you are running 8.2.1 on the ASA capture can be done with the match key word.

Give this a shot.

cap capin int inside match tcp ho 10.10.10.81 ho 192.150.149.190 eq 20

Then try the active ftp and then issue

sh cap capin detail | i R

R - will get only the reset packets. The detail will get the mac address of the source.

Good luck.

-KS

[jdlcisco1]

Thank you so much for the help.

  2: 09:08:23.206074 d0d0.fdd4.3ca0 0026.9926.0d0e 0x0800 54: 10.10.10.81.50239   > 192.150.149.190.20: R [tcp sum ok] 0:0(0) ack 221915245 win 0 (DF) (ttl 63, id 0)
4: 09:08:23.974925 d0d0.fdd4.3ca0 0026.9926.0d0e 0x0800 54: 10.10.10.81.35193   > 192.150.149.190.20: R [tcp sum ok] 0:0(0) ack 3512670482 win 0 (DF) (ttl 63,id 0)

0026.9926.0d0e this is the mac address of the inside interface of the ASA the other mac is for my router which i dont think it could be because I have changed routers since the ASA has been put in. I figured this had to be the case but I just dont know how to tell it to play nice.. **SIGH**

thanks again I appriciate the knowledge

[Kureli Sankar · Accepted solution]

You are welcome. Now that I have helped rule the ASA out of the picture. Poor firewall it was not at fault after all.

All we know is that this d0d0.fdd4.3ca0 which is the router is sending the reset.  It may not be the router that is sending the reset. It may just be relaying the reset that is sent from some other source or the client it self if the client is not directly connected to the ASA.

Try a test from a client that is connected directly on the same inside subnet as the ASA's inside interface. Make the GW of the client as the ASA's inside interface. See if you still see the Reset and if so what is the mac address.  Configure no captures on the ASA for the new client IP.

Next thing to do this collect wireshark captures on the client it self when you do this active ftp test and see if the client is sending the reset or what the client sees during the reset.

-KS

[jdlcisco1]

thanks so much

you are right the ASA is doing just fine. I have a natting issue where if the ftp client is truly using passive ftp it works fine. if like you said it is using active the connection breaks. when tryint to set up the second connection it is trying to redirect the traffic to another server..and imagine that FTP works just fine from the that other location.

thanks for helping a new admin troubleshoot now im off to try and fix nat.

[Kureli Sankar]

Karl,

Both tcp 21 (for user ID and password)  and tcp 20 (data) are going to the same server according to the syslogs that you uploaded.  It is not going to a diff. server.

Anyway, seems like you know how to take it from here.  Good luck.  Pls. rate the posts that helped you.

-KS