From ken@panzer.kdm.org  Sun Sep 23 16:22:47 2001
Return-Path: <ken@panzer.kdm.org>
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id 7D9D537B408
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 23 Sep 2001 16:22:46 -0700 (PDT)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id RAA04727;
	Sun, 23 Sep 2001 17:22:45 -0600 (MDT)
	(envelope-from ken)
Message-Id: <200109232322.RAA04727@panzer.kdm.org>
Date: Sun, 23 Sep 2001 17:22:45 -0600 (MDT)
From: ken@kdm.org
Reply-To: ken@kdm.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: natd doesn't work with Path MTU discovery
X-Send-Pr-Version: 3.2

>Number:         30775
>Category:       kern
>Synopsis:       natd doesn't work with Path MTU discovery
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 23 16:30:00 PDT 2001
>Closed-Date:    Mon Sep 24 21:20:46 PDT 2001
>Last-Modified:  Mon Sep 24 21:21:28 PDT 2001
>Originator:     Kenneth D. Merry
>Release:        FreeBSD 4.4-STABLE i386
>Organization:
KDM Enterprises
>Environment:

A 4.4-stable (or most any other version of FreeBSD) box with two nics.  One
is on the 'external' net, one on the internal net (with RFC 1918
addresses).

ipfw and natd are configured to provide NAT functionality.

>Description:

natd doesn't handle need-to-frag ICMP packets coming back from the router,
so the machine behind the NAT box doesn't know that it needs to reduce the
route MTU for a given site.

>How-To-Repeat:

Crank up tcpdump on the NAT box and a machine behind the NAT.

At least in my case, go to www.schwab.com using a web browser on a machine
behind the NAT, and watch the tcpdump output.  I see ICMP need-to-frag
packets coming back into the NAT box on the external interface, but they
aren't sent back to the machine behind the NAT box.

The problem with www.schwab.com may or may not be reproducible, depening on
whether the problem is closer to me or closer to schwab.

In any case, natd should handle ICMP need to frag packets, since TCP Path
MTU discovery doesn't work without them.

>Fix:

potential work-arounds:

Run an application proxy server on a machine that isn't behind natd.

Run the application on a machine that isn't behind natd.

Investigate whether ipfilter's NAT code can handle path MTU discovery.

>Release-Note:
>Audit-Trail:

From: Ruslan Ermilov <ru@FreeBSD.ORG>
To: ken@kdm.org
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/30775: natd doesn't work with Path MTU discovery
Date: Mon, 24 Sep 2001 14:50:13 +0300

 Actually, natd(8) (libalias(3)) handles these all right.
 Make sure you are not blocking ICMP in your firewall.
 Please send me the output from a "natd -v" session that
 contains these ICMP packets.
 
 Having your firewall rules listed would also help.
 
 On Sun, Sep 23, 2001 at 05:22:45PM -0600, ken@kdm.org wrote:
 > 
 > A 4.4-stable (or most any other version of FreeBSD) box with two nics.  One
 > is on the 'external' net, one on the internal net (with RFC 1918
 > addresses).
 > 
 > ipfw and natd are configured to provide NAT functionality.
 > 
 > >Description:
 > 
 > natd doesn't handle need-to-frag ICMP packets coming back from the router,
 > so the machine behind the NAT box doesn't know that it needs to reduce the
 > route MTU for a given site.
 > 
 > >How-To-Repeat:
 > 
 > Crank up tcpdump on the NAT box and a machine behind the NAT.
 > 
 > At least in my case, go to www.schwab.com using a web browser on a machine
 > behind the NAT, and watch the tcpdump output.  I see ICMP need-to-frag
 > packets coming back into the NAT box on the external interface, but they
 > aren't sent back to the machine behind the NAT box.
 > 
 > The problem with www.schwab.com may or may not be reproducible, depening on
 > whether the problem is closer to me or closer to schwab.
 > 
 > In any case, natd should handle ICMP need to frag packets, since TCP Path
 > MTU discovery doesn't work without them.
 > 
 > >Fix:
 > 
 > potential work-arounds:
 > 
 > Run an application proxy server on a machine that isn't behind natd.
 > 
 > Run the application on a machine that isn't behind natd.
 > 
 > Investigate whether ipfilter's NAT code can handle path MTU discovery.
 
 -- 
 Ruslan Ermilov		Oracle Developer/DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: "Kenneth D. Merry" <ken@kdm.org>
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/30775: natd doesn't work with Path MTU discovery
Date: Mon, 24 Sep 2001 22:13:12 -0600

 On Mon, Sep 24, 2001 at 14:50:13 +0300, Ruslan Ermilov wrote:
 > Actually, natd(8) (libalias(3)) handles these all right.
 > Make sure you are not blocking ICMP in your firewall.
 > Please send me the output from a "natd -v" session that
 > contains these ICMP packets.
 > 
 > Having your firewall rules listed would also help.
 
 You're right, my firewall rules were blocking incoming icmp to the machines
 on the inside.
 
 I'll avoid clogging the PR database with my config, and I'll close the PR
 once this mail shows up in the PR database.
 
 Ken
 -- 
 Kenneth Merry
 ken@kdm.org
State-Changed-From-To: open->closed 
State-Changed-By: ken 
State-Changed-When: Mon Sep 24 21:20:46 PDT 2001 
State-Changed-Why:  
Pilot error, I wasn't allowing ICMP in to the inside of the network. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=30775 
>Unformatted:
