12-21-2011 06:05 AM
I've got an SA4500 set up & functioning, and we're using NetworkConnect. The OS we're using is 6.5, and the browser I'm using is FireFox 3.6.24 running on winXP SP3. When I go to run NetworkConnect, it installs just fine. According to the User Log, my session receives an IP, then 30 sec later (exactly) it closes the connection, with 0 bytes written, and 339bytes read. During this time, the Event Log indicates AUT24604 - SSL negotiation failed while client at source IP '10.10.10.10' was trying to connect to '22.214.171.124'. Reason: 'sslv3 alert Certificate Unknown'.
The SSL cert is fully trusted by WinXP, and the cert's been imported into the Certificate Store for FireFox.
This isn't a NetworkConnect ACL issue, because others can attach to NetworkConnect just fine (it's just that I can't...)
I've seen a solution on the Internet that said something about competing versions of Juniper apps on the client. --I installed tihs on a winXP system that's never seen a shred of Juniper SW in its life. I also saw info about NetworkConnect trying to use a certificate (or attributes from a certificate), during authentication, which is why NC doesn't work. (I can log in to the IVE just fine (with browser SSL) , it's just that NC won't negotiate SSL... Any ideas?
Solved! Go to Solution.
12-21-2011 06:38 AM
That error message on the device _should_ (doesn't mean it won't) not have anything to do with why Network Connect can't stay up. What is the message you see as a user (nc.windows.app.xxxxx)? What are the other log messages surrounding your user entry?
12-21-2011 07:46 AM
Here's the user-log entry for my failure. I include an 'additional' entry from 'sam-user' in the middle, showing a 'key-exchange' entry that my user (sam-user) never sees.. I never get any errors in the log, except for the SSL negotiation error..
Info NWC23465 2011-12-20 23:04:18 - ive - [126.96.36.199] joe-user(Users)[Users] - Network Connect: Session ended for user with IP 10.10.10.10
Info ERR24670 2011-12-20 23:04:18 - ive - [188.8.131.52] joe-user(Users)[Users] - Network Connect: ACL count = 0.
Info JAV20023 2011-12-20 23:04:18 - ive - [184.108.40.206] joe-user(Users)[Users] - Closed connection to TUN-VPN port 443 after 30 seconds, with 339 bytes read (in 1 chunks) and 0 bytes written (in 0 chunks)
---------> I never get this-----> NWC23508 2011-12-20 20:57:57 - ive - [220.127.116.11] sam-user(Users)[Users] - Key Exchange number 1 occured for user with NCIP 10.10.10.10
Info JAV20021 2011-12-20 23:03:48 - ive - [18.104.22.168] joe-user(Users)[Users] - Connected to TUN-VPN port 443
Info NWC23464 2011-12-20 23:03:48 - ive - [22.214.171.124] joe-user(Users)[Users] - Network Connect: Session started for user with IP 10.10.10.10, hostname joe-user-computer
Info ERR24670 2011-12-20 23:03:48 - ive - [126.96.36.199] joe-user(Users)[Users] - Network Connect: ACL count = 1.
Info AUT22670 2011-12-20 23:03:32 - ive - [188.8.131.52] joe-user(Users)[Users] - Login succeeded for joe-user/Users from 184.108.40.206.
Info AUT24326 2011-12-20 23:03:32 - ive - [220.127.116.11] joe-user(Users) - Primary authentication successful for joe-user/RSA-server from 18.104.22.168
12-21-2011 07:52 AM
Do you see the tunnel establish on the client? Or does it remain in a "connecting" state? What type of message do you see as a user?
If you are negotiating at SSL rather than ESP you would not see the key exchange message (based on what you have posted you should be hitting ESP, though, yes).
12-21-2011 09:29 AM
I don't have access to the client system right now, since I'm at work (and the client is at home), so I can't tell you the nc.windows error number. I'll need to check w/ the other network engineers to see if U/4500 is open inbound, on the server-side. I'll need to gather more info on this when I get home & I can touch my test equipment...
12-21-2011 11:25 AM
Forgot to mention: Is NetworkConnect dependant on the IPsec Policy Service in windows? We disable that service to make things leaner. I'll try enabling that svc the next time I'm in front of my test client.
12-21-2011 05:30 PM
SOLVED: Confirmed on two computers. if the Windows DHCP Service is stopped, and set as Disabled, NetworkConnect will not properly obtain its IP. Enable DHCP, and NC comes right up. I actually stumbled upon this... Nothing in the logs I was seeing, indicated at ALL that NC had issues obtaining an IP.
12-22-2011 05:56 AM
Yes, that is correct: DHCP needs to be enabled so that the client can receive an IP.
There should have been a message on the client indicating an issue with the configuration; the client-side logs do show that this would have been the problem.
Thank you for confiming you have resolved the issue.
01-08-2012 07:21 PM
...meaning to say that client VPN connection does require a DHCP service on the laptop to establish the VPN connection....
JNCIA-JUNOS, JNCIS-ENT/SEC, JNCIP-ENT
(CCNA, ACMP, ACFE, CISE)
CONNECT EVERYTHING. EMPOWER EVERYONE.
Share & Learn. Knowledge is Power.
"If there's a will, there's a way!"
01-09-2012 06:38 AM
Yes, you are correct. The VPN client, Network Connect, receives an IP from the IVE using DHCP (regardless of how the IPs are set on the SA unit, the client gets IP using DHCP). If the client PC can't process/handle that DHCP component, for example if DHCP client service is disabled, an IP can't be assigned and Network Connect will error out.
02-22-2012 02:54 AM
Please let me make this inquiry what does the log messages below refer too:
ID= ERR24670 Network Connect: ACL count = 0
client keeps complaining of loosing connection when accessing local resources via SSL.
02-27-2012 07:01 PM
The events log will tell you when you are close( it should have nothing to do with disconnects.