From owner-freebsd-security Fri Dec 8 11: 6:37 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 11:06:35 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id CDD6537B402 for ; Fri, 8 Dec 2000 11:06:34 -0800 (PST) Received: (qmail 56756 invoked from network); 8 Dec 2000 19:06:33 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 8 Dec 2000 19:06:33 -0000 From: "Patrick Bihan-Faou" To: Cc: Subject: Re: pipsecd+ipfw fwd Date: Fri, 8 Dec 2000 14:07:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, It sounds to me that you would be better served by configuring the IP routing tables rather than doing this with ipfw fwd rules. Also for the PMTU problem, tcpmssd (from the ports) can help you there. The issue is no different that the one experience by PPPoE users. The reason why you want to reduce the MTU of the IPSec link is that IPSec headers take some space. If you leave the MTU as 1500, the resulting IPSec packets may need to be fragmented and that will not help the performance of your link. Patrick. "John F Cuzzola" wrote in message news:... > Hello all, > I'm using pipsecd from the ports collection and it seems to do the job > (for my purposes anyway). I've noticed however that when configuring the > tunnel device the author recommends a MTU of 1440. Recently I added a > firewall rule like: > > ipfw add fwd ip from to any > > to force the next hop through the tunnel. Well it didn't work, it did for > small amounts of data but not larger ones which lead me to suspect a path > MTU discovery problem. I reconfigured the tunnel device for a MTU of 1500 > and it works great. My question is when using ipfw fwd what happens if the > size of the packet exceeds the MTU of the device? When IPFW FWDing does > ICMP 3.4 messages get sent back for large packets whos dont fragment > bit is set? or does that packet just get dropped? It > would appear the icmp 3.4 message doesn't get sent back but that could be > because of the pipsecd port. > > Kindof curious & thanks, > John > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message