back to focus: attached is my patch for ip_masq_ftp (should apply cleanly
to 2.2.17, read patch header for changes) and a script to setup the modules.
Please give it a test and tell me...

Best regards

Juanjo

--

Date: Thu, 5 Oct 2000 11:34:17 -0300
From: Juanjo Ciarlante <jjo@mendoza.gov.ar>
To: David Ranch <dranch@trinnet.net>
Subject: Re: ip_masq_ftp status
X-Mailer: Mutt 0.95.4us


On Wed, Oct 04, 2000 at 11:11:33PM -0700, David Ranch wrote:
 >  >Attached is latest patch _and_ script to use this stuff, please
 >  >give a try (and post it)
 >  >   BTW this script setups also a user-space redirector "redir" to
 >  >   cope with local/localnet redirections.
 >
 > Could you elaborate on this "redir" tool?  Is this really
 > a required tool in addition to ipmasqadm or the likes?
This is what is do call the "NATriangle" problem (described below)
and it's not related to linux's nat/ipmasq.


 > And feedback from previous patch?
 > Some.. some people haven't been able to get it to work and
I guess my poor docs hurt too much ... I'm trying to revert this
(with your unvaluable help!) , that why I created rc.masqfw ...


 > I plan on testing it this weekend.
GREAT!


Regards...
Juanjo


---NATriangle problem---
For NAT configs to work packet flow _MUST_ cross the firewall
in _both_ directions (in-out and out-in).
See:
                 /-<-- [ O ]                (outside host)
               /         :
            [ F ]        ^                   (firewall)
               \         :
                `-->-- [ I ]                (inside host)


for masq:
      host      traffic-flow       "netstat -n, socket state"
        I        I->F->O           I-O      I sees end-to-end netstat
        O        O->F->I           O-F      O sees him-to-firewall

For portfw  the problem is when some  "O" (client, _now_ internal)
connects to "F" when "I" (server) is in  _SAME_SUBNET_ as "O"


"O" sends initial packet:
    from "O":                               O -> F        [SYN     ]   <===+
    firewall rewrite, sends to "I":         O -> I        [SYN     ]       |
                                                                        (DIFF!)
"I" sees packet from "O", so it responds                                  |
    from "I":                               I -> O        [SYN  ACK]   <===+


Now you see:
       "O" receives packet _directly_from_ "I" (dotted line in diagram) and
       he has _never_ sent to "I" (previous packet was sent to "F"!!)

This happens because the response didn't pass via "F".


SOLUTION: (as in rc.masqfw)


    If packet is "truly" from outside (ipchains rules) then
          /* packet will be intercepted by ip_masq_mfw */
          do masq forward

    else
          /* packet will go "up-stack" as normal */
          do redir, thus creating TWO connections:    O-F and F-I

Hope this helps...

--