Subject: Does not show up with standard clients

From: Lars Hanke <[email-masked]>
Date: Thu, 08 Jan 2009 00:54:02 +0100

I tried to further locate when the bug appears. As it turned out the 
command line ftp client does not cause the kernel panic, neither in 
passive nor in standard mode. I also ran the ftpsync Perl script without 
problems.

In order to allow the systems to access ftp, I added the following rule 
to the applicable chain:

iptables -A _chain_ -p tcp -o ppp0 -s _client-system_ --syn -m state 
--state NEW -j ACCEPT

(yes, there is a state established, related rule somewhere at the top of 
the stack.) However, even after having performed the ftpsync, using gFTP 
through frox panicked the firewall.

However, during further searching for the point of no return, I found 
that my proxy did not even have permission to open a connection to port 
21. After allowing this, I can browse ftp:// URLs through the same 
squid3 as used by frox without problems. The kernel panic using gFTP 
still persists.

If nf_nat_ftp and nf_conntrack_ftp are not loaded during browser access, 
the data connection is just dropped by the firewall. Nothing evil happens.

This is the frox configuration file. So far untested, but a very similar 
one ran for a couple of years on my Etch server.

/# grep -v '^#' /etc/frox.conf | grep -v '^ *$'
Listen proxy.mgr
Port 2121
ResolvLoadHack wontresolve.doesntexist.abc
User frox
Group frox
WorkingDir /srv/proxy/frox
LogLevel 25
LogFile /var/log/frox.log
PidFile /var/run/frox.pid
BounceDefend yes
CacheModule http
HTTPProxy 127.0.0.1:8080
MinCacheSize 5000
DoNTP yes
MaxForks 10
MaxForksPerHost 4
ACL Allow sleipnir - *

gFTP on sleipnir is configured to use:
Proxy: proxy.mgr:2121
Typ: user@host NOAUTH
USER %hu@%hh
PASS %hp

... and yes proxy.mgr resolves to the OpenVZ container homing the frox.