FTP-server on non-standard port behind DNAT, client behind SNAT

FTP-server on non-standard port behind DNAT, client behind SNAT

[Покотиленко Костик]

I have proftpd-server with virtual hosts running on 21 and 3421 ports.
Both are masquerading to the public IP of a gateway/nat.

Gateway/nat running:
ip_conntrack_ftp ports=21,3421
ip_nat_ftp ports=21,3421

Using a client behind the SNAT I can connect to 21 and get directory
listing in passive mode, can connect to 3421 but CAN'T get directory
listing in passive mode.

Seems like ip_conntrack_ftp/ip_nat_ftp doesn't spy 3421 port. What can
be wrong? How to debug?

Directory listing on 21 goes well:

ftp> pass
Passive mode on.
ftp> ls
227 Entering Passive Mode (xxx,xxx,xxx,xxx,236,99).
150 Opening ASCII mode data connection for file list
[directory listings]
226 Transfer complete.
ftp>

When trying to get directory listing on 3421 I get:

ftp> pas
Passive mode on.
ftp> ls
227 Entering Passive Mode (xxx,xxx,xxx,xxx,157,8).
ftp: connect: Connection refused
ftp>

where xxx,xxx,xxx,xxx: public IP of gateway/nat of a FTP server.

Gateway/nat running Debian etch, recompiled standard kernel 2.6.18 with
some patches from patch-o-matic-ng and imq.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: FTP-server on non-standard port behind DNAT, client behind SNAT

[Pascal Hambourg]

Hello,

Pokotilenko Kostik a écrit :
> I have proftpd-server with virtual hosts running on 21 and 3421 ports.
> Both are masquerading to the public IP of a gateway/nat.
> 
> Gateway/nat running:
> ip_conntrack_ftp ports=21,3421
> ip_nat_ftp ports=21,3421
> 
> Using a client behind the SNAT I can connect to 21 and get directory
> listing in passive mode, can connect to 3421 but CAN'T get directory
> listing in passive mode.
> 
> Seems like ip_conntrack_ftp/ip_nat_ftp doesn't spy 3421 port. What can
> be wrong? How to debug?
> 
> Directory listing on 21 goes well:
> 
> ftp> pass
> Passive mode on.
> ftp> ls
> 227 Entering Passive Mode (xxx,xxx,xxx,xxx,236,99).
> 150 Opening ASCII mode data connection for file list
> [directory listings]
> 226 Transfer complete.
> ftp>
> 
> When trying to get directory listing on 3421 I get:
> 
> ftp> pas
> Passive mode on.
> ftp> ls
> 227 Entering Passive Mode (xxx,xxx,xxx,xxx,157,8).
> ftp: connect: Connection refused
> ftp>
> 
> where xxx,xxx,xxx,xxx: public IP of gateway/nat of a FTP server.

AFAIK, the public address in the reply to the PASV command means that 
ip_conntrack_ftp and ip_nat_ftp monitors the control connection on port 
3421 too, unless the server itself advertised the public address. Could 
it be the client-side SNAT which rejects the data connection ?

Re: FTP-server on non-standard port behind DNAT, client behind SNAT

[Покотиленко Костик]

В Вто, 11/11/2008 в 16:16 +0100, Pascal Hambourg пишет:
> Hello,
> 
> Pokotilenko Kostik a écrit :
> > I have proftpd-server with virtual hosts running on 21 and 3421 ports.
> > Both are masquerading to the public IP of a gateway/nat.
> > 
> > Gateway/nat running:
> > ip_conntrack_ftp ports=21,3421
> > ip_nat_ftp ports=21,3421
> > 
> > Using a client behind the SNAT I can connect to 21 and get directory
> > listing in passive mode, can connect to 3421 but CAN'T get directory
> > listing in passive mode.
> > 
> > Seems like ip_conntrack_ftp/ip_nat_ftp doesn't spy 3421 port. What can
> > be wrong? How to debug?
> > 
> > Directory listing on 21 goes well:
> > 
> > ftp> pass
> > Passive mode on.
> > ftp> ls
> > 227 Entering Passive Mode (xxx,xxx,xxx,xxx,236,99).
> > 150 Opening ASCII mode data connection for file list
> > [directory listings]
> > 226 Transfer complete.
> > ftp>
> > 
> > When trying to get directory listing on 3421 I get:
> > 
> > ftp> pas
> > Passive mode on.
> > ftp> ls
> > 227 Entering Passive Mode (xxx,xxx,xxx,xxx,157,8).
> > ftp: connect: Connection refused
> > ftp>
> > 
> > where xxx,xxx,xxx,xxx: public IP of gateway/nat of a FTP server.
> 
> AFAIK, the public address in the reply to the PASV command means that 
> ip_conntrack_ftp and ip_nat_ftp monitors the control connection on port 
> 3421 too, unless the server itself advertised the public address.

The server advertise the public address itself, it's proftpd with this
option:
<VirtualHost yyy.yyy.yyy.yyy>
  ...
  MasqueradeAddress xxx,xxx,xxx,xxx
  ...
</VirtualHost>

where yyy.yyy.yyy.yyy: privat IP.

> Could 
> it be the client-side SNAT which rejects the data connection ?

No, all outgoing connection are allowed. Moreover on port 21 data
connection port is within same range, so this is not the case.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: FTP-server on non-standard port behind DNAT, client behind SNAT

[Pascal Hambourg]

Pokotilenko Kostik a écrit :
> 
> The server advertise the public address itself, it's proftpd with this
> option:
> <VirtualHost yyy.yyy.yyy.yyy>
>   ...
>   MasqueradeAddress xxx,xxx,xxx,xxx
>   ...
> </VirtualHost>
> 
> where yyy.yyy.yyy.yyy: privat IP.

Couldn't this disrupt the FTP connection tracking which expects to see 
the private address ? This option should not be required, as ip_nat_ftp 
is able to translate addresses in the control flow.

Re: FTP-server on non-standard port behind DNAT, client behind SNAT

[Покотиленко Костик]

В Вто, 11/11/2008 в 20:15 +0100, Pascal Hambourg пишет:
> Pokotilenko Kostik a écrit :
> > 
> > The server advertise the public address itself, it's proftpd with this
> > option:
> > <VirtualHost yyy.yyy.yyy.yyy>
> >   ...
> >   MasqueradeAddress xxx,xxx,xxx,xxx
> >   ...
> > </VirtualHost>
> > 
> > where yyy.yyy.yyy.yyy: privat IP.
> 
> Couldn't this disrupt the FTP connection tracking which expects to see 
> the private address ? This option should not be required, as ip_nat_ftp 
> is able to translate addresses in the control flow.

You are extremely right :) That was the case, removing MasqueradeAddress
made it work!

I was unable to find the information on how does conntrack_ftp/nat_ftp
work, otherwise I 
would found out the right way.

Thanks alot, you saved my time.

P.S. Sorry, previous post acidently went privat

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: FTP-server on non-standard port behind DNAT, client behind SNAT

[Pascal Hambourg]

Pokotilenko Kostik a écrit :
> 
> You are extremely right :) That was the case, removing MasqueradeAddress
> made it work!

Glad it helped. However I wonder why it was working on port 21 and not 
on port 3421.

> I was unable to find the information on how does conntrack_ftp/nat_ftp
> work, otherwise I would found out the right way.

The source code is available. (just kidding)

The Netfilter conntrack/NAT helper is smart enough and does all the 
dirty job transparently so neither the client or server should bother 
about NAT issues. It monitors the control connection, translates the 
address and port information in it, translates and marks the data 
connections as RELATED, in both active and passive modes. All this 
assumes that the control connection is cleartext, not encrypted with 
SSL/TLS.

Note that if you want to use active mode on the non standard port from 
the masqueraded client, the SNAT device must be aware that this ports is 
used for FTP control connections. Most NAT devices handle FTP only on 
port 21.

Only when the NAT device is "dumb" (not FTP-aware) or encryption is used 
the masqueraded end must advertise the public address, reserve a port 
range for data connections and have this port range explicitly DNATed to 
its private address by the NAT device.