Date: Tue, 23 Mar 1999 13:21:21 -0500 From: "Jim Flowers" <jflowers@ezo.net> To: "Charles Henrich" <henrich@flnet.com> Cc: "Matthew Reimer" <mreimer@vpop.net>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: NAT/SKIP/MTU Message-ID: <001301be755a$0eed6d20$23b197ce@ezo.net> References: <lists.freebsd.hackers.19990322144600.A17340@orbit.flnet.com> <36F6D023.1925D6D5@vpop.net> <001301be74ce$d63efdd0$23b197ce@ezo.net> <19990323100221.D8398@orbit.flnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Skip definitely alters the mtu downward that it presents for discovery in order to allow for the increased size of the outbound encapsulated packets without causing fragmentation. This is described in one of the white papers that comes with it. Have you tried setting the mtu of the skip interface down to something like 756? I had to do this for cvsup (< 1300) to work reliably although I didn't ascribe the problem to SKIP at the time because it goes through the NAT path but it still has to go through the SKIP ACL in cleartext. - might have been. This should have the effect of causing smaller packets to be received. ----- Original Message ----- From: Charles Henrich <henrich@flnet.com> To: Jim Flowers <jflowers@ezo.net> Cc: Matthew Reimer <mreimer@vpop.net>; <freebsd-hackers@FreeBSD.ORG> Sent: Tuesday, March 23, 1999 1:02 PM Subject: Re: NAT/SKIP/MTU > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001301be755a$0eed6d20$23b197ce>