[ previous ] [ next ] [ threads ]
 
 From:  "Neil Schneider" <pacneil at linuxgeek dot net>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] FTP NAT redux
 Date:  Sat, 28 Aug 2004 01:33:17 -0700 (PDT)
Fred Wright said:
>
> On Tue, 24 Aug 2004, Neil Schneider wrote:
>> Fred Wright said:
>> > On Fri, 20 Aug 2004, Neil Schneider wrote:
>> >>
> [...]
>> >> ip_contrack_ftp and ip_contrack_nat are "helper" modules
>> >> specifically
>> >> for NAT'ing FTP protocol. I believe, they track the port
>> connections
> [...]
>> > I think IPFilter handles this automatically for NAT but not for
>> the
>> > firewall, though this is based on using an active-mode client,
>> which
>> > is a
>> > similar but not identical case to the passive-mode server.
>> > Passive-mode
>> > clients and active-mode servers should have no trouble.  To open
>> > things up
>> > the rest of the way, you need to open the whole "ephemeral" port
>> range
>> > 49152-65535.  This may still not be enough if the server goes by
>> an
>> > older
>> > standard for the port range, but if you enable firewall logging
>> you
>> > can
>> > see what ports it's having trouble with.
>> >
>> > I don't think this has anything to do with "double NATting", other
>> > than
>> > that means there are *two* NAT layers that need to "get FTP
>> right".
>>
>> Well the testing I'm doing is from a system behind m0n0wall to and
>> ftp
>> server NAT'ed behind m0n0wall. I opened the "ephemeral" ports you
>> described, and still can't get a file listing. The client side is
>> regular masqerading NAT the server is Server NAT to a specific IP.
>> Clients with complaints are behind Linksys and other "DSL/Cable
>> Routers". The result is the same.
>
> Have you tried enabling logging for that and seeing if the data
> connections show up there?  If you're not sure of the port range, you
> could at least temporarily open 1024-65535 with logging.

I have not tried tcpdump, though the network is switched, so I may
have to make some adjustments.

> You could also use tcpdump (or I think there's a better tool called
> "tcpflow" or something that I've never used) to monitor the control
> connection to see what data port it's trying to use.
>
> Does it work in active mode?  Or is that a non-option due to NAT
> issues on
> the client side?

Doesn't seem to work in either active or passive mode, if the client
is behind a firewall.

>> Are you suggesting I need to Server NAT all those ports 49152-65535
>> ?
>
> It's possible, depending on whether NAT handles this case correctly on
> its
> own.  It would be "Inbound NAT", not "Server NAT", though.

Ok, I have been using Server Nat instead of 1:1 NAT. It's never been
clear to me what the significant difference is. Can you please
explain? I think I tried 1:1 NAT and it wasn't working for me, but I'm
willing to try again.


-- 
Neil Schneider                              pacneil_at_linuxgeek_dot_net
                                           http://www.paccomp.com
Key fingerprint = 67F0 E493 FCC0 0A8C 769B  8209 32D7 1DB1 8460 C47D

Fires can't be made with dead embers, nor can enthusiasm be stirred by
spiritless men. Enthusiasm in our daily work lightens effort and turns
even labor into pleasant tasks. --James Baldwin