We are looking to implement NetConnect as our client VPN solution. However, I have been unable to integrate the NetConnect solution with our DHCP/DNS environment. In our environment, the DHCP server provides the workstation name/IP information to the DNS server. This is failing in our lab. The IP is assigned correctly, but the device name (from the IVE) being provided to the DHCP server is not correct. A capture of the traffic consistently shows an entry similar to Option: (t=12,l=48) Host Name = "useruid84f8c519de2e3b1e717f2ac410ccd2592740dcb7" and this is what is being recorded on the DHCP server. I have tried multiple remote devices and received similar results. JTAC says this is a known bug, but I cant imagine all NetConnect environments live with incorrect DNS entries. Is there a workaround or do I need to change something in the DHCP or IVE configuration. Thanks. DWizard
Why not allow the client to register to DNS and get rid of the middle man? Or, you could create a NC Login script that issues the simple command
that should kick up a registration request from client to DNS Server..
This has always been a problem for us. Cleaning up stale records is not easy. Microsoft has DNS Scavenging but unless they've improved it in the last version it isnt very good. Maybe you can get it working better then we did.
Its possible that when new clients register with an IP Address that already has a stale record attached that they will automatically remove the previous record. You'd need to test that.
NC does have a session ending script but I dont know of a Windows command that will remove its own DNS Record.
At one time I was discussing this same issue with a colleague at another company. He actual went to the extreme of assigning each of this 3000+ remote users static VPN IP Addresses. Kind of crazy but very effective when it comes to name resolution.
Yes, this is a known issue. SA sends User ID instead of hostname. Its is getting fixed in 6.3R5 and 6.4R2 releases.
In the fixed buids,
1. SA device will send client hostname as a DHCP option in DHCP requests for NC.
2. SA wont send a dhcp release packet after a NC session ends.
3. SA will keep the user record for NC users in all cases for 24 hours since last NC access.
So the DHCP server should configured in such a way that it purges the NC IP records after 1 day for as SA wont send a release packet (This is DHCP server side settings). Other wise all the IP's in the pool might get consumed if the users login from multiple PC's like public internet kiosks.
Please wait for these releases and upgrade to them.
do you know when the Release 6.4.R2 or 6.3.R5 will be available?
Thank for information.
Just found out Juniper has reintroduced this problem and they have no plans on fixing it. Engineering request denied. No explanation.
My argument is simple. If I have a system that is not configured to send a DHCP release packet then why do I want the NC client to do it? At most this should be an option that can be configured in the IVE or NC client, otherwise by DEFAULT the NC client should do nothing when the IVE is configured to use an external DHCP server.
There is a very good reason for the SA to send the DHCP release packets.
What happens when the client times out? What happens when the NC doesnt disconnect the session cleanly?
Would you like to share the 'very good reason'? I haven't recevied an explanation from Juniper.
Page 627 in IVE 7 Admin. Don't know if this is true. Seems Juniper is flip flopping on this.
"NOTE: The SA Series Appliance does not send a DHCP release to the DHCP server after
the Network Connect session terminates.