[vpn-help] VPN Client Road Map Modifications ...

[Peter Eisch]

On 9/7/06 7:22 PM, "Matthew Grooms" <mgrooms at shrew.net> wrote:

> All,
> 
> With version 1.1 of the VPN Client on the horizon, I wanted to make an
> announcement concerning some recent changes to the 'VPN Client Road Map
> and Future Versions' page of the website.
> 
> http://www.shrew.net/vpn/todo.php
> 
> The page is now a more accurate representation of the current
> development plan and goals. If you have reviewed the Road Map recently,
> you may have noticed that a 2.0 release involves changes to the kernel
> driver architecture. After some serious thought, I have decided to fast
> track the new architecture in an effort to correct certain design flaws
> of the 1.x series.
> 
> As the VPN Client has matured, the user-land components have seen a
> great deal of improvement. The kernel driver components were completed
> and stabilized as early as possible and have remained mostly unchanged
> during the life of the 1.x series. While the simplistic nature of these
> drivers was a win for quick implementation and stability, they simply do
> not offer flexibility that future products require. A more forward
> looking model has been chosen and an initial implementation has been
> developed.
> 
> Current Driver Architecture :
> 
>  IPSECC
>  IPSECD
> ==========
> IP | VPROT
> ----------
> NIC | VNET
> 
> In this diagram, everything above the double line is a user-land
> component and everything below is an NDIS kernel component. The VPROT
> driver is an NDIS Protocol driver that sits parallel to the MS TCP/IP
> driver. The VNET driver is an NDIS Miniport driver that sits parallel to
> other network card drivers. The VPROT driver is used to send and receive
> public traffic and the VNET driver is used to send and receive private
> traffic.
> 
> Future Driver Architecture :
> 
>  IPSECC
>  IPSECD
> ==========
>    IP
> ----------
>   VFLT
> ----------
> NIC | VNET
> 
> As you can see, the new kernel driver architecture is quite different.
> The major change is that the NDIS Protocol driver has been supplanted by
> an NDIS Intermediate Filter driver. Since an Intermediate driver sets
> between NDIS Protocol and Miniport drivers, the client will now be able
> to interact with packets that are passed to Miniports other than VNET.
> The second advantage is that packets can be injected below the MS TCP/IP
> layer and intercepted before they are allowed to pass back up to higher
> level protocols. Lastly, VNET can be dumbed down to nearly a do-nothing
> stub driver as all traffic inspection and redirection can be handled at
> the Intermediate driver layer.
>

Does this mean that the pcap apps (ethereal, tcpdump, etc.) will be able to
latch onto the driver and sniff too?

Getting the driver blessed would be quite nice touch.

Good work Matthew,

peter