[Openvpn-devel] Re: [Openvpn-users] Windows tun driver
Inode said: > Hi all, > I'm looking on the net for a tunnel driver for windows. Anyone found a > good working driver? I have to user OpenVPN from an OpenBSD and a > Windows, and OpenBSD (native) doesn't support TAP device... 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. My understanding is that a tap driver exists for OpenBSD that was ported from FreeBSD, but that it's still in an experimental, somewhat unfinished state and needs a good kernel hacker to bring it up to the standard of the rest of the OpenBSD networking subsystem. 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
[Openvpn-devel] RE: [Openvpn-users] Windows tun driver
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
[Openvpn-devel] RE: [Openvpn-users] Windows tun driver
Bert Shuler 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
Re: [Openvpn-devel] Re: [Openvpn-users] Windows tun driver
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
Re: [Openvpn-devel] Re: [Openvpn-users] Windows tun driver
Matthias Andree 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
Re: [Openvpn-devel] Re: [Openvpn-users] Windows tun driver
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
Re: [Openvpn-devel] RE: [Openvpn-users] Windows tun driver
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
Re: [Openvpn-devel] RE: [Openvpn-users] Windows tun driver
Matthias Andree 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
