nc.windows.app.23791

[dusannovakovic_]

Yo, everyone knows this error - and everyone hates this errormessage.

Beyond the "known" tips and tricks (check personal firewall, install windows patch for loopback ip-address issue, unmark automatic proxy settings in browser...) can anyone explain why this error sometimes comes when user FIRST TIME clicks the "START" button on Network Connect windows, but when the user clicks AGAIN on the "START" button, NC is able to start a vpn connection? Strange thing....

Any other tips how to handle this wellknown and awfull error message?

[Jickfoo_]

I was getting this error because the users were trying to go out to crl.verisign.net to check the cert during login. Our dial-up provider was blocking this access. This "feature" can be shut off in the browser.

Anyway, this is what our problem was but I know it can be many many things and I feel your pain. All I can say for sure is that something is being blocked. This error is almost always about firewalling or ACLs blocking specific conversations.

[routerwitch_]

Here is what I have found. When you have two overlapping IP pools in your profiles, you can get users stepping on each others addresses. If pool #1 is trying to assign an IP to a client, but that IP is in use because it was assigned out of pool #2, you will see this error. I recommend checking your profiles to ensure that you don't have a conflict.

Hope that helps,

Lucas

[Notch_]

I recently took over Admin duties for my company's Juniper VPN platform. I've had no previous experience on this platform, but how hard can it be? So I thought. I had a couple users who were getting the dreaded 23791 dialog box, and no amount of tracing or log file examination gave any indication of what the problem might be. Now I'm beginning to understand how much fun this platform can be.

Anyway, the problem turned out to be with the configuration of the "Resource Policies/Network Connect/NC Connection Profiles". There were several profiles configured here, but none of them were associated with the "role" that the problem users were assigned to. Basically, there was no IP Pool that they could be assigned an IP address from. I've also learned that the same symptom can occur if the IP address pool for a NC Connection Profile is exhausted (no free addresses remain in the pool).

Obviously when that happens the NC client should huck a generic 23791 error and the VPN server shouldn't log a descriptive message like "no ip pool defined for user x in role y" - that would be too helpful (pardon the sarcasm).

Some may say it's my own fault for not associating the role to a NC profile, and I would agree if I had initially set this up, but I inherited it and was left to fend for myself.

Hopefully others may benefit from my experience.

Message Edited by Notch on 03-03-2009 05:46 AM

[spacyfreak_]

well, i hope it gives you some solace, but when you try configuring other remote access devices like ASA or Citrix AG, you will find lots of other "issues" which can make your admin life sad.

In comparison i find juniper ssl-vpn box really easy to use - but very very flexible.

[jainanik_]

It was pretty cool to see this

2011-05-10 09:56:16 - XXX - [Y.Y.Y.Y] XXXXXXXXXXXXXXXXXX (Realm)[Role] - Network Connect: IP address cannot be allocated to user XXXXXXXXXXXXX. Solution: Check IP Address Pools / DHCP server state.

[zanyterp_]

I haven't seen that one yet; only when it is just down. Do you see anything in the user access log the first time that shows failure? What does your policy trace show for the differences? What does the client log say?