From owner-freebsd-hackers Tue Mar 23 10: 2:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orbit.flnet.com (orbit.flnet.com [205.240.232.32]) by hub.freebsd.org (Postfix) with ESMTP id 57D2E1538E for ; Tue, 23 Mar 1999 10:02:55 -0800 (PST) (envelope-from henrich@orbit.flnet.com) Received: (from henrich@localhost) by orbit.flnet.com (8.8.5/8.8.4) id NAA09227; Tue, 23 Mar 1999 13:02:22 -0500 (EST) Date: Tue, 23 Mar 1999 10:02:21 -0800 From: Charles Henrich To: Jim Flowers Cc: Matthew Reimer , freebsd-hackers@FreeBSD.ORG Subject: Re: NAT/SKIP/MTU Message-ID: <19990323100221.D8398@orbit.flnet.com> Mail-Followup-To: Jim Flowers , Matthew Reimer , freebsd-hackers@FreeBSD.ORG References: <36F6D023.1925D6D5@vpop.net> <001301be74ce$d63efdd0$23b197ce@ezo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <001301be74ce$d63efdd0$23b197ce@ezo.net>; from Jim Flowers on Mon, Mar 22, 1999 at 08:45:30PM -0500 X-Operating-System: FreeBSD 2.2-BETA_A X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On the subject of Re: NAT/SKIP/MTU, Jim Flowers stated: > Depending on what is wanted, SKIP and NAT will cooperate nicely on the same > interface. SKIP can be used for tunneled traffic over a VPN while NAT is > used for non-SKIP traffic. I have posted some how-tos on freebsd-security > recently but the general idea is to include appropriate matching rules in > ipfw to accept the SKIP related traffic prior to being diverted by the NAT > rule. This can also be used to switch individual network hosts from SKIP to > NAT and back by manipulating network host rules. The problems I'm seeing are apparently related to the fact that SKIP alters the mtu on the internal interface... However if I use the tun devices for skip it shouldnt be a problem, I'll search through the mailling lists for your write-ups, thanks! Here's the wacky situation that I'm running into: 10.x --> fxp0 [NATD] fxp1 <-- www.travelocity.com If I alter the MTU on the fxp0 interface (natd is on fxp1) connections to travelocity fail work, then no bulk data exchange works.. The connection eventually times out and drops. This also occurs with a bunch other sites as well. My first thought was to blame the FreeBSD internal framentation handling code between fxp1/fxp0, but unless there's something *really* wacky going on, it cant be that because the majority of internet traffic works peachy keen. I'm a bit rusty on my IP internals, is the fragmentation supposed to occur in the FreeBSD kernel, or should the MTU discovery process effectivly set the MTU of the entire path to the lower value? Charles Henrich Manex Visual Effects henrich@flnet.com http://orbit.flnet.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message