-----Original Message-----
From: Fuzzy Fox <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, September 17, 1998 2:41 AM
Subject: Re: [masq] [masq] For my own edification...
>Jose M. Sanchez <[EMAIL PROTECTED]> wrote:
>>
>> 4) Why passive FTP will NOT work for me using MASQ, from a WEB browser,
when
>> the FTP module is loaded, (port FTP access, from a client program work
just
>> fine!, Web browsers work fine too, when the ftp module is NOT loaded!)
>
>You have mentioned this before, and it makes very little sense, because
>in a PASV ftp connection, the client makes all the connection attempts
>outwards, so there's no reason for the masq module to get involved.
>
Yes I realized this, but at the same time whenever the FTP module is loaded
the PASV connection fails. Tracing reveals that the response does return
from the remote but does not get forwarded to the client if the module is
loaded (on my weird configuration...).
>> This last problem has been driving me into a "crusade" to solve
>> this... I believe it is directly related to the inability of MASQ,
>> FTP module to handle reception of PASV packets on the SAME IP as that
>> it is transmitting on, and should be curable (thanks to the hints this
>> discussion has resulted in) by using aliased IPs...
>
>Well, I don't know about that, but I did dig into the source for the
>ip_masq_ftp module, and found this interesting (if cryptic) comment:
>
> /*
> * Look at incoming ftp packets to catch the response to a PASV
> * command. When we see one we build a masquerading entry for the
> * client address, client port 0 (unknown at the moment), the server
> * address and the server port. Mark the current masquerade entry
> * as a control channel and point the new entry at the control
> * entry. All this work just for ftp keepalive across masquerading.
> *
> * The incoming packet should be something like "227 Entering
> * Passive Mode (xxx,xxx,xxx,xxx,ppp,ppp)". xxx,xxx,xxx,xxx is the
> * server address, ppp,ppp is the server port number. ncftp 2.3.0
> * cheats by skipping the leading number then going 22 bytes into
> * the data so we do the same. If it's good enough for ncftp then
> * it's good enough for me.
> *
> * In this case, the client is the source machine being masqueraded,
> * the server is the destination for ftp requests. It all depends
> * on your point of view ...
> */
>
This indicates that the module is indeed "doing something" with the inbound
packets (where my problem is), what I need to do is to turn on debugging and
watch what is actually occuring...
-JMS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
