m0n0wall has an option NOT to filter these private addresses...

--------------------from interfaces_wan.php--------

|CHECKBOX| Block private networks
When set, this option blocks traffic from IP addresses that are reserved for
private
networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback
addresses
(127/8). You should generally leave this option turned on, unless your WAN
network
lies in such a private address space, too.

---------------------------------------------------

or I could be missing the point, of course ;-)

Regards,
Joachim

-----Original Message-----
From: Fred Wright [mailto:fw at well dot com]
Sent: vrijdag 9 mei 2003 23:47
To: list at m0n0wall dot neon1 dot net
Subject: Re: [m0n0wall] pb8 released!



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


---------------------------------------------------------------------
To unsubscribe, e-mail: list dash unsubscribe at m0n0wall dot neon1 dot net
For additional commands, e-mail: list dash help at m0n0wall dot neon1 dot net


-----------------------------------------------
MISSION STATEMENT 
-----------------------------------------------
Oce enables its customers to manage their documents efficiently and
effectively by offering innovative print and document management products
and services for professional environments.

-----------------------------------------------
DISCLAIMER 
-----------------------------------------------
This e-mail message and any attachment are intended for the sole use of the
recipient(s) named above and may contain information which is confidential
and/or protected by intellectual property rights.
Any use of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any form) by
other persons than the designated recipient(s) is prohibited.

If you have received this e-mail in error, please notify the sender either
by telephone (0032-2-729.48.11) or by e-mail and delete the material from
any computer.
Oce-Belgium/Oce-Interservices is nor responsible for the correct and
complete transfer of the contents of the sent e-mail, neither for the
receipt on due time.  This e-mail message does not bring about a contractual
obligation for Oce-Belgium/Oce-Interservices.

Thank you for your cooperation.

For further information about Oce-Belgium/Oce-Interservices please see our
website at www.oce.be

-----------------------------------------------