Re: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side

From: Patrick M. Hausen (hausen_at_punkt.de)
Date: 08/21/03

  • Next message: Melson, Paul: "RE: [fw-wiz] pixen abnomalities;" 
    To: Mikael Olsson <mikael.olsson@clavister.com>
Date: Thu, 21 Aug 2003 22:02:28 +0200 (CEST)

    Hi all!

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

    Thanks for your time,
    Patrick 

    -- 
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Vorholzstr. 25        Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe       http://punkt.de
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
  • Next message: Melson, Paul: "RE: [fw-wiz] pixen abnomalities;"

    Relevant Pages

    • Re: sl2tps, MRU, MTU, and MSS
      ... When the client opens a TCP connection, it offers an MSS of 1360 ... datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU ... When I bring up the tunnel, LCP negotiates an MRU of 1400. ...
      (freebsd-net)
    • Re: [PATCH] xt_TCPMSS: SYN packets are allowed to contain data
      ... The added MSS is likely to be larger than 536 too... ... If you cannot guarantee you know the source MTU, ... I was referring to the SYN packet itself. ... there is no data and the header offset is wrong so it hasn't been ...
      (Linux-Kernel)
    • Re: TCP packet size is much smaller than expected
      ... 1500 bytes is the IP MTU and includes the IP header. ... The MSS ... is the IP MTU less the size of the IP header and the TCP header. ...
      (comp.os.linux.networking)
    • Re: TCP_MAXSEG vs TCP/generic segmentation offload (tso/gso)
      ... I was under the impression that TSO (and maybe GSO) implied more ... cleverness in the network card; that the network card more or less gets ... but device does not use its own MTU to ... You can have multiple flows in parallel, each with its own MSS, while ...
      (Linux-Kernel)
    • Re: ICMP-based blind performance-degrading attack
      ... read/write packets are generally 8k in size. ... above can possibly be reproduced with TCP. ... they would normally send me (with an MSS of 1436). ... just as there is no "minimum MTU" size for IP. ...
      (Bugtraq)