From owner-freebsd-questions@FreeBSD.ORG Tue Oct 11 13:52:41 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BCFA16A428 for ; Tue, 11 Oct 2005 13:52:41 +0000 (GMT) (envelope-from nospam@mgedv.net) Received: from mgedv.at (www.mgedv.at [195.3.87.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id D254943D5E for ; Tue, 11 Oct 2005 13:52:40 +0000 (GMT) (envelope-from nospam@mgedv.net) Received: from metis (localhost [127.0.0.1]) by mgedv.at (SMTPServer) with ESMTP id E087E186800; Tue, 11 Oct 2005 15:52:38 +0200 (MEST) From: "mdff" To: "'Norberto Meijome'" Date: Tue, 11 Oct 2005 15:52:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <434BB776.5030209@meijome.net> Thread-Index: AcXOZFBZ8Gg+wiQdQJWlD2BMeR8bYQABiz8w Message-Id: <20051011135238.E087E186800@mgedv.at> Cc: freebsd-questions@freebsd.org Subject: RE: encrypted file sharing bsd<-->winxp/2k3 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nospam@mgedv.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 13:52:41 -0000 > mdff wrote: > >>>staying away from ipsec and hw-crypto-ether-cards how > >>>can i connect to network-shares on freebsd-boxes from > >>>windows-clients having the whole connection (auth and > >>>data stuff) encrypted? > >>>it should be possible to map the share as a nw-drive. > >>>br... > >>> > >> > >>VPN is probably your choice. Check out OpenVPN > >>(http://openvpn.net/) for a portable and relatively > >>easy-to-setup solution. > > > > > > thx for the hint, but we don't want VPN/tunnels/ipsec > > solutions for this. > > would you mind explaining why not? > > (I was going ot suggest SSH forwarding and then your protocol > of choice, > but that is a tunnel ). > because one user being authenticated on the windows client should be able to connect to another network share without needing to always startup a ipsec-connection, authenticate and re-map the drive (necessary because sometimes windows does not re-map the drive automatically). also, the admin- needs for vpn-host-client connections is much more, what we can't offer to the customer. technically the solution would fit, but the admin overhead would be too much.