Bug 30775

Summary:	natd doesn't work with Path MTU discovery
Product:	Base System	Reporter:	ken <ken>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	4.4-STABLE
Hardware:	Any
OS:	Any

Description ken 2001-09-24 00:30:00 UTC

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.

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

Comment 1 ru freebsd_committer

2001-09-24 12:50:13 UTC

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

Comment 2 ken 2001-09-25 05:13:12 UTC

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

Comment 3 Kenneth D. Merry freebsd_committer

2001-09-25 05:20:46 UTC

State Changed
From-To: open->closed

Pilot error, I wasn't allowing ICMP in to the inside of the network.