Firewall Wizards mailing list archives

Re: Transparent proxies and PMTUD on the (WWW) server side


From: Mikael Olsson <mikael.olsson () clavister com>
Date: Tue, 26 Aug 2003 23:03:26 +0200


"Patrick M. Hausen" wrote:

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?

Well, yes, sometimes. But not nearly often enough to rely on.
Consider what happens if TWO segments arrive while your proxy 
process is sleeping (perhaps because another proxy process is
running on full).... - Yeah, your read() is going to return
2k+ of data, which will then be passed on to the write(), which
will send full-length packets.

Then of course there's the whole issue of the Nagle algorithm,
delayed ACKs, and various other TCP performance tweaks that 
can cause sends to be slightly delayed. That will also cause
larger segments to be transmitted.

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"
"work".

Eh? That just HAS to be a function of something completely
different; I refuse to believe that DF stripping can cause
these kind of failures. UDP is a non-issue; I know of no OS
that does PMTUd for UDP. And windows most definitely checks
checksums of TCP, which is what SMB uses for everything but
announcements, and announcements have nothing to do with 
actual file transfer.

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


Current thread: