Troubleshooting guide

Chapter 7 Troubleshooting Security Servers and Content Security
Resolving Common FTP security server problems
Advanced Technical Reference Guide 4.1 • June 2000 68
2626 AP-Defender, AT-Defender
2649,2651 IIOP
2998 RealSecure
5190 AOL
5510 SecurID-prop
5631 PCanywhere
6000-6063 X11
6499 IS411
6660-6670 IRC
7000 IRC2
7070 RealAudio
12468-12469 WebTheater
16384 ConnectedOnline
18181-18184 CVP, UFP, SAM, LEA
18187 ELA
See the SecureKnowledge Solution (ID: 47.0.707710.2521144) in the Check Point Technical Services site
Allowing FTP data connections through the FireWall on random ports
VPN-1/FireWall-1 by default assumes data connection coming from port 20.
See the SecureKnowledge Solution (ID: 10022.0.714865.2422686
) in the Check Point Technical Services site
Port command must end with a new line
VPN-1/FireWall-1 expects to receive the PORT command with /r/n at the end
You can change this behavior by changing the INSPECT code.
See the SecureKnowledge Solution (ID: 36.0.152763.2473228
) in the Check Point Technical Services site
Bi-directional FTP Data connection are not allowed
Unlike the FTP Control connection that is a bi-directional connection, the DATA connection is unidirectional.
One side sends ACK packets and the other side sends DATA packets. VPN-1/FireWall-1 always forbids bi-
directional commands because they are considered to be insecure.
FTP servers that allow bi-directional FTP connections allow FTP data connections from random ports on FTP
servers.
VPN-1/FireWall-1 imposes unidirectional data transfer on connections opened via the port or the PASV
command in the FTP protocol
Fast mode and FTP
Since VPN-1/FireWall-1 has to inspect each packet in order to understand the port command and thereby opens
only the relevant port for the data connection, FAST mode is not supported with FTP.
See the SecureKnowledge Solution (ID: 10000.0.1236618.2339349
) in the Check Point Technical Services site
FTP connections hang during large file transfers
It appears that when a packet comes through that is just a little bit less than the MTU size, the FireWall will
accept it. But then the FireWall adds it's data to the packet, which makes it larger than the MTU threshold and it
is dropped. The packet is resent and is accepted and then dropped again for the same reason. This becomes an
endless loop and the connection appears to freeze.