One of my users is having problems with his NetExtender connection. After installing NetExtender from the portal, it connects fine -- ONCE. After that, attempting to reconnect gives

Verifying user...authentication fail!

and the log on the router shows:

[timestamp] | Info | SSLVPN | Auth Failed: No user name in http request (message id: 1079)

This seems odd to me because the user name, password and domain are entered on the NetExtender client. After this error occurs, the only way to connect again is to uninstall, reboot, and reinstall NetExtender. He can connect fine to the Sonicwall SSLVPN demo site, and a different user can connect fine to this site from a different PC. Any clues?


I wish I had a more complete answer for you, but I have the same problem, and it's not 100% resolved.

I have had some success with a simple reboot: close NetExtender, Reboot. Try again.

I have had some seemingly random success. I would just try and try and eventually it would work. I thought this might be related to time so I checked the config on the firewall and DC and everything was in perfect sync, so I don't think that is the issue.

This problem seemed to start after enabling LDAP+LocalUsers Auth (was LocalUsers). It is possible the problem is related to Auth scheme.

Another possibility I haven't been able to test yet, related to the above, is that the reason is related to the computer trying to connect not being a member of the domain. The workstations I am testing from are not domain joined (to the domain doing the LDAP auth). However, the issue is the same when using a "LocalUser" from the sonicwall device.

I have also tried the version of NetEx that gets installed from the portal, as well as the latest version from mysonicwall.

I hope some of those clues will help you.

|improve this answer|||||
  • Huh. Ok. So on a whim I tried enabling IPv6, and suddenly I was connected! However my other problem machine already had IPv6 on. So I worked a bit, checked a few things and got disconnected when I made a change on the server end. Tried to reconnect, failed. DISABLED IPv6 and it worked again first try. SO. Something that happens when you enable/disable IPv6 causes the connection to work again. Now we just need to figure out what, and why it's not happening automtically. – Aerankas Sep 6 '11 at 8:55

I know this is very after the fact, but I find that most NetExtender connection problems can be solved with one of:

If you're using a wireless NIC, /release /renew and reconnect. If you're using a wired NIC, connect, disable the network adapater, re-enabled the network adapter, reconnect.

I tend to use these two techniques to work around the issue of a connection dropping, and upon reconnection, only the "Sent" bytes counter in the SSL-VPN NetExtender client showing traffic while "Received" sits connects with about 600bytes received and just stays on that number.

I presume the "reboot" solution works because it cycles whatever cached credentials / ip adddress / auth token that the client isn't releasing, but when you cycle the NIC, it picks up on these changes.

I can't see any real avenue for a bug report though.

|improve this answer|||||

Coming back to explain my findings: this turned out to be caused by an old firmware on the Sonicwall device, incompatible with the latest NetExtender client, while the compatible client was incompatible with Windows 7.

Cox DNS hijacking was a significant confounding factor on the client end as well.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.