Novell Home

BorderManager and FTP

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 6 Jan 2003
 

There's been a lot of interest in how to use BorderManager and various FTP products together. Here are some useful notes from Novell Consultant Martin Day. Also, Fred Rang shares a script he developed to help WSFTP go through a BorderManager server. If you have any additional ideas, please send them our way.

Martin Day

From the RFC

  • Control commands always go from the client to the FTP server from high ports to port 21.
  • Generally, it is the server's responsibility to maintain the data connection -- to initiate it and to close it.
  • Only the client may initiate the use of non-default data ports.
    • Data transfer has a default method that ALL FTP servers should support.
    • The user default port is the same as that used for the control connection.
    • The server default port is port 20.
  • With the passive data transfer process, the client listens on its data port and the server INITIATES the connection.
  • ACTIVE - If the client issues a PORT command, this tells the server that the client is listening on a non-default port (another high port than that used with the control connection). Note, the server still INITIATES the data connection to the user port indicated by the PORT command. The source port will still be port 20 on the server.
  • PASSIVE - If the client issues a PASV command, this tells the server to identify a non-default server side data port. The server responds to this request by telling the client which port it is LISTENING on. Note, the server does NOT initiate the comms.
  • Both PORT and PASV can be combined. It also means that a client can cause data to be sent between two FTP servers by issuing a PORT command to one and a PASV command to another. These commands include the IP address.

FTP Through Novell NAT

NAT performs special processing to allow FTP to function properly when a client is on the private side and a server is on the public side. In dynamic mode, NAT supports all FTP requests (PASV, PORT) when going from the private to the public network. Normally, NAT would disturb this process (see details in RFC 1579 for more information on the problem). However, in this ONE instance, Novell's NAT will look inside the data portion of the PORT command packet and translate the private address (and port, if dynamic NAT is being used), thus allowing the public server to make it's data connection back to the private client. This is the ONLY scenario in which Novell's NAT translates information within the data portion of a packet. Without this feature, the public server would be given the client's private address, but not be able to route to it.

There is another concern with FTP and NAT. It occurs when a public client is trying to reach a private FTP server. NAT is running in static mode to allow connection to the server via a static mapping. In this scenario, if the client is set up to make a 'passive open', the session will fail. Passive mode causes the server to send data to client containing the address and port number which the client should use to establish the data connection. This data (unlike the PORT data in the example above) does NOT get translated, therefore the attempted connection fails.

Using WS_FTP Pro (version 6.01)

It is probably best to change the delimiter in nwadmn32 to be @ rather than $.

Using WS_FTP Pro Through Filters

If using FTP through a corporate firewall then be aware that the default action for data transfer is to use the PORT command. This means that the FTP server must initiate a data connection (for ls commands etc.) to an internal high port on the client. Two problems:

  • The firewall probably won't allow an external host to talk to an internal high port. FW-1 stateful inspection will probably open the required port as it reads the data in the PORT command.
    • With BM, if use ftp-pasv-st then the control session will happen but a data channel won't be setup. Can configure WS_FTP Pro to use passive, in which case this filter will work.
    • With BM, if use ftp-port-st then WS_FTP Pro works fine by default. If it has been configured to use passive data transfer then the data transfer will fail.
    • With BM, if use ftp-port-pasv-st, WS_FTP Pro works fine with PORT and PASV data transfers.
  • The NAT implementation at the firewall must allow this to happen. Our BM NAT does read the PORT command and so allow the data channel through NAT by doing the required mapping. PASV is straight forward as it is the client that initiates the data connection.

Using WS_FTP Pro Through BM FTP Proxy with No Authentication

  • The Use Firewall option should be ticked.
  • The Host Name should be the IP address of the FTP proxy.
  • User ID and Password fields should be blank.
  • Firewall Type should be ?USER with no logon?.
  • It does not matter if PORT or PASV commands are issued -- both work.
    (Apparently it is only the comms between the proxy and the destination that CANNOT use the PORT command.)

Using WS_FTP Pro Through BM FTP Proxy with Authentication Enabled

  • No pre-configured options for the Firewall Type provide the BM proxy with the parameters in the correct order.
  • For EACH destination ftp site it is necessary to manually configure WS_FTP Pro with all credentials for the BM FTP proxy and the destination FTP server.
  • Disable the firewall tab.
  • Under General tab:
    • Host Name/Address -- enter IP address of BM FTP proxy.
    • User ID -- enter ndsuser@ftpuser@ftpserver (NO leading dot)
      E.g. jbloggs@acme@anonymous@ftp.novell.de
    • Password -- enter ndspassword@ftppassword
  • It does not matter if PORT or PASV commands are issued -- both work.

Other Suggestions

Fred Rang

I've been fighting with WSFTP Pro and BorderManager to get them to work together. After working in Firescript editor (which comes with WSFTP), I was able to create a script that works "properly" with WSFTP going through a BorderManager server.

I wish I could have read this up here instead of having to do it myself. But now I'd like to share what I have.

Here's the script I used.

[fwsc]
author=CoolSolutions
version=1
verdate=2002.12.10
required=FwUserId,FwPassword,HostUserId,HostPassword,HostAddress
connectto=firewall

[comment]

[script]

tryssl; 

label loginhost;
send ("USER %FwUserId@%HostUserId@%HostAddress") 
{
	case (200..299) :
		jump success;

	case (300..399) :
		continue;

	case any :
		return (false);
}

// if an autodetect is possible anywhere, it would be here

send ("PASS %FwPassword@%HostPassword")
{
	case (200..299) and contains(lastreply, "ACCOUNT") 
	and not isempty(HostAccount) :
		continue;

	case (300..399) :
		continue;

	case (200..299) :
		jump success;

	case (530) :
		reask(hostpassword, hostuserid, fwpassword, fwuserid);
		jump loginhost;

	case any :
		return (false) ;
}

send ("ACCT %HostAccount")
{
	case (200..299) :
		jump success;

	case (530) :
		reask(hostaccount, hostpassword, hostuserid, 
		fwpassword, fwuserid);
		jump loginhost;

	case any:
		return (false);
}

label success;
gossl;
return (true);

If you have any questions you may contact Fred at Fred.Rang@Noa.Nintendo.Com


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell