From: Alistair Tonner <Alistair@nerdnet.ca>
To: netfilter@lists.netfilter.org
Subject: Re: squid + clamp-mss-to-pmtu
Date: Tue, 10 May 2005 17:12:58 -0400 [thread overview]
Message-ID: <200505101712.58976.Alistair@nerdnet.ca> (raw)
In-Reply-To: <1115656458.2899.40.camel@localhost.localdomain>
On May 9, 2005 12:34 pm, jonathan wrote:
> Le jeudi 05 mai 2005 à 06:32 -0400, Alistair Tonner a écrit :
> > On May 4, 2005 11:09 am, jonathan wrote:
> > > Hi,
> > > I have a problem with squid and iptables.
> > > I have to use "TCPMSS --clamp-mss-to-pmtu" to adapt the mtu with the
>
> ISP
<< BULK SNIPPAGE FOR BREVITY>>>
> >
> > You are doing the clamp in both FORWARD and OUTPUT. This is a
>
> good idea on
>
> > systems that require this function. However since we don't know the
>
> flow on
< more snippage >
> scheme of the network :
> clients (win2000 and linux)
> iptables+squid+advanced routing (same machine)
> 2 differents ISPs
>
> > 2) where are the systems initiating the failed connections
> located on that
> > network
> sorry, i don't understand your question ...
I presume the 'clients' above
> > 3) where is squid on that network?
>
> squid is on the same server than the iptables firewall (between clients
> and the Internet)
>
> > 4) what are you doing to get connections to go through squid?
>
> Squid is configurated as transparent proxy, only the gateway IP address
> is configurated on the clients. (nothing on the browsers)
>
> > 5) what other rules are there?
>
> classical rules are configurated, NAT for the local network... and
> filtering rules for accessing typical ports (DROP INPUT AND FORWARD
> setting by default).
>
> routing configuration makes some marked packets going through ISP1 and
> other marked packet through ISP2.
>
Okay -- now we're getting somewhere ... 'classical rules' is nice and
generic, but I will assume you mean that ESTABLISHED,RELATED are allowed on
the top of INPUT, OUTPUT, FORWARD chains, and that selective packets are
allowed through ... i.e port 53 udp for DNS, and that port 80 and 443 from
the internal network to the world is redirected through squid. This function
could be an issue -- specially if the redirect is in the wrong chain .. (IIRC
should be in mangle PREROUTING and catch *all* traffic on those ports)
Where are you marking packets and under what rules? You mention that some go
out isp1 and others out isp2. Are you marking based on dns/mail/web/ftp/ or
are you marking based on destination ip?
I still think you want to a) dump all rules with
iptables -L -n -v -x --line-numbers
iptables -L -n -v -x --line-numbers -t nat
iptables -L -n -v -x --line-numbers -t mangle,
b) sanitize them by masking out real IP's
c) send them here.
Since you're likely using iproute2 your route tables wouldn't hurt
either .. .equally sanitized.
> > 6) what are the tcp_ecn settings on the firewall (I'd suspect
> ecn before
> > anything else since there are so many b0rken firewalls out there that
> don't understand it)
> the tcp_ecn is switch to "0".
> > 7) what is meant by inaccessible? what functions of squid might
> affect this?
> it means that mozilla browser write the state "waiting for..." until the
> timeout. Sometimes, it take a lot of time to display the website writing
> the state " transferring data from ...", and the website appears several
> minutes later or never appears !
And what is squid saying about these connections?
>
> I've noticed that squid's log display "TCP_NEGATIVE_HIT/404" many times
> ( i suppose it's normal on some websites), but it seems like squid block
> on this "error" message, trying to get a 2xx HTTP return code or
> something like this. Is it possible ?
googled:
TCP_NEGATIVE_HIT:
The request was for a negatively-cached object. Negative-caching refers to
caching certain types of errors, such as "404 Not Found." The amount of time
these errors are cached is controlled with the negative_ttl configuration
parameter.
9.21 In the IP cache section, what's the difference between a hit, a negative
hit and a miss?
A HIT means that the document was found in the cache. A MISS, that it wasn't
found in the cache. A negative hit means that it was found in the cache, but
it doesn't exist.
There are still quite a number of layers at which you might have issues.
What happens when you drop squid out of the equation completely?
What happens if you drop the TCPMSS clamps out of iptables?
What happens if you drop the mark/route combo and use one/both ISPs?
>
> > > Is there a way to make it work?
Certainly it can be made to work, ... I have here a large hammer, we'll make
it work! *grin*
> > >
> > > thanks
Good luck!
Alistair Tonner
next prev parent reply other threads:[~2005-05-10 21:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-04 15:09 squid + clamp-mss-to-pmtu jonathan
2005-05-05 10:32 ` Alistair Tonner
[not found] ` <1115656458.2899.40.camel@localhost.localdomain>
2005-05-10 21:12 ` Alistair Tonner [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-05-10 15:55 jonathan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200505101712.58976.Alistair@nerdnet.ca \
--to=alistair@nerdnet.ca \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.