Date: Sat, 20 Mar 1999 13:36:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: alk@pobox.com Cc: roberto@keltia.freenix.fr, chat@FreeBSD.ORG Subject: Re: SKIP on 3.1 Message-ID: <199903201336.GAA04990@usr01.primenet.com> In-Reply-To: <14065.41601.661191.482612@avalon.east> from "Anthony Kimball" at Mar 18, 99 07:09:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> : > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903201336.GAA04990>