SonicWALL PRO 2040 VPN issues

yes I have updated all to the latest that we have 4.0.0.830
the users are mostly on comcast and they all have dynamic IP addresses, so it follows that comcast will switch their Ip addresses, I imagine once every few months or whenever the leases expire on them.

When the users log on, you can see their connections on the sonicWall active VPN users section?  Using an AD server, or is the SonicWALL the one handing out the VPN IPs?

If they are connecting, and staying connected, but unable to connect to anything in network, and they show on the sonicWALL, it seems like they are getting an odd IP/subnet/dns/etc.  Have the users do an ipconfig /all and send to you, and compare the tunneling IPs to what your network looks like.

From there, you can check what your AD servers are leasing out / SonicWALL attempts to lease out, etc.

had an issue like this, the sonicwall dhcp client was assigning IP addresses that were already being used on the network
i had to assign machines with static ip's to have new ones

answer to your first question: yes, you can see them as online under users in the sonicwall
answer to your second question: sometimes the ipconfig /all for the sonicwall adapter shows all 0.0.0.0

sometimes is shows the correct internal LAn address (they can connect during that time)

if it shows 0.0.0.0 then do a renew in the client properties of the VPN client

checking the vpn client. Sorry I can;t seem to find how to "renew" in the client properties of the VPN client.

That means the underlying problem is whatever is handing out IPs to the VPN clients.  That's not handing it out correctly.
Is the SonicWALL or something else handing out the (i'm guessing) DCHP IPs?

and yes, ccpjc's answer will fix the problem for only that one instance.  But I'm pretty sure you don't want to sit there and reset people's IPs all day/night.

you can simply to do a "ipconfig /renew" in a command prompt when you are connected to the VPN for that.

yes the sonicwall is handling all DHCP.

Our windows sbs 2003 server handles AD and DNS requests

Right click on the Icon in the taskbar beside the clock -> Open SonicWall VPN Client
double click on the current connection, then at the bottom of the status tab you will see 'Renew'

Justicator:
That means the underlying problem is whatever is handing out IPs to the VPN clients.  That's not handing it out correctly.
Is the SonicWALL or something else handing out the (i'm guessing) DCHP IPs?

and yes, ccpjc's answer will fix the problem for only that one instance.  But I'm pretty sure you don't want to sit there and reset people's IPs all day/night.

-- I already posted my experience with it, about the VPN client assigning IP's to computers with them already on the network, haven't heard anything back yet

another thing is to exclude those that are static assigned on the network from the SonicWall DHCP Server

ccpjc:
did as you stated. Connected to VPN -

In the windows Virtual IP Configuration
IPaddress N/A Subnet mask N/A
"Renew" button greyed out

ccpjc:  Huh?

I forgot to post:

In advanced for the VPN

 Enable NAT Traversal:  (yes)
Keep Alive interval: 240  
Enable IKE Dead Peer Detection: (yes)
        Dead Peer Detection Interval: 60      
        Failure Trigger Level: 3      
VPN Single Armed mode (stand-alone VPN gateway) NO
  Clean up Active tunnels when Peer Gateway DNS name resolves to a different IP Address YES
 Preserve IKE Port for Pass Through Connections NO
 Send vpn tunnel traps only when tunnel status changes NO

ccpjc:
I was refering to this comment you made below.....
my reply to you comment was essentially the "renew" button was greyed out so I could not "renew" as you indicated

"Expert Comment      
Was this comment helpful?
Yes No
ccpjc:
Right click on the Icon in the taskbar beside the clock -> Open SonicWall VPN Client
double click on the current connection, then at the bottom of the status tab you will see 'Renew'"

One at a time!  hahah..  i'm so confused with which answers go where.

I'm going to have to dig around my SonicWALL a tad to find it when I have a chance.

Sorry that comment was posted for Justicator and you to try not in relation to the greyed out part

are you trying the VPN client from within your network, the new version won't allow this

@ccpjc : no worries
I have a laptop connected to a third party wireless to conduct the current VPN excitment.

ok let's try doing this from the start

Delete your VPN settings from the GVPNC
Add a new connection, verify the IP is correct
Make sure you have the correct PreShared key, you can find it in the SonicWall GUI under VPN -> GroupVPN, it will either be called Shared Secret or PreShare Key depending on the version

Double click the vpn connection to start, it should show Connecting, then change to provisioning, then acquiring IP, then finally connected
Once connected, it should pop up a balloon to show you are connected and your VPN IP address
if not then try going back into the Status screen and doing a Renew

Post results

Delete VPN settings check
add new connection to correct ip - check
preshared key known (sonicwall router open presahred key dispalyed

double click on vpn connection
prompted for preshared key -entered

enter username /password box
enter successfully twice

vpn status is "connected"

networking icons in systray appear with the little gold ball moving back and forth...

Below is the connection details from the VPN client log


2009/03/19 09:11:28:852      Information      67.95.*.*      Starting ISAKMP phase 1 negotiation.
2009/03/19 09:11:28:898      Information      67.95.*.*      Starting aggressive mode phase 1 exchange.
2009/03/19 09:11:28:898      Information      67.95.*.*      NAT Detected: Local host is behind a NAT device.
2009/03/19 09:11:28:898      Information      67.95.*.*      The SA lifetime for phase 1 is 28800 seconds.
2009/03/19 09:11:28:898      Information      67.95.*.*Phase 1 has completed.
2009/03/19 09:11:28:914      Information      67.95.*.*      Received XAuth request.
2009/03/19 09:11:28:914      Information      67.95.*.*      Sending XAuth reply.
2009/03/19 09:11:28:914      Information      67.95.*.*      Received XAuth status.
2009/03/19 09:11:28:914      Information      67.95.*.*      Sending XAuth acknowledgement.
2009/03/19 09:11:28:914      Information      67.95.*.*      User authentication has succeeded.
2009/03/19 09:11:28:930      Information      67.95.*.*      Received request for policy version.
2009/03/19 09:11:28:930      Information      67.95.*.*      Sending policy version reply.
2009/03/19 09:11:28:930      Information      67.95.*.*      Received policy change is not required.
2009/03/19 09:11:28:930      Information      67.95.*.*      Sending policy acknowledgement.
2009/03/19 09:11:28:930      Information      67.95.*.*      The configuration for the connection is up to date.
2009/03/19 09:11:28:992      Information      67.95.*.*      Starting ISAKMP phase 2 negotiation with 198.68.70.0/255.255.255.0:Any:Any:N/A.
2009/03/19 09:11:28:992      Information      67.95.*.*      Starting quick mode phase 2 exchange.
2009/03/19 09:11:29:008      Information      67.95.*.*      The SA lifetime for phase 2 is 28800 seconds.
2009/03/19 09:11:29:008      Information      67.95.*.*      Phase 2 with 198.68.70.0/255.255.255.0:Any:Any:N/A has completed.
2009/03/19 09:11:29:008      Information      67.95.*.*      NetWkstaUserGetInfo returned: user: bigmon, logon domain: snoops, logon server: disk

Ok so you are connected now right?

Can you access network resources?
If it says access is denied, go into the the AD and make sure your account hasn't been locked out from too many attempts

What are your current DCHP settings on the SonicWALL?
Good policy states that you should have a range setup especially for DCHP, but conflict detection should take care of that without a problem.

The problem still is where your users are getting no IP addresses assigned to them, which I still think is it trying to contact the AD server for a DHCP address.

You can go this way (which I prefer):
Set your AD server to hand out DCHP exactly like your sonicWALL is doing, and set up your sonicWALL to point towards your AD server in the DNS pic as below.

Or, make sure your route policy is setup correctly.  See pics also.

@ccpj

attempting to login to LAN resources via Remote desktop: "this computer can't connect to the remote computer"

ipconfig /all reveal that the sonicwall is coming up 0.0.0.0

@justicator

The dhcp(which is on sonicwall) is setup from .50 to .254  All workstations on the LAN have manual ip addreses. they start at .100 and goto .175

and the renew button is still greyed out?

In the actual SW GUI, when you click on the VPN properties and goto Client, is the Virtual Adapter setting set to DHCP lease?
And if you goto Network -> DHCP server and see the scopes, are there any listed there?
if not add a dynamic

@ccpjc

yes the renew button is still greyed out.

No the virtual adapter setting was set to "none"

yes the scope is from .50 to .254 on the LAN

change it from None to Lease and connect again
also change the score to something you know isn't static or dynamically assigned
like .100 - .150

scope *

in SW gui - leased is set
in sw gui DHCP scope is set to .50 to .59 (no static IPs)

attempt VPN connection
username and password - ok

then status stays on "cennecting"

Sonicwall virtual adapter icon appears in task bar (gold ball bounces back and forth)

In the properties of the GVPNC the renew button is no longer greyed out.

Sonicwall hangs on finding IP address, so I click on "renew" button - no effect

Ok it sounds like you are already using aggressive mode on your tunnel correct? On the sonic wall you are sitting at, it has a unique name usually the serial #, and whatever you are connecting to it has a unique name. name the tunnel whatever name of the device is your connecting to. make sure you are in aggressive mode, set the default gateway to 0.0.0.0 set the local IKE as your unique name and the remote IKE to the remote unique name.