[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  list at m0n0wall dot neon1 dot net
 Subject:  Re: [m0n0wall] pb8 released!
 Date:  Fri, 9 May 2003 14:47:09 -0700 (PDT)
On Wed, 30 Apr 2003, Manuel Kasper wrote:

> - RADIUS server support for PPTP VPN (may be used with e.g. Microsoft IAS)

But still no PPTP VPN client. :-)

> - bug in ipfilter's MSS clamping feature fixed
> 
> I've spent too much time again fixing bugs in other people's code. I
> figured that ipfilter didn't fix up the MSS properly on some packets,
> while it worked fine on others (MSS = maximum segment size; a TCP option;
> fixing this up is necessary for PPPoE connections (DSL) since the MTU is
> 1492 instead of 1500 bytes because of the PPPoE header - all DSL routers

Sigh.  Since when is it a router's responsibility to program around other
peoples' misconfigurations? :-)

The way that's *supposed* to work is that Path MTU Discovery figures out
the smaller limit and uses it.  "MSS clamping" just sweeps the problem
under the rug, allowing it to bite you in non-TCP cases.

> The impact was that transferring more than 1452 bytes of data at once
> from/to hosts which:
> 
> - do not send any TCP options other than MSS clamping in their SYN
>   (as such the bug depended on the operating system of the hosts)
> and, at the same time
> - block ICMP "fragmentation needed" messages

The latter is the problem.  Blocking ICMP errors is a Very Bad Thing in
general.  Sounds like some firewall admin is confused.


Speaking of which, completely blocking private network addresses in the
firewall (as m0n0wall currently does) can cause problems.  Even though
private network addresses aren't supposed to be visible "outside", the
address shortage has caused some ISPs to use private addresses for
internal routers.  Ordinarily these aren't visible, but they become
visible whenever such a router sends an ICMP error, which thus originates
from a "private" address.  The most obvious problem case is traceroute,
but PMTUD could also suffer if such a router just happened to be at an
"MTU choke point". 

One could filter ICMP errors based on the *destination* address in the
*embedded* IP header, though simply not blocking them at all shouldn't be
too bad, given that they typically need to match against known connections
or "associations" in order to have any effect.  Such a loophole should be
only for ICMP *errors* (types 3, 4, 5, 11, 12), not requests or responses.


A worse case involves ISPs that assign private network addresses to their
*customers*, so that in effect even the customer's border router is behind
NAT.  The best solution is to avoid such brain-damaged ISPs, but if that's
not possible, then *any* filtering of (some) private network addresses
would be problematic. 

					Fred Wright