Date: Mon, 18 Sep 2000 00:01:54 +0200 From: Mipam <mipam@ibb.net> To: John F Cuzzola <vdrifter@ocis.ocis.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: MTU Path Discovery + ipfw/natd Message-ID: <20000918000154.B455@ibb0021.ibb.uu.nl> In-Reply-To: <Pine.LNX.4.21.0009171237090.24790-100000@ocis.ocis.net>; from vdrifter@ocis.ocis.net on Sun, Sep 17, 2000 at 12:48:11PM -0700 References: <Pine.LNX.4.21.0009171237090.24790-100000@ocis.ocis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 17, 2000 at 12:48:11PM -0700, John F Cuzzola wrote: > Hello Everyone, > I have a question on why something works. Suppose I have a private net > that a BSD box is masquarading for like this: > > ROUTER ----------- FreeBSD Box --------- Private Net 192.168.0.0/24 > > let's suppose the BSD box is masquarading through a public ip of > 209.52.173.1. My question has to do with MTU Path Discovery. Suppose a > computer 192.168.0.1 sends a packet with the don't fragment bit set. This > packet's source address get's changed to 209.52.173.1 and sent to the > next-hop (in this example the router). Now let's say the router can't > handle the size of the packet and since it is not allowed to fragment, it > tries to send a icmp 3.4 message (Fragmentation needed but DF bit > set). Well the router will send that ICMP message to 209.52.173.1 and > 192.168.0.1 would never receive it. I've never had any problems with > ipfw/natd but was curious why this scenario doesn't seem to happen. Can > anyone fill me in? Well, you are doing nat as you said, so state keeping is done. The icmp type 3 code 4 is send back as a reply on the initial packet. Now, i suppose you'll allow icmp type 3 code 4 in, it'll perfectly arrive back at 192.168.0.1. Btw, i dont know what kind of osses you run inside, but normally netbsd doesnt send packets with the df bit set on the initial packet, i guess also open and freebsd do not just send packets with the df bit set initially. Most systems announce a MSS that is determined from the MTU on the interface that the traffic to the remote system passes out from the system through, look with tcpdump and you'll see it happening. Some systems will send back a packet with the same mss and df bit set. Other will just send a reply back with the same mss or a smaller one, but without the df bit. Bye, Mipam. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000918000154.B455>