From owner-freebsd-security Mon Oct 9 18:19:51 2000 Delivered-To: freebsd-security@freebsd.org Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by hub.freebsd.org (Postfix) with ESMTP id 82CAE37B502 for ; Mon, 9 Oct 2000 18:19:48 -0700 (PDT) Received: from mthompson.home.net ([24.7.95.143]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001010011837.KSSK4031.femail4.sdc1.sfba.home.com@mthompson.home.net> for ; Mon, 9 Oct 2000 18:18:37 -0700 Message-Id: <4.3.2.7.2.20001009180629.00cda790@mail.smateo1.sfba.home.com> X-Sender: mpthompson@mail.smateo1.sfba.home.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Oct 2000 18:16:10 -0700 To: freebsd-security@freebsd.org From: Mike Thompson Subject: Re: Encrypted IP tunneling solution In-Reply-To: <4.3.2.7.2.20001009101945.04999df0@localhost> References: <4.3.2.7.2.20001008220611.085d2f00@mail.atomz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Unfortunately, the work involved on the Windows side is not nearly as easy as on the FreeBSD side. It would most likely mean creating a virtual NDIS MAC-layer VxD that essentially serves the same function that /dev/tunXX does on FreeBSD and then writing a Windows userland application would tie the virtual NDIS driver to an encrypted SSH connection. Not impossible, not trivial either. I have come across a Windows version of BPF work-alike driver (it is even under a Berkeley style license) that would help in implementing such a solution. Mike At 10:22 AM 10/9/00 -0600, you wrote: >At 11:56 PM 10/8/2000, Mike Thompson wrote: > >>BTW, my ultimate goal behind this little application is to get it working >>with Windows clients running SSH protocols where it can serve as a very >>simple, but secure VPN solution. > >This would be the real value. It would be VERY useful to tunnel Windows >clients with minimal effort. It'd be even nicer if it were stand-alone; >that is, if it did not require a separate SSH implementation to be >installed on the Windows machine. Many of the users who one wants to >tunnel into a LAN remotely do not have shell accounts, and giving them >such accounts can compromise security and/or be confusing to them. Using >SSH 2 (which doesn't require a shell account for port redirection) would >be a good way to do this. > >--Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message