From owner-freebsd-current@FreeBSD.ORG Mon Jul 3 22:11:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D429D16A4D4 for ; Mon, 3 Jul 2006 22:11:47 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDE6643DD3 for ; Mon, 3 Jul 2006 22:09:59 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k63M9kx0046616 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 4 Jul 2006 00:09:56 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <20060630213259.GA20670@odin.ac.hmc.edu> References: <4498D108.90907@rogers.com> <20060621053007.GA3320@odin.ac.hmc.edu> <20060630213259.GA20670@odin.ac.hmc.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Tue, 4 Jul 2006 00:09:14 +0200 To: Brooks Davis X-Mailer: Apple Mail (2.752.2) Cc: Mike Jakubik , freebsd-current@freebsd.org, Garance A Drosihn , Justin Hibbits Subject: Re: ~/.hosts patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 22:11:47 -0000 OK, I think I do understand the issue now, and this might or might not help in your situation... Am 30.06.2006 um 23:32 schrieb Brooks Davis: > The problem is that the client must think it is > connecting to server.fully.qualified.domain and do so by name because > the name is passed to the server which misuses in in interesting ways. At work, we're running a sort-of-VPN to a client of ours using pf and ssh with the socks proxy. On our side, pf redirects all TCP traffic to a certain set of IPs to a local process on the internal firewall (IPs identical to the customers's network, and we've copyied over their internal DNS zones). The local proxy process (www/transproxy) then uses socks to establish a TCP connection via the (permanent) ssh tunnel to the clients network. At the client's side, nothing is required except for a sshd configured to allow for dynamic port forwardings (and working internal DNS). From client software at our end, and our customer's server processes, it's virtually indistinguishable from a standard connection: the IPs are the same, the DNS names are the same, only the origin of the connection in the customer's network is the gateway machine, instead of the real client at our end. This appears to be working quite well with quite a number of standard and proprietary protocols. HTH, Stefan -- Stefan Bethke Fon +49 170 346 0140