Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Aug 1998 16:22:28 +0300
From:      Ruslan Ermilov <ru@ucb.crimea.ua>
To:        hackers@FreeBSD.ORG
Subject:   PMTU discovery, Firewalls and Sendmail
Message-ID:  <19980831162228.A20318@ucb.crimea.ua>

next in thread | raw e-mail | index | archive | help
Hi!

Recently I had problems receiving mail from hub.FreeBSD.org.
The logs were full of sendmail's timeout errors.

Now I finally discovered the problem and want to share my
experience with you ;-)

As you know (if you don't, please refer to RFC1191) today
almost every host uses ``Path MTU Discovery''.

The ICMP participates in it too.

What happens if some router along the path is blocking ICMP?

Let's start from an example.

As you know, hub.FreeBSD.org is a mailhub that serves all mailing
lists dedicated to FreeBSD. I'll call it just HUB, OK?

Somewhere on CRL.NET (the Walnut Creek CDROM's ISP) along the path
from my mail machine to the HUB the ICMP blocked.
This was made to protect HUB from ICMP DoS attacks.

Well, HUB is trying to send mail to me <RU@UCB.CRIMEA.UA>.
The host route to RELAY.UCB.CRIMEA.UA is cloned, and its MTU (by default)
is equal to 1500. More exactly, it will be equal to MTU of its first hop.
In case of Ethernet it is equal to 1500.

All following SMTP packets have the DF flag set.

While the packet size is small (at EHLO, MAIL and RCPT stages) all goes
smooth.  After that, the message itself is transferred at DATA stage.
The size of TCP packets increases.

Somewhere (I don't know exactly where) along the path from HUB.FREEBSD.ORG
to RELAY.UCB.CRIMEA.UA a router can't forward the packet due to its lower
next-hop MTU (at least, my site is connected to the Internet via SLIP with
MTU equal to 552).
This router, following RFC1191 rules, constructs and sends ``Datagram Too Big''
ICMP message to the HUB.

Router at CRL.NET blocks ICMP and doesn't let it to come through and reach
the HUB. The connection hangs at DATA stage. Then, after a certain period
of time, the standard timeout-driven retransmit procedure takes place.
HUB then re-transmits the same packet (of the same large size), router that
can't forward it sends back ICMP ``too big'', and CRL.NET blocks it.

This scenario will take place until HUB's sendmail drops the connection
by timeout.

So, HUB will never adjust the MTU.

My conclusion is:
~~~~~~~~~~~~~~~~

Don't block ICMP, because blocking breaks PMTU discovery.

At least, don't block ICMP type 3 code 4 messages (fragmentation needed
and DF set).

P.S. Now, when ICMP to HUB is not anymore blocked, everything is OK.

With best Regards,
-- 
Ruslan Ermilov		Sysadmin and DBA of the
ru@ucb.crimea.ua	United Commercial Bank
+380.652.247.647	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980831162228.A20318>