* Passive FTP sees remote's _internal_ IP!!??
@ 2006-11-26 9:01 gypsy
2006-11-26 20:18 ` William Lima
0 siblings, 1 reply; 10+ messages in thread
From: gypsy @ 2006-11-26 9:01 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Passive FTP sees remote's _internal_ IP!!??
2006-11-26 9:01 Passive FTP sees remote's _internal_ IP!!?? gypsy
@ 2006-11-26 20:18 ` William Lima
0 siblings, 0 replies; 10+ messages in thread
From: William Lima @ 2006-11-26 20:18 UTC (permalink / raw)
To: gypsy; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Passive FTP sees remote's _internal_ IP!!??
@ 2006-11-27 15:32 gypsy
2006-11-27 15:37 ` David Sims
2006-11-27 18:39 ` Maxime Ducharme
0 siblings, 2 replies; 10+ messages in thread
From: gypsy @ 2006-11-27 15:32 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Passive FTP sees remote's _internal_ IP!!??
2006-11-27 15:32 gypsy
@ 2006-11-27 15:37 ` David Sims
2006-11-27 18:39 ` Maxime Ducharme
1 sibling, 0 replies; 10+ messages in thread
From: David Sims @ 2006-11-27 15:37 UTC (permalink / raw)
To: gypsy; +Cc: netfilter
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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Passive FTP sees remote's _internal_ IP!!??
2006-11-27 15:32 gypsy
2006-11-27 15:37 ` David Sims
@ 2006-11-27 18:39 ` Maxime Ducharme
1 sibling, 0 replies; 10+ messages in thread
From: Maxime Ducharme @ 2006-11-27 18:39 UTC (permalink / raw)
To: 'gypsy', netfilter
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Passive FTP sees remote's _internal_ IP!!??
[not found] <20061127184454.0BD73DB@brinstar.nerim.net>
@ 2006-11-27 21:26 ` Pascal Hambourg
2006-11-28 4:46 ` gypsy
2006-11-28 9:14 ` gypsy
0 siblings, 2 replies; 10+ messages in thread
From: Pascal Hambourg @ 2006-11-27 21:26 UTC (permalink / raw)
To: netfilter
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 ?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Passive FTP sees remote's _internal_ IP!!??
2006-11-27 21:26 ` Pascal Hambourg
@ 2006-11-28 4:46 ` gypsy
2006-11-28 18:09 ` Maxime Ducharme
2006-11-28 22:36 ` Pascal Hambourg
2006-11-28 9:14 ` gypsy
1 sibling, 2 replies; 10+ messages in thread
From: gypsy @ 2006-11-28 4:46 UTC (permalink / raw)
To: netfilter; +Cc: Pascal Hambourg
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Passive FTP sees remote's _internal_ IP!!??
2006-11-27 21:26 ` Pascal Hambourg
2006-11-28 4:46 ` gypsy
@ 2006-11-28 9:14 ` gypsy
1 sibling, 0 replies; 10+ messages in thread
From: gypsy @ 2006-11-28 9:14 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Passive FTP sees remote's _internal_ IP!!??
2006-11-28 4:46 ` gypsy
@ 2006-11-28 18:09 ` Maxime Ducharme
2006-11-28 22:36 ` Pascal Hambourg
1 sibling, 0 replies; 10+ messages in thread
From: Maxime Ducharme @ 2006-11-28 18:09 UTC (permalink / raw)
To: 'gypsy', netfilter
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Passive FTP sees remote's _internal_ IP!!??
2006-11-28 4:46 ` gypsy
2006-11-28 18:09 ` Maxime Ducharme
@ 2006-11-28 22:36 ` Pascal Hambourg
1 sibling, 0 replies; 10+ messages in thread
From: Pascal Hambourg @ 2006-11-28 22:36 UTC (permalink / raw)
To: netfilter
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 ?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-11-28 22:36 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-26 9:01 Passive FTP sees remote's _internal_ IP!!?? gypsy
2006-11-26 20:18 ` William Lima
-- strict thread matches above, loose matches on Subject: below --
2006-11-27 15:32 gypsy
2006-11-27 15:37 ` David Sims
2006-11-27 18:39 ` Maxime Ducharme
[not found] <20061127184454.0BD73DB@brinstar.nerim.net>
2006-11-27 21:26 ` Pascal Hambourg
2006-11-28 4:46 ` gypsy
2006-11-28 18:09 ` Maxime Ducharme
2006-11-28 22:36 ` Pascal Hambourg
2006-11-28 9:14 ` gypsy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox