On Sat, 12 Feb 2005 20:33:52 -0600, Josh Nerius <jnerius@xxxxxxxxx> wrote: > > hello josh. > > > > I stand 100% with Jason O.'s opinion .. > > netfilter/iptables has nothing to do with squid binding to some/any port. > > whoever had to do his homework ... i beleive has done it. > > Accessing that port is something different (-i lo -j ACCEPT), but i > > beleive that's not the case. > > > > regards, > > Georgi Alexandrov > > Hello George, > > >From experience...not speculation, I still stand by what I said. > > Squid can be a strange animal. In many configurations, the > communication between child processes relies on being able to > communicate via the loopback interface of the machine. Iptables can, > and and in configurations I've worked with, has caused the same > symptoms described. Basically, the daemon never gets a chance to bind > to a port as the initial communication between these child processes > is broken causing the entire startup procedure to fail. This makes the > illusion that the problem is related to binding the port when in fact > the program can't start for other reasons. > > This problem *can* be caused by firewall rules in place that prevent > this communication from happening. If you examine the rulesets posted, > it looks like he is using policy DROP on the INPUT chain which may > certainly cause problems with squid if proper rules to allow the > necessary traffic are not in place. I will test by removing DROP rule on the INPUT chain. > Another thing to note here, and the reason that I'm of the opinion > that this could be a netfilter/iptables problem is the fact that the > original poster seems to have indicated that squid works when iptables > is flushed. > > The last point mentioned above, coupled with the fact that I've dealt > with this problem during the development of a transparent redirection > appliance for the company I work for, is why I maintain the opinion > that I do. > > As mentioned before, Jason has a good knowledge of netfilter, but > apparently not Squid, thus my homework comment. > > Thanks, and hopefully this information helps to clarify the > information I posted. :-) Sorry, for being so late in replying. > Josh Nerius
