[Vpn-help] Cisco Client Access Rules

[NMaio at guesswho.com]

Matthew,
Thank you for the response.  I believe we might be talking about two different things though.  What I am referring to is the fact that with PIX/ASA version 7 and up you have the ability to restrict a client from access to the gateway if the version number of the client is not correct.  VPNC has a way to send anything you want which means you can make it look like it is an actual Cisco client even though it is not.  The shrew client "appears" not to send a client type or version so if you are restricting to specific client versions the shrew client will not work unless you allow all clients.

Here is the command I am referring to.  This is not acls applied to the traffic from a client...it is just restricting the client version.
http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/c4.html#wp2118499

Here is a thread of what I am referring to in the VPNC client.  The config directve is "Application Version"
http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2007-February/001342.html

Thanks for your help.
Nick


________________________________________
From: Matthew Grooms [mgrooms at shrew.net]
Sent: Saturday, December 12, 2009 3:09 PM
To: Nicholas Maio
Cc: vpn-help at lists.shrew.net
Subject: Re: [Vpn-help] Cisco Client Access Rules

NMaio at guesswho.com wrote:
> Does anyone know if it is possible to set the Shrew Client to use a
> client type and version number?  I use client access rules on our PIX
> and ASA but due to the fact that the shrew client doesn't send a client
> or version type I am forced to allow all clients for some groups.
> Thanks in advance.
>

IPsec VPN Clients sends a Vendor ID hash value to inform a peer when an
optional feature may be available for use. Most of what allows an IPsec
VPN client to work are 'optional' with respect the the RFCs. In fact,
Xauth and modecfg are actually informational drafts which never made the
RFC standards track. I suspect that the problem you are experiencing is
related to the local security policy enforcement feature provided by the
Cisco VPN client.

Anyhow, back to vendor IDs. Some vendors use a ID hash value to identify
a specific version of a product. This implies a whole subset of features
that it expects to be available. In the case of Cisco products, this is
certainly true. However, as far as I know, using a particular vendor ID
string has nothing to do with negotiating local client security policy.
That is actually handled after phase1 negotiations complete and during
the modecfg negotiation process. Although the Shrew Soft VPN client does
send a Cisco unity vendor ID string, it doesn't support negotiation of
any client security policies ( ie. firewall rules ). When a PIX or ASA
is configured to require that the client support local security policy
enforcement, the gateway will disconnect the client.

I have read similar assertions to yours related to vpnc ( unix command
line cisco compatible vpn client ) sending a 'client type and version
number' to work around one issue or another. If anyone has documentation
about this option, feel free to point me at it and I will have a closer
look. Maybe they send an incredibly old Cisco Unity version string that
pre-dates the security policy enforcement feature to work around the
issue ... but thats just a wild guess.

-Matthew