OpenVPN

On Mon, 15 Sep 2003, James Yonan wrote:

> Yes, this is a problem.  For OpenBSD to talk to Windows over OpenVPN, we need
> either a tun driver for Windows or a tap driver for OpenBSD.
> 
> My guess is that the easier and better solution would be to solve the tap on
> OpenBSD problem, rather than the tun on Windows problem.

I'd like to challenge the "better" claim:

The tap driver gives full ethernet tunnelling, so the Windows box gets
to choose the IP, gets ARP traffic tunnelled and all that. That's pretty
much power IMO.

The tun driver, in contrast, only works for a specific IP, if the
Windows box chooses another one, it's not getting any traffic back.

I consider this a security relevant choice, if I have "half-trusted"
users, tap isn't really an option.

Background for the challenge is that OpenVPN might be useful as an
additional security layer on top of WLAN-WEP, but tap somewhat defeats
the purpose.

> I think that Windows users are going to prefer a tap interface anyways,
> because it carries the kind of traffic and protocols which Windows
> applications generate, such as broadcast traffic and non-IP protocols.

I for one don't need Windoze broadcast traffic gated, and "my" Windows
boxes hardly generate non-IP traffic. IPX or NetBEUI drivers aren't
installed on the Windows machines I maintain. ARP isn't needed. Granted,
if you need IGMP, you'll want tap, but I'd guess that the SMB browsing
can deal with most of the "problems".

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

James:
Are you aware of a Windows tun project? While most windows users may
prefer tap, I am interested in the point-to-point nature of the tun
device. When setting up many routed connections, it seems that each TAP
connection will use 1 ip and waste 2 others. I can also live without
broadcast traffic and non-IP protocols.

_SNIP_

I think that Windows users are going to prefer a tap interface anyways,
because it carries the kind of traffic and protocols which Windows
applications generate, such as broadcast traffic and non-IP protocols.

James

Bert Shuler <bshuler@...> said:

> James:
> Are you aware of a Windows tun project? While most windows users may
> prefer tap, I am interested in the point-to-point nature of the tun
> device. When setting up many routed connections, it seems that each TAP
> connection will use 1 ip and waste 2 others. I can also live without
> broadcast traffic and non-IP protocols.

While I do believe that the majority of Windows users will prefer a tap
interface, I say this simply because in my experience _most_ Windows users
prefer the option that is the easiest to configure.  Once you stop
automatically routing broadcasts and non-IP protocols, then you have to start
doing more configuration on Windows, i.e. setting up WINS servers and clients,
configuring samba differently, etc.

Having said that, I will agree that having a tun driver would be cool, and
that in many if not most circumstances, it is technically a better choice --
it is more scalable, it offers finer gradation of access control, it is more
universal across *nix platforms, etc. -- as long as you don't need to route
non-IP protocols.

The real problem is that very few open source developers are interested in
developing drivers for Windows, so there are not many choices available.  To
my knowledge there are three:  TAP-Win32, CIPE-Win32, and WinPcap, and none of
them provide tun capabilities.

James

Matthias Andree <ma+ovpnd@...> said:

> On Mon, 15 Sep 2003, James Yonan wrote:
> 
> > Yes, this is a problem.  For OpenBSD to talk to Windows over OpenVPN, we need
> > either a tun driver for Windows or a tap driver for OpenBSD.
> > 
> > My guess is that the easier and better solution would be to solve the tap on
> > OpenBSD problem, rather than the tun on Windows problem.
> 
> I'd like to challenge the "better" claim:

I mean "better" only in the sense of simpler configuration -- i.e. not needing
to set up a WINS server to make cross-subnet browsing work.  I agree that tun
is more scalable, secure, etc.

> The tap driver gives full ethernet tunnelling, so the Windows box gets
> to choose the IP, gets ARP traffic tunnelled and all that. That's pretty
> much power IMO.
> 
> The tun driver, in contrast, only works for a specific IP, if the
> Windows box chooses another one, it's not getting any traffic back.
> 
> I consider this a security relevant choice, if I have "half-trusted"
> users, tap isn't really an option.

I would agree that tun is a better choice for less than fully-trusted users.

> Background for the challenge is that OpenVPN might be useful as an
> additional security layer on top of WLAN-WEP, but tap somewhat defeats
> the purpose.
> 
> > I think that Windows users are going to prefer a tap interface anyways,
> > because it carries the kind of traffic and protocols which Windows
> > applications generate, such as broadcast traffic and non-IP protocols.
> 
> I for one don't need Windoze broadcast traffic gated, and "my" Windows
> boxes hardly generate non-IP traffic. IPX or NetBEUI drivers aren't
> installed on the Windows machines I maintain. ARP isn't needed. Granted,
> if you need IGMP, you'll want tap, but I'd guess that the SMB browsing
> can deal with most of the "problems".

I totally agree that a tun driver for Windows would be nice to have.  In fact
I would guess that the TAP-Win32 driver might even be close to the task, if
you could figure out the right DDK magic to export a point-to-point WAN
interface that binds to IPv4 instead of 802.3.  Interested in doing some
driver development?

James

On Tue, 16 Sep 2003, James Yonan wrote:

> > I'd like to challenge the "better" claim:
> 
> I mean "better" only in the sense of simpler configuration -- i.e. not needing
> to set up a WINS server to make cross-subnet browsing work.  I agree that tun
> is more scalable, secure, etc.

After being through setting up a tap for a particular configuration
(pure ethernet with fallback to OpenVPN-on-WLAN), tap isn't easier to
configure than tun either. --ifconfig is one reason, although it's going
to get competition, getting routing right if you "tap" one IP into an
existing eth subnet is non-trivial and requires like 4 lines of --up
scripting.

My Linux distro also defaults to ethertap rather than tun, so if you're
running SuSE, better make sure you load the "tun" module early. ethertap
won't work with tun at the other end of the pipe -- different framing
apparently.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

On Tue, 16 Sep 2003, James Yonan wrote:

> While I do believe that the majority of Windows users will prefer a tap
> interface, I say this simply because in my experience _most_ Windows users
> prefer the option that is the easiest to configure.  Once you stop
> automatically routing broadcasts and non-IP protocols, then you have to start
> doing more configuration on Windows, i.e. setting up WINS servers and clients,
> configuring samba differently, etc.

Would the TUN device really be much different from any random PPP
device? Either is a point-to-point connection. Granted, with current
Windoze versions, SMB and all that stuff isn't bound to PPP devices by
default but is likely that the user wants it bound to TUN, however,
there are convenience features like --ifconfig.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Matthias Andree <ma+ovpnd@...> said:

> On Tue, 16 Sep 2003, James Yonan wrote:
> 
> > While I do believe that the majority of Windows users will prefer a tap
> > interface, I say this simply because in my experience _most_ Windows users
> > prefer the option that is the easiest to configure.  Once you stop
> > automatically routing broadcasts and non-IP protocols, then you have to start
> > doing more configuration on Windows, i.e. setting up WINS servers and clients,
> > configuring samba differently, etc.
> 
> Would the TUN device really be much different from any random PPP
> device? Either is a point-to-point connection. Granted, with current
> Windoze versions, SMB and all that stuff isn't bound to PPP devices by
> default but is likely that the user wants it bound to TUN, however,
> there are convenience features like --ifconfig.

Yes, tun and ppp are very similar.  I know that the linux tun driver basically
just sets the ppp bits and the kernel does most of the work.

Windows kernel hacking is more complicated, as it requires a great deal more
support code to do even simple things.  I just did a wc *.[ch] on the source,
and ...

TAP-Win32 -- 3061 lines of code for TAP only
Linux TUN/TAP -- 699 lines of code for TUN and TAP

Incidentally, beta8 has an expanded --ifconfig function that works on both tun
and tap devices (including tap devices on windows).  It also has a --route
convenience function that figures out the appropriate per-platform syntax for
route, and it too works on windows.

James