[vpn-help] -12 against ipsec-tools 0.6.6

Matthew Grooms mgrooms at shrew.net
Fri Aug 11 11:36:09 CDT 2006


Peter Eisch wrote:
> 
> We're getting mixed results.  Brian's system works fine, my lab desktop is
> throwing fits.  He's now taken the helm of my desktop to see if he can make
> it happy.  Please stand by...
> 
> Yes, on his the metric appears with '1' and his works swell.
> 
> Reflecting back to a different thread, how would this be any different with
> a dialer/modem than with a LAN?  Is there anything in how you fiddle routes
> that's different on the Windows with a dialer?  (Yes, I have no clue about
> Windows programming since Windows 2.1.)
> 

Peter,

	I am sorry to say that the client will not communicate using a dialup 
adapter at the moment. This is one of several problems I plan to correct 
with the 1.1 code base.

	The Shrew Soft Client is a mixed mode IPSEC implementation similar to 
OpenVPN where the bulk of the work is handled in user space. Keeping 
things in user space allows for much easier debugging using standard 
tools and the obvious protection of not trashing kernel memory space 
when a bug is triggered.

	The OpenVPN product uses UDP or TCP for both key management and 
transport so it can rely on standard socket calls. An IPSEC product uses 
UDP for key management and ESP or AH ( traditionally ) for transport. 
Unfortunately, a user space application has no mechanism to communicate 
via ESP in the windows environment. A vendor must provide protocol 
support via an NDIS driver which binds directly to adapters and exposes 
the data to user space.

	So, the Shrew Soft VPN client has two kernel drivers. An NDIS nic 
driver to provide virtual adapter support and a NDIS protocol driver to 
speak raw IP. Since Win2K and XP come configured with their own IPSEC 
implementations enabled by default, a VPN client cant bind to the ISAKMP 
port without disabling the existing service. For this reason, the Shrew 
Soft Client implements its own mini IP stack and uses the custom 
protocol driver to speak UDP as well as ESP which allows it to co-exist 
more or less peacefully with the native service.

	This brings us to the answer to your question. An NDIS protocol driver 
must have support for all the underlying NDIS adapter types it is 
willing to bind to. At the moment I haven't had the time to write or 
test support for anything other than an Ethernet driver. Anyway, there 
you go. Probably more information than you wanted to know but I wanted 
to answer you question to the best of my ability as you are being so 
generous with your time ;)

Thanks again for your help,

-Matthew



More information about the vpn-help mailing list