[vpn-help] Client to NetScreen fails xauth when using static configuration
mgrooms at shrew.net
Wed Jan 5 11:34:31 CST 2011
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
> 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
> 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
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,
More information about the vpn-help