[Vpn-help] New 2.2.0 alpha available ...

[Matthew Grooms]

All,

I just posted a 2.2.0 alpha 1 release on the download page. Unlike a 
stable release, it contains new features and aggressive changes for 
those interested in testing or early adoption. Here is a brief synopsis 
of one of the more interesting new features ...

For a while now I have been trying to devise a method to improve support 
for gateways that do not provide automatic configuration for clients. In 
particular, a gateway that does not support virtual adapter address 
assignment can be very troublesome for client connectivity. As a result, 
the 2.2.0 version supports a new adapter option called "Use a virtual 
adapter and random address". As a programmer, I initially cringed at the 
thought of using random address values to ensure the proper operation of 
the client software. Its the type of idea that keeps us up at night :) 
But without gateway participation, the alternative methods of manually 
assigning per-client addresses or using the direct adapter mode is 
actually quite a bit less desirable.

Please note: These problems are not unique to the Shrew Soft VPN Client. 
For a bit of background, first read the documentation section entitled 
Private Address Configuration. It describe the difference between direct 
and virtual adapter modes which is typical for any modern VPN client 
software offering ...

http://www.shrew.net/vpn/help-2.1.0/vpnhelp.htm

With a 2.1.x client, using the virtual adapter mode without a gateway 
assigned virtual address is difficult to manage. Every client installed 
must specify a unique virtual address or there will be conflicts when 
more than one client attempts to connect simultaneously. The reason for 
this is that the gateway must track IPsec Policies and SAs using source 
and destination IDs. The ID values consist of the private network 
address used by the client and the private network the client is 
attempting to communicate with. When a client is assigned a unique 
virtual address, the IDs will be unique for each client. When virtual 
address assignment is not possible, a conflict is more likely to occur.

Lets assume the client host is assigned a DHCP address of 192.168.0.1/24 
by a SOHO Firewall that performs NAT and the gateway is configured with 
a 1.2.3.4 address. The VPN client is configured to communicate with the 
10.9.9.0/24 network which is protected by the VPN gateway. The gateway 
IPsec policies will look different depending on which adapter mode is 
usable by the client.

A gateway policy pair will typically look something like this ...

IN  = CL-PUB-ADDR -> GW-PUB-ADDR ESP / ESP CL-PRV-ADDR -> GW-PRV-NET
OUT = GW-PUB-ADDR -> CLIENT-PUB-ADDR / ESP GW-PRV-NET -> CL-PRV-ADDR

Gateway cannot assign virtual addresses
=======================================
Both of the following scenarios are prone to failure. In Direct Adapter 
Mode, two clients could be connecting from behind different SOHO routers 
using the same private network address scheme. The addresses can be the 
same because NAT hides these duplicate private addresses behind a unique 
public address. But when IPSEC SAs are negotiated using IKE, the real 
private address values are always used which makes them un-unique. With 
Virtual Adapter Mode, the same problem can occur if two clients attempt 
to use the same Virtual adapter address.

Direct Adapter Mode ( DHCP:192.168.0.1 could be a duplicate )
------------------------------------------
IN  = SOHO-NAT-ADDR -> 1.2.3.4 ESP 192.168.0.1/32 -> 10.9.9.0/24
OUT = 1.2.3.4 -> SOHO-NAT-ADDR ESP 10.9.9.0/24 -> 192.168.0.1/32

Virtual Adapter Mode ( STATIC:192.168.254.1 could be a duplicate )
------------------------------------------
IN  = SOHO-NAT-ADDR -> 1.2.3.4 ESP 192.168.254.1/32 -> 10.9.9.0/24
OUT = 1.2.3.4 -> SOHO-NAT-ADDR ESP 10.9.9.0/24 -> 192.168.254.1/32

Gateway assigns virtual addresses
=================================
The following scenario will always work correctly because the virtual 
adapter address, assigned by the gateway, is guaranteed to be unique.

Virtual Adapter Mode ( UNIQUE-ADDR is never a duplicate )
------------------------------------------
IN  = SOHO-NAT-ADDR -> 1.2.3.4 ESP UNIQUE-ADDR/32 -> 10.9.9.0/24
OUT = 1.2.3.4 -> SOHO-NAT-ADDR ESP 10.9.9.0/24 -> UNIQUE-ADDR/32

By offering a new mode that randomizes the Virtual adapter address, the 
gateway policies have a much lower likelihood of being duplicates for a 
given client connection. Again, this is only relevant when a gateway is 
incapable of assigning the a virtual adapter address which is always the 
best option.

If you consider that there are only a few popular vendors that offer 
inexpensive SOHO routers that perform NAT ( Linksys, Netgear, D-Link ), 
each router comes pre-configured with the same private network address 
scheme ( 192.168.0.0/24, .1/24, etc ) and a typical SOHO network will 
only have a handful of devices connected to it, the odds are quite good 
that two clients will use the same private address using a direct 
adapter mode. With the virtual adapter mode and a randomized address 
with default settings, there is a 1 in 131,070 chance that two clients 
will use the same virtual adapter address. The odds of a conflict 
increase when more clients are connected to the gateway simultaneously.

Unfortunately, there is no infallible way to support client connectivity 
with low end consumer SOHO routers. The difference between devices that 
support virtual address assignment and ones that don't are often only 
$50 to $100 dollars more. For example ...

Netgear FVS318 ( $129.99 )
No support for Xauth or Automatic Client Configuration

Netgear FVS338 ( $199.99 )
Supports Xauth and Automatic Client Configuration via Modecfg

This is NOT a product endorsement. I would only encourage those looking 
to support client connectivity to consider these features before buying 
or upgrading a VPN appliance. That is, if you don't plan to use Linux / 
BSD as your firewall / gateway. For those stuck with less sophisticated 
devices, this new adapter addressing mode should allow for a reasonable 
level of service when only a handful of client connections are required, 
and additionally, reduce the amount of manual administration.

Thanks,

-Matthew