[vpn-help] Client to NetScreen fails xauth when using static configuration

[Matthew Grooms]

On 1/4/2011 9:41 AM, kevin vpn wrote:
> Hi all,
>
> I'm trying to configure Shrew and a NetScreen VPN in the following
> manner:  I want to use a static client configuration and XAuth
> together.
>
> Specifically I want to "Use a virtual adapter and assigned address" and
> to NOT "Obtain Automatically".  I want to specify the Address and
> Netmask manually (DNS too, but that does not seem to be an issue).
> However, I also want to use XAuth so that I can use an external
> directory for the users and passwords.  The NetScreen unfortunately
> requires modecfg to be on when using XAuth, so I also have to set the
> Auto Configuration in the Site config to "ike config push".
>
> When I set this up, I cannot connect.  It looks like Shrew does not
> like it when the NetScreen wants to proceed with client configuration
> despite the fact that Shrew is already configured with an IP address.
> The Shrew IKE log reports "user<username>  authentication failed":
>
...
>
> As soon as I change in the Site configuration to "Obtain Automatically"
> the Address and Netmask things work fine.  (The reason why I'm
> configuring the clients manually is a long story and probably is not
> relevant.)
>
> Does anyone know a workaround or way to tell Shrew to simply ignore the
> config parameters that the NetScreen is sending?
>
> The Shrew client is 2.1.7 on WinXP SP3 and the NetScreen is running
> 6.2.0r7.
>

Hi Kevin,

The client should only report an authentication failure if it receives a 
failure result from the gateway. Juniper devices will process xauth and 
then handle modeconfig before sending the status result. My guess is 
that the client isn't ack'ing the IP address and netmask values as you 
have configured it to not accept those parameters. The Netscreen is 
probably returning a failure because it doesn't see those attributes in 
the acknowledgment list and requires them to be present. Its difficult 
to differentiate user authentication failures from modecfg negotiation 
failures because these devices do not return a status result for each 
individual transaction ( which goes against the RFC draft BTW ).

I understand what your trying to do. My impression is that you want the 
client to lie about what attributes it has accepted and then use other 
values instead. While I perceive the utility in this, the client wasn't 
designed to provide this behavior. If you have reason to believe that 
the Juniper gateway is returning a success status and that the client is 
mis-interpreting this status ( gateway log output says otherwise ), 
please send me a packet dump of the decrypted IKE traffic using the VPN 
trace application and I'll have a look.

Just a suggestion, but I would think the Juniper device has provisions 
for assigning static IP addresses based on an Xauth user name. Usually 
you can add properties to your external authentication source account ( 
LDAP, radius, etc ... ) to force a specific static IP addresses value or 
name service parameters to be returned during modecfg negotiation.

Hope this helps,

-Matthew