Hi Jo,
the first thing I am wondering about is that you open ports 1024:65535
while I would expect the initial data connection at port 20.
Nevertheless, the main problem you are facing is that you try to
conntrack FTP on your own. FTP is a little bit too complex for that so
you'll get by with a little help from your friend: The helper module may
be the solution for your problem.
I built my linux from scratch so I cannot tell you much about any
distributions or util packages, but my PC serves as gateway for the both
of my local home-networks to the internet and my ftp routing works well
so I paste the corresponding section of my configuration in order to
give an example. Since you don't seem to be masquerading you can omit
the last rule and replace the IP-adresses and interface names. Note that
these rules only accept outgoing FTP connections, so if you're driving a
server you'll have to add NEW to the --ctstate of the second rule.
###########################
# forwarding tcp sessions to global net #
###########################
*filter
-A FORWARD -s 10.0.0.0/255.255.255.224 -d ! 10.0.0.0/255.255.255.224 -i
! ppp0 -o ppp0 -p tcp --dport 21 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A FORWARD -d 10.0.0.0/255.255.255.224 -s ! 10.0.0.0/255.255.255.224 -i
ppp0 -o ! ppp0 -p tcp --sport 21 -m conntrack --ctstate ESTABLISHED -j
ACCEPT
-A FORWARD -d 10.0.0.0/255.255.255.224 -s ! 10.0.0.0/255.255.255.224 -i
ppp0 -o ! ppp0 -p tcp -m helper --helper ftp-21 -m conntrack --ctstate
RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.0.0.0/255.255.255.224 -d ! 10.0.0.0/255.255.255.224 -i
! ppp0 -o ppp0 -p tcp -m helper --helper ftp-21 -m conntrack --ctstate
RELATED,ESTABLISHED -j ACCEPT
COMMIT
*nat
-A POSTROUTING -s 10.0.0.0/255.255.255.224 -o ppp0 -p tcp --dport 21 -m
conntrack --ctstate NEW -j MASQUERADE
COMMIT
Good luck
Arnd-Hendrik
spaminator@xxxxxx wrote:
Hi there,
I'm experiencing a strange problem when trying to FTP through a firewalling bridge.
My FTP client connects to the FTP server ok. But when the client switches to passive mode to get the directory's file list I get
stuck.
The bridge is running on a Debian Sarge box with kernel 2.6.8-3, iptables 1.2.11-10 and bridge-utils 1.0.4-1. The bridge is built from the physical devices eth0 and eth1.
The bridge is assigned an IP address too to be able to manage it remotely. Hence the INPUT and OUTPUT rules in my /etc/firewall.up.rules. As far as I understood, iptables only uses the FORWARD chain for the bridged packets.
Here is my /etc/firewall.up.rules:
#
# is invoked by /etc/network/interfaces as pre-up for br0
#
*filter
#
:INPUT DROP [0:0]
# some input rules
#
:FORWARD DROP [0:0]
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p icmp -j ACCEPT
# client to server
-A FORWARD -p tcp -s ! 217.17.69.18/255.255.255.224 --sport 1024:65535 \
-d 217.17.69.18/255.255.255.224 --dport 21 \
-m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -s ! 217.17.69.18/255.255.255.224 --sport 1024:65535 \
-d 217.17.69.18/255.255.255.224 --dport 1024:65535 \
-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# server to client
-A FORWARD -p tcp -s 217.17.69.18/255.255.255.224 --sport 21 \
-d ! 217.17.69.18/255.255.255.224 --dport 1024:65535 \
-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -s 212.117.69.128/255.255.255.224 --sport 1024:65535 \
-d ! 217.17.69.18/255.255.255.224 --dport 1024:65535 \
-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# logging
-A FORWARD -j ULOG --ulog-nlgroup 1
#
:OUTPUT DROP [0:0]
# some output rules
#
COMMIT
#
These are all rules in the FORWARD chain. Using "! --syn" or "-m state --state RELATED,ESTABLISHED" instead of "-m conntrack --ctstate RELATED,ESTABLISHED" leads to the same result:
When I look into the logfile I find an entry where my client:somehighport tries to tcp the server:somehighport. To me it looks like the client seems to want to establish a data-connection and iptables does not recognize these packet as RELATED or ESTABLISHED.
Just for the crack of it I temporarily added NEW to the second "client to server"-rule. With that it works fine, but leaves the boxes behind the bridge open for any attack on the high ports.
http, https or anything else is working properly, if I implement them in the FORWARD chain.
Any suggestions out there?
bye and TIA
Jo
_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
