From owner-freebsd-chat Sat Mar 20 5:37: 3 1999 Delivered-To: freebsd-chat@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 38BB214D3E for ; Sat, 20 Mar 1999 05:36:59 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id HAA01797; Sat, 20 Mar 1999 07:31:26 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd001771; Sat Mar 20 07:31:14 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id GAA04990; Sat, 20 Mar 1999 06:36:26 -0700 (MST) From: Terry Lambert Message-Id: <199903201336.GAA04990@usr01.primenet.com> Subject: Re: SKIP on 3.1 To: alk@pobox.com Date: Sat, 20 Mar 1999 13:36:25 +0000 (GMT) Cc: roberto@keltia.freenix.fr, chat@FreeBSD.ORG In-Reply-To: <14065.41601.661191.482612@avalon.east> from "Anthony Kimball" at Mar 18, 99 07:09:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > : > The only caveat for is that I can't talk to the far 10.x net from one of > : > the routers :-( > : > : That's why NAT & RFC-1918 address space usage is evil. > > Why? Have you determined the cause of the failure, and found > that the tunnel/NAT were correctly configured, but protocol > constraints prevent any configuration from operating nominally? Actually, I have an Internet draft in the works on this; it's currently undergoing peer review prior to being sent off to the IETF. The problem boils down to proxying DNS data between primaries; all of the other issues are already covered by other drafts; see the drafts in the dnsind working group at www.ietf.org. For private-net to private-net addressing, you need to do addres block translation; this basically means that going from one 10.x/16 net to another, you have to ensure a unique value for "x" between the nets and/or block translate when crossing the net/net demarcation. For external-to-private net addressing, you don't use the default route. Instead, you use a GRE link to the NAT machine, and on the NAT machine, assign the tunnel an IP address in the local 10 block, and alias the LAN-side interface. Running PPP over the GRE, you assign the external machine the internal 10 interface IP address. Then set routing for the 10 network on the exterior machine to the local PPP interface. Effectively, this puts the external machine on the internal network with an internal network address. Yeah, this is complicated, but it's Best Current Practice. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message