Re: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side
From: Mikael Olsson (mikael.olsson_at_clavister.com)
Date: 08/21/03
- Previous message: edp: "R: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- In reply to: Patrick M. Hausen: "[fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- Next in thread: Patrick M. Hausen: "Re: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- Reply: Patrick M. Hausen: "Re: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "Patrick M. Hausen" <hausen@punkt.de> Date: Thu, 21 Aug 2003 21:41:54 +0200
"Patrick M. Hausen" wrote:
>
> [PMTUd problems with transparent proxies that don't pick up ICMP]
>
> My ad hoc solution
> was to turn of PMTUD on the sidewinder box so the internal packets
> could be fragmented. I don't really like that but it works for now.
>
> - Permit "ICMP frag needed" from internal to external with appropriate
> NAT _if_ there is an active proxy session to the external destination.
>
> 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.
> - The perfect approach IMHO would be to have the ALG lower its own
> MSS on the client side when it encounters an "ICMP frag needed"
> that can be matched to an active proxy connection and leave the
> outside connection as it is.
> This can't be accomplished or even mimicked by proxy or packet
> filter rules but must be implemented as a feature of the ALG in
> question.
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.
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?
Sure; fragmentation adds a little tranmission overhead.
But so do your VPN tunnels. Packet loss is more painful
with fragmentation, sure, but just how much packet loss do
modern networks get anyhow?
PMTUd, while being a sound idea way back then, breaks horribly
in the Internet of today because of ... well .. lots of reasons,
mainly involving NATs and firewalls.
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.
-- 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
- Previous message: edp: "R: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- In reply to: Patrick M. Hausen: "[fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- Next in thread: Patrick M. Hausen: "Re: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- Reply: Patrick M. Hausen: "Re: [fw-wiz] Transparent proxies and PMTUD on the (WWW) server side"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
