- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-28-2014 02:20 AM
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
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
10-28-2014 05:25 AM
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
10-28-2014 05:37 AM
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
10-28-2014 06:00 AM
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
10-28-2014 06:36 AM
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
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!