FTP Data - Handshake is not estabilished

[rkra]

Hello,

we are struggling with this problem.

There is a FTP Client and an FTP Server. Both on different sites. Between them is a VPN Tunnel build with PA 3020 and PA 5020.

FTP is working - but sometimes not!!!!!

We found the reason for this:

This is what I can see at client's site

• Controlchannel (21) is UP
• Client asks "STOR myfile.txt"
• Datachannel Handshake starts, the last packet is WRONG!! Wrong Source AND destination Port:

SYN                Packet  218 Essen>Erfurt      Port 20 -> Port 64068
ACK                Packet  219 Erfurt>Erfurt       Port 64068 -> 20

SYN ACK         Packet  220 Essen>Erfurt     Port -> 21 -> 64067

Is it possible Palo Alto is little bit confused?

We are goint to trace on the server now ..

Roman

[HULK]

Hello Rkra,

In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20. But the entire  TCP 3 way handshake will complete in port 21, hence 20 will not ve a right port during initial connection establishment.

From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened or ALG to be enabled to perform this automatically ( Application Layer Gateway):

FTP server's port 21 from anywhere (Client initiates connection)

FTP server's port 21 to ports > 1023 (Server responds to client's control port)

FTP server's port 20 to ports > 1023 (Server initiates data connection to client's data port)

FTP server's port 20 from ports > 1023 (Client sends ACKs to server's data port)

When drawn out, the connection appears as follows:

In step 1, the client's command port contacts the server's command port and sends the command PORT 1027. The server then sends an ACK back to the client's command port in step 2. In step 3 the server initiates a connection on its local data port to the data port the client specified earlier. Finally, the client sends an ACK back as shown in step 4.

The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client--something that is usually blocked.

You may attach PCAP on all 4 places to troubleshoot it properly. Client, PA_320, PA-5020, Server.

Hope this helps.

Thanks

[rkra]

Hello Hulk,

I would like to repeat, it works ... but not every time.

I wrote a short batch to test the server, it is a small loop, this one repeats every 5 seconds.

The same problem is when configuring it passive OR active

If the loop repeats every 60 second, it works long time well ..

If the loop repeats every <5 second, the problem appears very soon ..

@echo off

:start

echo GO!

ftp -d -s:ftpcommands.txt>>.\ftp.log

timeout /T 5 /NOBREAK

goto start

and now the ftp commands file:

open 10.2.16.88

zgttest

password

put testfile.txt

bye

Roman

[HULK]

We may need to enable TCP flow-basic in order to identify the failure condition. But, would it be possible to set the repeat time >30 sec and let us know the result. Just to ensure that previous session has been closed and the same source port is not reused.

The default timeout value in a PAN firewall will be as mentioned below:

Session timeout

  TCP default timeout:                           3600 secs

  TCP session timeout before SYN-ACK received:      5 secs

  TCP session timeout before 3-way handshaking:    10 secs

  TCP session timeout after FIN/RST:               30 secs

  UDP default timeout:                             30 secs

  ICMP default timeout:                             6 secs

  other IP default timeout:                        30 secs

  Captive Portal session timeout:                  30 secs

  Session timeout in discard state:

    TCP: 90 secs, UDP: 60 secs, other IP protocols: 60 secs

Thanks

[hshah]

Hi Roman,

Based on problem complexity, solution needs lots of live troubleshooting and live captures. Which may not be possible on forum. Still we will try to help as much as possible.

Follow bellow steps for failure attempt.

1. show counter globlal filter packet-filter yes delta yes.

2. Lets say source is 1.1.1.1 and destination 2.2.2.2. Then put those values in filter and turn on filter and capture.

3. Once connection is fail repeat step 1. and provide us output.

4. Also provide us captures.

5. Disable capture first and than filter.

Regards,

Hardik Shah