Tugger the SLUGger!SLUG Mailing List Archives

RE: [SLUG] FW: FTP NAT/Conntrack problems

Title: RE: [SLUG] FW: FTP NAT/Conntrack problems

New info the topic:

On Thu, 17 May 2001, Luke McKee wrote:

> Can someone confirm that netfilter is doing this source ip check in the
> ftp_contrac module.

Yes, this is now checked by default with the 2.4.4 kernel.

> If this is so, could I request that there be a compile time define to not
> scrutinize the source ip address of incoming ftp data connections

If you need to allow these packets through (e.g. for load balancers etc),
use the new 'loose' parameter when loading the ip_nat_ftp module.

[Luke Mckee]: Correction the ip_conntrac_ftp module is the one that takes the loose option

- James
James Morris

SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
> -----Original Message-----
> From: Crossfire [mailto:xfire@xxxxxxxx]
> Sent: Thursday, May 17, 2001 1:44 PM
> To: Luke McKee
> Cc: 'slug@xxxxxxxxxxx'
> Subject: Re: [SLUG] FW: FTP NAT/Conntrack problems
> Luke McKee was once rumoured to have said:
> > Slug PPL,
> >
> > I thought I would mention this to the slug list. Sorry for
> the slightly off
> > topic posting earlier that was primarily directed towards
> netfilter users.
> >
> > Simply what I am trying to say is some Linux users running
> NAT in the
> > version in 2.4 kernel can not access some FTP sites that
> others can access
> > without trouble - because netfilter breaks RFCs. It even
> affects ftp client
> > running on the nat box itself so if you are running NAT
> there is nothing you
> > can do apart from login to another machine outside your
> private network or
> > shut down NAT completely to get to that FTP site.
> This is why FTP has passive mode.

Passive mode is where the client goes out and connects to the server to establish a ftp data stream. Yes it solves the MASQ problem but not when servers are in a cluster behind a simple firewall.

In our instance and likely in MOST others passive mode will not work.
Not all ftp servers that are behind a load balancer or firewall can have incoming connections permitted - i.e. bind on the firewalls IP - most servers in a load balanced array are behind a firewall. Therefore passive mode WILL NOT WORK.

Remember not all firewalls SNAT or MASQ and or have them on by default.

So if you are paranoid about security leave netfilter with the default setting, if you are concerned about compatibility with what's out there on the internet (like programmers like Dan Bernstein are not) you should compile the ftp_conntrac as a module and use the loose=1 option.

> > The ftp servers you can't connect to with NAT running are
> FTP servers that
> > send file transfers from a different IP to the one you
> first connected to.
> > Servers that do this are commonly found in
> High-Availability networks (like
> > those running high-availability Linux clusters -
www.linux-ha.org). I just
> thought I should let you all know this in case anyone else have been having
> problems with FTP on linux.


> I now agree with Cris' comment on the slug home page:
> "Unfortunately, whilst everyone was impressed with Netfilter, and Chris's
> overview of it, no one was willing to entrust a production firewall to Linux
> 2.4. Perhaps around 2.4.10"

>This was *NOT* my comment[2].  I use Netfilter at home, and I'm about to
>deploy it into production.

>The NAT code in Netfilter is *far* better than the old Masq system in
>2.2 in terms of flexibility.

>You obviously didn't research this very well before jumping to
>conclusions, and I do not appreciate being misrepresented.

Excuse me I only cut and pasted from the website and say I agree with it. I didn't think I was likely
to stuff up doing such a menial exercise. I should have relised you didn't say it - look at least I said
where I got the source from. Baah - what an ego.... rub it in good.

I say NO to the claim that I did not research what I wrote fully. I just spend the last day researching this topic trying to find out why some ftp sites didn't work with our implementation of netfilter + nat. Tested a hypothesis and found out it was correct from the developers on the netfilter mailing list. Then I suggested a fix - only to find out it already existed 5 minutes ago.

Well I could have hacked / looked at the code but seeing I'm not an elitist or a big code hacker like yourself I just did a couple of postings to the netfilter-users mailing list. Just calm down and stop flaming fellow Linux "users" - if you don't find them fellow you don't need to tell the whole world that.

I didn't go on bragging that Winroute Pro works and Linux doesn't didn't I? so I don't deserve a hiding from you ;_) or any other Linux users I tried to help with this tip that I found in my travels and experience :-).

If your not happy being on a linux USERS list nobody is forcing you to stay subscribed to it. Yes most linux users should hack the code and contribute and not RELY on other people time for support but it doesn't say anywhere that linux users have to be code hackers. Ignorance is bliss (till I go to Uni next year at least :-)

See ya,



>[1] Hack the Source Luke.  They even tell you what changes you'd need
    to make.

>[2] For the unaware, he's lifted the comment from Jeff's report on the
    last meeting.  These were Jeff's words, not mine.

>[3] Yes, the C. stands for Chris, not for Crossfire.
>  Crossfire      | This email was brought to you
>  xfire@xxxxxxxx | on 100% Recycled Electrons

>SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
>ore Info: http://lists.slug.org.au/listinfo/slug