Passive FTP sees remote's _internal_ IP!!??

Passive FTP sees remote's _internal_ IP!!??

[gypsy]

William Lima wrote:
> 
> Dear,
> 
> Load modules:
> 
> modprobe ip_nat_ftp
> 
> Abs,

Nope:

#!/bin/bash
modprobe ip_nat_ftp
iptables -P FORWARD ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
68.171.136.91
iptables -A FORWARD -j LOG

Module                  Size  Used by    Not tainted
ipt_LOG                 3448   1  (autoclean)
iptable_filter          1772   1  (autoclean)
ip_conntrack_ftp        3728   1  (autoclean)
ip_nat_ftp              2640   0  (unused)
iptable_nat            17542   2  [ip_nat_ftp]
iptable_mangle          2168   0  (autoclean) (unused)
ip_tables              11840   6  [ipt_LOG iptable_filter iptable_nat
iptable_mangle]

Nov 26 17:20:35 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61924 DF PROTO=TCP
SPT=2105 DPT=2336 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 17:20:36 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61951 DF PROTO=TCP
SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 17:20:39 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61957 DF PROTO=TCP
SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 17:20:45 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61958 DF PROTO=TCP
SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0 

We don't think this is a netfilter problem.  The kernel should tell the
remote end that it can't use the "nonroutable" IP - shouldn't it?
--
gypsy

> 2006/11/26, gypsy <gypsy@iswest.com>:
> > In our network, we have 2 gateways.  The main GW is a Slackware 10.0 box
> > and the other is a SonicWALL firewall appliance.  Each connects to a
> > different external IP but both are in the same /29 network.
> >
> > Note: No machine in our LAN has an IP of 192.168.1.11.
> >
> > When the default GW is set to the linux box (192.168.223.254) and
> > passive FTP to a remote server is initiated, the FTP fails after
> > connection because the internal IP of the remote machine (192.168.1.11)
> > is seen rather than its external IP.  This problem occurs only when
> > passive FTP is used.
> >
> > We do not believe that the OS or FTP daemon of the remote host matters
> > because when the default GW is set to the SonicWALL (192.168.223.1), the
> > passive FTP succeeds.
> >
> > Therefore, we conclude that there is something wrong with our linux box.
> >
> > But WHAT?
> >
> > Note that the connection has already occurred when port negotation is
> > attempted - which is when the FTP fails.
> >
> > If anyone has advice, we will sincerely appreciate it.
> >
> > The kernel is 2.4.32.
> >
> > #!/bin/bash
> > iptables -P FORWARD ACCEPT
> > iptables -P INPUT DROP
> > iptables -P OUTPUT DROP
> > iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
> > 68.171.136.91
> > iptables -A FORWARD -j LOG
> >
> > Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56473 DF PROTO=TCP
> > SPT=1069 DPT=1090 WINDOW=60352 RES=0x00 SYN URGP=0
> > Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56500 DF PROTO=TCP
> > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > Nov 26 00:32:14 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56506 DF PROTO=TCP
> > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > Nov 26 00:32:20 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56507 DF PROTO=TCP
> > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > --
> > gypsy
> >
> >
> 
> --
> William R. Lima
> wrochalima@linuxit.com.br

Re: Passive FTP sees remote's _internal_ IP!!??

[David Sims]

Hi,

http://slacksite.com/other/ftp.html

Dave
********************************************************************
On Mon, 27 Nov 2006, gypsy wrote:

> William Lima wrote:
> >
> > Dear,
> >
> > Load modules:
> >
> > modprobe ip_nat_ftp
> >
> > Abs,
>
> Nope:
>
> #!/bin/bash
> modprobe ip_nat_ftp
> iptables -P FORWARD ACCEPT
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
> 68.171.136.91
> iptables -A FORWARD -j LOG
>
> Module                  Size  Used by    Not tainted
> ipt_LOG                 3448   1  (autoclean)
> iptable_filter          1772   1  (autoclean)
> ip_conntrack_ftp        3728   1  (autoclean)
> ip_nat_ftp              2640   0  (unused)
> iptable_nat            17542   2  [ip_nat_ftp]
> iptable_mangle          2168   0  (autoclean) (unused)
> ip_tables              11840   6  [ipt_LOG iptable_filter iptable_nat
> iptable_mangle]
>
> Nov 26 17:20:35 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61924 DF PROTO=TCP
> SPT=2105 DPT=2336 WINDOW=60352 RES=0x00 SYN URGP=0
> Nov 26 17:20:36 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61951 DF PROTO=TCP
> SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0
> Nov 26 17:20:39 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61957 DF PROTO=TCP
> SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0
> Nov 26 17:20:45 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61958 DF PROTO=TCP
> SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0
>
> We don't think this is a netfilter problem.  The kernel should tell the
> remote end that it can't use the "nonroutable" IP - shouldn't it?
> --
> gypsy
>
> > 2006/11/26, gypsy <gypsy@iswest.com>:
> > > In our network, we have 2 gateways.  The main GW is a Slackware 10.0 box
> > > and the other is a SonicWALL firewall appliance.  Each connects to a
> > > different external IP but both are in the same /29 network.
> > >
> > > Note: No machine in our LAN has an IP of 192.168.1.11.
> > >
> > > When the default GW is set to the linux box (192.168.223.254) and
> > > passive FTP to a remote server is initiated, the FTP fails after
> > > connection because the internal IP of the remote machine (192.168.1.11)
> > > is seen rather than its external IP.  This problem occurs only when
> > > passive FTP is used.
> > >
> > > We do not believe that the OS or FTP daemon of the remote host matters
> > > because when the default GW is set to the SonicWALL (192.168.223.1), the
> > > passive FTP succeeds.
> > >
> > > Therefore, we conclude that there is something wrong with our linux box.
> > >
> > > But WHAT?
> > >
> > > Note that the connection has already occurred when port negotation is
> > > attempted - which is when the FTP fails.
> > >
> > > If anyone has advice, we will sincerely appreciate it.
> > >
> > > The kernel is 2.4.32.
> > >
> > > #!/bin/bash
> > > iptables -P FORWARD ACCEPT
> > > iptables -P INPUT DROP
> > > iptables -P OUTPUT DROP
> > > iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
> > > 68.171.136.91
> > > iptables -A FORWARD -j LOG
> > >
> > > Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56473 DF PROTO=TCP
> > > SPT=1069 DPT=1090 WINDOW=60352 RES=0x00 SYN URGP=0
> > > Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56500 DF PROTO=TCP
> > > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > > Nov 26 00:32:14 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56506 DF PROTO=TCP
> > > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > > Nov 26 00:32:20 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56507 DF PROTO=TCP
> > > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > > --
> > > gypsy
> > >
> > >
> >
> > --
> > William R. Lima
> > wrochalima@linuxit.com.br
>

RE: Passive FTP sees remote's _internal_ IP!!??

[Maxime Ducharme]

 

This is "normal" FTP behavior

Problem is caused by the machine that handles NAT,
it doesnt translate passive FTP replies so it won't
handle passive FTP connections neither.

This happens when the remote server has a bad
NAT configuration for FTP. If the FTP server is
bound on another port than 21 this is common problem.

This is also why you see outbound access to 192.168.1.11
on dynamic ports. On the first line of your log we see that
192.168.223.4 try to get onto 192.168.1.11:1090, means
the FTP server isnt configured properly

Maybe SonicWALL is able to "fix" this itself, I dont
know this product very well.

Loading ip_nat_ftp on your side will only help
for active FTP connection, or if you run a FTP
server which IP is NATed (inside your 192.168.223.* net).

some suggestions :

1. Fix NAT for FTP on remote firewall

2. Configure remote server to explicitly send
external IP for passive connections (most of FTP
software allows to configure this)

3. Configure your FTP client to use active mode.
If server is running on another port than 21,
you must tell ip_nat_ftp to "listen" for FTP
traffic on this port. Someone on this list can
tell us how ? (I dont remember how)

4. Configure your FTP client to explicitly send
your external IP in active connections (PORT commands)
and configure iptables to forward any connections from
the FTP server to the internal IP which have the client
running. This is the worst solution.

Like David Sims I suggest
http://slacksite.com/other/ftp.html

HTH

Maxime Ducharme

 

-----Message d'origine-----
De : netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] De la part de gypsy
Envoyé : 27 novembre, 2006 10:33
À : netfilter@lists.netfilter.org
Objet : Passive FTP sees remote's _internal_ IP!!??

William Lima wrote:
> 
> Dear,
> 
> Load modules:
> 
> modprobe ip_nat_ftp
> 
> Abs,

Nope:

#!/bin/bash
modprobe ip_nat_ftp
iptables -P FORWARD ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
68.171.136.91
iptables -A FORWARD -j LOG

Module                  Size  Used by    Not tainted
ipt_LOG                 3448   1  (autoclean)
iptable_filter          1772   1  (autoclean)
ip_conntrack_ftp        3728   1  (autoclean)
ip_nat_ftp              2640   0  (unused)
iptable_nat            17542   2  [ip_nat_ftp]
iptable_mangle          2168   0  (autoclean) (unused)
ip_tables              11840   6  [ipt_LOG iptable_filter iptable_nat
iptable_mangle]

Nov 26 17:20:35 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61924 DF PROTO=TCP
SPT=2105 DPT=2336 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 17:20:36 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61951 DF PROTO=TCP
SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 17:20:39 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61957 DF PROTO=TCP
SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 17:20:45 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61958 DF PROTO=TCP
SPT=2106 DPT=2337 WINDOW=60352 RES=0x00 SYN URGP=0 

We don't think this is a netfilter problem.  The kernel should tell the
remote end that it can't use the "nonroutable" IP - shouldn't it?
--
gypsy

> 2006/11/26, gypsy <gypsy@iswest.com>:
> > In our network, we have 2 gateways.  The main GW is a Slackware 10.0 box
> > and the other is a SonicWALL firewall appliance.  Each connects to a
> > different external IP but both are in the same /29 network.
> >
> > Note: No machine in our LAN has an IP of 192.168.1.11.
> >
> > When the default GW is set to the linux box (192.168.223.254) and
> > passive FTP to a remote server is initiated, the FTP fails after
> > connection because the internal IP of the remote machine (192.168.1.11)
> > is seen rather than its external IP.  This problem occurs only when
> > passive FTP is used.
> >
> > We do not believe that the OS or FTP daemon of the remote host matters
> > because when the default GW is set to the SonicWALL (192.168.223.1), the
> > passive FTP succeeds.
> >
> > Therefore, we conclude that there is something wrong with our linux box.
> >
> > But WHAT?
> >
> > Note that the connection has already occurred when port negotation is
> > attempted - which is when the FTP fails.
> >
> > If anyone has advice, we will sincerely appreciate it.
> >
> > The kernel is 2.4.32.
> >
> > #!/bin/bash
> > iptables -P FORWARD ACCEPT
> > iptables -P INPUT DROP
> > iptables -P OUTPUT DROP
> > iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
> > 68.171.136.91
> > iptables -A FORWARD -j LOG
> >
> > Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56473 DF PROTO=TCP
> > SPT=1069 DPT=1090 WINDOW=60352 RES=0x00 SYN URGP=0
> > Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56500 DF PROTO=TCP
> > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > Nov 26 00:32:14 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56506 DF PROTO=TCP
> > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > Nov 26 00:32:20 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> > DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56507 DF PROTO=TCP
> > SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> > --
> > gypsy
> >
> >
> 
> --
> William R. Lima
> wrochalima@linuxit.com.br

Re: Passive FTP sees remote's _internal_ IP!!??

[Pascal Hambourg]

Hello,

Maxime Ducharme a écrit :
> This happens when the remote server has a bad
> NAT configuration for FTP.

I fully agree, the problem seems to be on the server side.

> Maybe SonicWALL is able to "fix" this itself, I dont
> know this product very well.

If it does so, I'd be happy to know how.

> some suggestions :
> 
> 1. Fix NAT for FTP on remote firewall
> 
> 2. Configure remote server to explicitly send
> external IP for passive connections (most of FTP
> software allows to configure this)
> 
> 3. Configure your FTP client to use active mode.
> If server is running on another port than 21,
> you must tell ip_nat_ftp to "listen" for FTP
> traffic on this port. Someone on this list can
> tell us how ? (I dont remember how)

$ modprobe ip_conntrack_ftp ports=21,alternate_port
$ modprobe ip_nat_ftp ports=21,alternate_port

Both commands are needed because AFAIK, ip_nat_ftp loads automatically 
ip_conntrack_ftp if not already loaded but does not pass the port list 
to it. Duh.

3b. Use extended passive mode (EPSV) if the client, the remote server 
and their firewall/NATs support it, because an EPSV reply does not 
contains the server address.

[Read on]
> -----Message d'origine-----
> De : netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org] De la part de gypsy
> Envoyé : 27 novembre, 2006 10:33
> À : netfilter@lists.netfilter.org
> Objet : Passive FTP sees remote's _internal_ IP!!??
> 
> We don't think this is a netfilter problem.

I agree, at least not on the client side.

> The kernel should tell the
> remote end that it can't use the "nonroutable" IP - shouldn't it?

No, the kernel is not supposed to do this. All the Netfilter FTP NAT 
helper module can do is translate "internal" addresses. However the 
wrong PASV reply comes from the outside.

>>>When the default GW is set to the linux box (192.168.223.254) and
>>>passive FTP to a remote server is initiated, the FTP fails after
>>>connection because the internal IP of the remote machine (192.168.1.11)
>>>is seen rather than its external IP.  This problem occurs only when
>>>passive FTP is used.

Does this happen with any FTP server or only a specific one ?

Re: Passive FTP sees remote's _internal_ IP!!??

[gypsy]

Pascal Hambourg wrote:
> 
> Hello,
> 
> Maxime Ducharme a écrit :
> > This happens when the remote server has a bad
> > NAT configuration for FTP.
> 
> I fully agree, the problem seems to be on the server side.
> 
> > Maybe SonicWALL is able to "fix" this itself, I dont
> > know this product very well.
> 
> If it does so, I'd be happy to know how.

SonicWALL does fix this, and we also would REALLY like to know how!!  At
the present time, our only "solution" is to reconfigure the clients to
gateway to the SonicWALL because everyone's browser only does passive
FTP.

> Does this happen with any FTP server or only a specific one ?

It happens with more than one server, but as far as I can tell, all
Unix/Linux/*BSD FTP servers work; only MS Windows servers seem to fail. 
But because of the success with the SonicWALL, it does not seem likely
that getting a remote site to change (or even look at) their setup will
ever happen.

SPECULATION:  In a google search for FTP servers, much comes up about
configuring IIS FTP, so perhaps it is a difficult thing to do, and
therefore it often is done wrongly.

Could it be worthwhile to run an FTP proxy such as
http://www.mcknight.de/jftpgw/jftpgw-0.13.4.tar.gz ?
--
gypsy

RE: Passive FTP sees remote's _internal_ IP!!??

[Maxime Ducharme]

> SonicWALL does fix this, and we also would REALLY like to know how!!  At
> the present time, our only "solution" is to reconfigure the clients to
> gateway to the SonicWALL because everyone's browser only does passive
> FTP.

I have an idea on how SonicWALL fix this, maybe it
is programmed to detect badly configured FTP replies
and correct them itself by replacing the PASV x.x.x.x
command with the source IP found in the IP packet

something like :

if ip.sourceIP != ftp.reply.passiveIP then
  ftp.reply.passiveIP = ip.sourceIP

I dont think iptables can do that, correct me if i'm wrong

I see you got a workaround, happy to hear this :)

Have a nice day

Maxime

Re: Passive FTP sees remote's _internal_ IP!!??

[Pascal Hambourg]

gypsy a écrit :
> 
>>Does this happen with any FTP server or only a specific one ?
> 
> It happens with more than one server, but as far as I can tell, all
> Unix/Linux/*BSD FTP servers work; only MS Windows servers seem to fail.

And all the faulty servers send the same address 192.168.1.11 ?
If so, and if these servers are public, could you please indicate a 
couple of them so I can see myself ?

Re: Passive FTP sees remote's _internal_ IP!!??

[gypsy]

gypsy wrote:
> >>>When the default GW is set to the linux box (192.168.223.254) and
> >>>passive FTP to a remote server is initiated, the FTP fails after
> >>>connection because the internal IP of the remote machine (192.168.1.11)
> >>>is seen rather than its external IP.  This problem occurs only when
> >>>passive FTP is used.

We created a workaround for this by forcing all FTP to be active, not
passive.  We did this with jftpgw (
http://www.mcknight.de/jftpgw/jftpgw-0.13.5.tar.gz ) with a transparent
proxy setup.

This is the configuration:
#!/bin/sh

./configure \
"--prefix=/usr" \
"--sysconfdir=/etc" \
"--localstatedir=/var" \
"--enable-crypt" \
"--enable-libwrap" \
"--with-logpath=/var/log" \
"$@"

make all install

And the jftpgw.conf:
<global>
	serverport		21
	defaultmode		active
	debuglevel		8
	changeroot		never
	dropprivileges		startsetup
	runasuser		nobody
	loginstyle		0
	logintime		user
	commandtimeout		60
	dnslookups		no
	forwardlookups		no
	hostcachetimeout	28800
	initialsyst		yes
	reverselookups		no
	strictasciiconversion	on
	syslogfacility		daemon
	transfertimeout		120
	transparent-proxy	on
	welcomeline		.
</global>
<servertype standalone>
	listen			192.168.223.254:2370
	logstyle		files
	logfile			/var/log/jftpgw.log
	pidfile			/var/run/jftpgw.pid
</servertype>
<servertype inetd>
	logstyle		syslog
</servertype>
<from 0.0.0.0/0>
	access deny
</from>
<from 192.168.223.0/24>
	access allow
</from>

And the iptables line:
iptables -t nat -A PREROUTING -p tcp -s 192.168.223.0/24 --dport 21 -j
DNAT --to 192.168.223.254:2370

--
gypsy

Passive FTP sees remote's _internal_ IP!!??

[gypsy]

In our network, we have 2 gateways.  The main GW is a Slackware 10.0 box
and the other is a SonicWALL firewall appliance.  Each connects to a
different external IP but both are in the same /29 network.

Note: No machine in our LAN has an IP of 192.168.1.11.

When the default GW is set to the linux box (192.168.223.254) and
passive FTP to a remote server is initiated, the FTP fails after
connection because the internal IP of the remote machine (192.168.1.11)
is seen rather than its external IP.  This problem occurs only when
passive FTP is used.

We do not believe that the OS or FTP daemon of the remote host matters
because when the default GW is set to the SonicWALL (192.168.223.1), the
passive FTP succeeds.

Therefore, we conclude that there is something wrong with our linux box.

But WHAT?

Note that the connection has already occurred when port negotation is
attempted - which is when the FTP fails.

If anyone has advice, we will sincerely appreciate it.

The kernel is 2.4.32.

#!/bin/bash
iptables -P FORWARD ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
68.171.136.91
iptables -A FORWARD -j LOG

Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56473 DF PROTO=TCP
SPT=1069 DPT=1090 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56500 DF PROTO=TCP
SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 00:32:14 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56506 DF PROTO=TCP
SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0 
Nov 26 00:32:20 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56507 DF PROTO=TCP
SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0 
--
gypsy

Re: Passive FTP sees remote's _internal_ IP!!??

[William Lima]

Dear,

Load modules:

modprobe ip_nat_ftp

Abs,

2006/11/26, gypsy <gypsy@iswest.com>:
> In our network, we have 2 gateways.  The main GW is a Slackware 10.0 box
> and the other is a SonicWALL firewall appliance.  Each connects to a
> different external IP but both are in the same /29 network.
>
> Note: No machine in our LAN has an IP of 192.168.1.11.
>
> When the default GW is set to the linux box (192.168.223.254) and
> passive FTP to a remote server is initiated, the FTP fails after
> connection because the internal IP of the remote machine (192.168.1.11)
> is seen rather than its external IP.  This problem occurs only when
> passive FTP is used.
>
> We do not believe that the OS or FTP daemon of the remote host matters
> because when the default GW is set to the SonicWALL (192.168.223.1), the
> passive FTP succeeds.
>
> Therefore, we conclude that there is something wrong with our linux box.
>
> But WHAT?
>
> Note that the connection has already occurred when port negotation is
> attempted - which is when the FTP fails.
>
> If anyone has advice, we will sincerely appreciate it.
>
> The kernel is 2.4.32.
>
> #!/bin/bash
> iptables -P FORWARD ACCEPT
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -t nat -A POSTROUTING -o eth1 -s 192.168.223.0/24 -j SNAT --to
> 68.171.136.91
> iptables -A FORWARD -j LOG
>
> Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56473 DF PROTO=TCP
> SPT=1069 DPT=1090 WINDOW=60352 RES=0x00 SYN URGP=0
> Nov 26 00:32:10 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56500 DF PROTO=TCP
> SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> Nov 26 00:32:14 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56506 DF PROTO=TCP
> SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> Nov 26 00:32:20 GWbox kernel: IN=eth0 OUT=eth1 SRC=192.168.223.4
> DST=192.168.1.11 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=56507 DF PROTO=TCP
> SPT=1070 DPT=1091 WINDOW=60352 RES=0x00 SYN URGP=0
> --
> gypsy
>
>


-- 
William R. Lima
wrochalima@linuxit.com.br