FTP Data connection broken, need help

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

FTP Data connection broken, need help

L3 Networker

ta, Im having a heck of a problem.

One zone out to an ftp server is working frie but from another zone the conputers can connect but they cant get file listings of xfer data ata ll. Routing is fine, obviously, the rules they are hitting is ok, NAT and Sec.

Both connections go through two VRs to get out to the ftp server. One zone hits two rules, the other only hits one.

Im running out of ideas of things to check.

Anyone else here have this problem in the past? What was the issue? Thanks.

1 accepted solution

Accepted Solutions

5.x:

set deviceconfig setting tcp asymmetric-path bypass bypass-exceed-oo-queue yes


Here are all the options under asymmetric-path:

admin@PA-200# set deviceconfig setting tcp asymmetric-path bypass

+ bypass-exceed-oo-queue   whether to skip inspection of session if out-of-order packets limit is exceeded

+ check-timestamp-option   whether to drop packets with invalid timestamp option

+ urgent-data              clear urgent flag in TCP header

  <Enter>                  Finish input

admin@PA-200#

prior versions:

set deviceconfig setting tcp asymmetric-path bypass  yes


This disables the sliding window and sequence number checking.  Looks like you are doing asymetric routing and the firewall is dropping tcp out of sequence packets.

Hope that helps.

-chadd.

View solution in original post

14 REPLIES 14

L3 Networker

oh and ive tried both passive and active connection types.

L5 Sessionator

Hi,

You can also do the following to see what might be causing the issue

1. Need to setup the filters for the traffic we are interested in. To do this, execute the following steps:

Navigate to Monitor--Packet Capture

Click 'Manage Filters'

Set Filter ID 1 to be the source IP and destination IP of traffic you feel is affected ( leave all other fields blank )

Set Filter ID 2 to be the exact inverse of what you did in step 3 (destination IP in source field, Source IP in destination field)

2. Setup up the captures

Create and name the file stage for a packet capture on all the stages (receive, transmit, firewall and drop)

3. Enable filters and captures

debug dataplane packet-diag set filter on

debug dataplane packet-diag set capture on

4. open 2 CLI windows

on 1 run the following command to look at the counter ( make sure it run this command once before running the traffic)

show counter global filter packet-filter yes delta yes

on the 2nd window run the following command to look at he sessions

show session all filter source <ip address> destination <ip address>

5. Now run the test for ftp while it is failing to look at the counters and captures and sessions to determine what is causing the issue.

6. Once you have finished testing and capturing. Make sure to turn off the debugs.

Hopefully this helps you resolve your issue.

Thank you

thanks very much, i will try that out asap.

thanks again, that worked, well just going to review the files.

btw, i guess the CMD line stuff is just to make sure its actually working/capturing as you test ..?

L3 Networker

You may also want to check the path of the FTP transfer that is not working, to make sure that the return path does not need a route between VRs.  If it does, you may need to add a route which says "Next VR", so the return traffic gets back.  Just a thought.  I like the suggestion from mbutt as well, that should point you in the right direction.

-chadd.

thanks for the reply,

im sure the routes are ok as i can always login to the ftp server just fine, its just everything stalls on the LIST command in one PA zone, but its fine in another.

I have the captures, there is about 30 packets in the drop pcap but they are from/to ips/ports that are allowed. I have to dig around a bit more.

so, ive got a pcap capture from one ftp connection out from our machine that does not work, and there are two dropped packets (see wireshark screen for example)

ftp 1.JPG

both packets dropped were 192.168.* -> 205.207.*:50046 (its reaching out to make the data connection via passive mode)

however the same type of packet that was dropped above, is also allowed (according to the PA logs).

ftp 2.JPG

FYI: the client PC that DOES work to this ftp server never reaches out to a random port for passive mode, doesnt even reach out to port 20, according to the logs.. it only reached out to port 21, or thats all i see anyways.

Not sure where to go from here.

When your packet filter is set up as mbutt recommended, run:

show counter global filter packet-filter yes delta yes

This will tell you why the packets are being dropped. Anything with a 'drop' message is an indication of what is happening. Just make sure to run that command once before the test starts to clear the counter stats.

From the screenshot, it shows a length of 0 on that packet, so I assume it is a SYN on that port. As long as the firewall is able to read the initial setup packets, and there's a rule allowing FTP, it will create a 'predict' session matching the chosen PASV port and allow that traffic.

What do you see from the global counter output?

-Greg

thanks, seems packets that are 'out of window' are being dropped.

only one link in forum i found

https://live.paloaltonetworks.com/message/14806#14806

maybe i could disable this ... function ..

im not sure what the window error is.

counter 1.JPG

5.x:

set deviceconfig setting tcp asymmetric-path bypass bypass-exceed-oo-queue yes


Here are all the options under asymmetric-path:

admin@PA-200# set deviceconfig setting tcp asymmetric-path bypass

+ bypass-exceed-oo-queue   whether to skip inspection of session if out-of-order packets limit is exceeded

+ check-timestamp-option   whether to drop packets with invalid timestamp option

+ urgent-data              clear urgent flag in TCP header

  <Enter>                  Finish input

admin@PA-200#

prior versions:

set deviceconfig setting tcp asymmetric-path bypass  yes


This disables the sliding window and sequence number checking.  Looks like you are doing asymetric routing and the firewall is dropping tcp out of sequence packets.

Hope that helps.

-chadd.

ok, thanks, im going to try turning that off then.

thank you sweet lord problem solved. thanks very much for all the help. man that was a doozey.

show counter global filter packet-filter yes delta yes

thats one hell of a command and im going to make sure i make good use of it in the furture.

Hello cchristiansen,

Its command could be applied after system rebooted? right? or applied immediately when commanding on CLI?

Thanks.

Regards,

Roh

You're in configure mode and it will work immediately as I know.And also it will stay after reboot.

  • 1 accepted solution
  • 13073 Views
  • 14 replies
  • 3 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!