Date: Sat, 23 Oct 1999 05:37:08 +0000 From: Bert Kellerman <bertke@bellsouth.net> To: security@FreeBSD.ORG Subject: Re: GRE/IP 47/PPTP Message-ID: <38114983.15EEE676@bellsouth.net> References: <199910221748.KAA67824@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs wrote: > Martin Machacek writes: > > Well, GRE tunnelling is something completely different from suporting GRE in > > NAT. I can imagine doing one-to-one NAT and passing GRE, but doing many to one > > NAT and supporting multiple GRE streams is IMHO impossible. There is no > > parameter in the GRE encapsulation that would allow you to identify the real > > internal recipient if you NAT multiple internal addresses to one external > > address. > > True in general.. however, if all you're using GRE for is PPTP, then > you can multiplex on the call identifier in the PPTP/GRE header. > > -Archie > > Are you referring to the optional 32 bit key field in the GRE header? Won't the > packet on the way back in have a different key field, as this is used for > authenticating the sender, and change? The natd implementation would then need a > way to calculate the expected return key field to differentiate between > connections. However, since there is a 32 bit sequence number in the GRE > header like TCP, I wonder if it would be possible for the router to recreate the > internal sequence numbers and assign each internal client a limited pool out of > the 32 bit outside sequence block. Could this be possible? I mean how many times > has a single TCP session used all 4 million sequence numbers? RFC 1701 states > that this sequence number field is also optional so this might not work for all > vendors. Bert 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?38114983.15EEE676>