Re: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side
From: Patrick M. Hausen (hausen_at_punkt.de)
To: Mikael Olsson <email@example.com> Date: Thu, 21 Aug 2003 22:02:28 +0200 (CEST)
Mikael Olsson wrote:
> > This relies on the assumtion that, if the external WWW server lowers
> > its MSS, the client side part of the proxy application will send
> > smaller frames, too - as soon as it get's them.
> If the proxy is a real proxy (and the ones you mention _are_), this
> won't help. The proxy builds its own TCP stream; the box that needs
> to know about the lowered MTU is the proxy itself, not the web server.
Yes, of course - that's what I tried to say in the next paragraph,
which you deleted ;-))
Just out of curiosity: I thought that the "naive" way of implementing
a proxy would preserve the lowered MSS while traversing the firewall:
while (len=read(external_socket, buf, external_mss))
write(internal_socket, buf, len);
Won't each read return as soon as a new TCP frame arrives
and won't each write result in a packet being sent? Sort of
MSS preservation by accident?
> This is what the proxy should do. The transparency function
> should be able to simply apply a little address translation
> magic to the ICMP error and hand it off to the host OS;
> it'd handle the MTU change just fine since it supports
> PMTUd to begin with.
I think _probably_ Gauntlet does it this way, but I can't test
that right now. I sent a similar message to the Sidewinder
product manager at Secure Computing, well known guy from the
good old Gauntlet days ;-) If this is apropriate for this list,
I'll forward what he's got to say about this problem.
(if he gives me permission to do so)
> HOWEVER: (Yes, I'll undoubtedly take a lot of heat over this,
> but I've got a thick hide) In your situation, I'd just turn
> PMTUd off and forget about it. Seriously.
> How bad is fragmentation? .. Really?
Well ... I'm don't care that much, really. It just doesn't
feel *right* ;-) OTOH all other solutions involve the
routers "emulating" a bigger MTU by fragmenting and reassembling
on the tunnel head and tail instead of reassembling at the
destination - Cisco's "ip mtu" command comes into play here.
That's even worse.
> Related story: A while ago, I made the call to change the default
> settings in the units we ship to always strip the DF bit in
> packets that traverse them, thereby disabling PMTUd completely and
> falling back on good old fragmentation. The engineer in me hates
> it, but it really does seem to work better these days.
Before I started to really investigate my "MTU problems" I tried
the same. This lead to data corruption for strictly internal
(non-firewall) traffic with Windows filesharing. I don't know
how, maybe Windows doesn't use UDP checksums for SMB, ...
That's my next task, now that I found a way to make "the Internet"
Thanks for your time,
-- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de _______________________________________________ firewall-wizards mailing list firstname.lastname@example.org http://honor.icsalabs.com/mailman/listinfo/firewall-wizards