SonicWALL Global VPN Client, DHCP Address Allocation

SonicWALL Pro 3060 firewall, SonicOS Enhanced, Global VPN Client x86 (all up to date).  Test client is XP Pro x86 with all updates.

Interface X0 = LAN
X1 = WAN
X2 = DMZ
X3 = WAN Failover
X4 = Guest WiFi
X5 = Unused

When a GVPN client connects, they're assigned an IP address from our internal LAN.  Unfortunately that network is 192.168.0.0/24.  Occasionally there's a clash with remote VPN connections, usually a home network that has the same 192.168.0.0 address.

I want the GVPN users to obtain an IP from a DHCP scope defined on the firewall.  Let's say that scope is 10.0.50.10 thru .99.

This EE Article seems to directly address my situation.  I've applied its concepts, using Interface X5 for a new "fake" subnet, 10.0.50.0/24.  The X5 interface is assigned IP 10.0.50.1.  I assigned the X5 interface to zone WLAN.  A new DHCP scope was created automatically.  

Then I changed the DHCP Over VPN properties on the firewall so GVPN clients obtain their IP from the firewall, with IP Relay Address 10.0.50.1 (X5).  I even connected a 10/100 switch to port X5 so the firewall wouldn't see that interface as having "no link".

When the GVPN client connects they get through all the Phase 1 and Phase 2 negotiation stuff successfully.  No errors.  The firewall shows a VPN tunnel, and it shows an IP assigned to the client from the correct DHCP scope.

But the client does not receive the IP address.  It sits there waiting for an IP but never receives one.  It finally times out.  I spent the better part of the day today messing with this and I cannot get the IP to the client.

If the same remote client uses a standard L2TP VPN client, like Windows, OS X Lion, or even iOS 5.0, they are successfully assigned an IP from the L2TP Address Pool, also on the firewall.  That pool is not on our LAN subnet, so everything is good.  

And as I mentioned before, if the firewall config says for the GVPN client to obtain an IP address from our LAN DHCP server, that also works fine.  But that's not the IP I want these clients to be using.

The obvious answer is "Don't use the SonicWALL VPN Client".  Well I have a few users who claim it's more reliable than other methods and doesn't ever drop the connection.  That may or may not be true, but that's what they say.  It's also much easier for users to set up themselves (with minimal coaching from IT).

Can anyone tell me what I'm missing?  I feel like I'm very close to making this work but some piece of the technical puzzle isn't in place.
LVL 13
IT-Monkey-DaveAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

digitapCommented:
Hello - What does your DHCP over VPN settings look like? I took a screen shot of one of my clients that is working properly. The IP defined is the gateway of the WLAN zone.
DHCP-over-VPN-Configuration---Mo.jpg
IT-Monkey-DaveAuthor Commented:
It's configured exactly like that except the Relay IP is 10.0.50.1, the IP assigned to Interface X5.
digitapCommented:
Do you currently have users accessing the WLAN zone internally?
Maximize Customer Retention with Superior Service

The IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more to help build customer satisfaction and retention.

IT-Monkey-DaveAuthor Commented:
No, WLAN has never been used for anything until now. It's exclusive to these Global VPN Client users (if we get it to work).

This seems like a possible routing issue. I played with static routes for WLAN and these clients today and nothing helped though.

Interesting that when the L2TP server is enabled, some NAT and firewall rules are created automatically. I tried replicating those for WLAN, X5, and the range of IPs in this DHCP scope, still no go.

I should mention that the X4 interface is wifi but not using the built in WLAN zone. I created a new zone "Wi-Fi" for that interface. Wifi users get their IP from another DHCP scope on this firewall.
Senthil KumarCommented:
I think you can continue with the Internal Server DHCP settings as i never faced a problem with GVPN clients from home or from another places that is using 192.168.x.x IP range. Disable the split tunneling and check.
digitapCommented:
OK, then that's probably you're problem. Go to the firewall rules and confirm the WLAN zone has access to the other zones; VPN, LAN, etc. It's disabled by default.
crouthamelaCommented:
Side note, this is probably the most eloquent question I've read ever. Props to you IT-Monkey-Dave
IT-Monkey-DaveAuthor Commented:
LOL, Thanks.  Truth is my OCD doesn't want to let this issue go unresolved even though we have an acceptable workaround, which would be to just not use the SonicWall VPN client.  There has to be a solution to this problem.
digitapCommented:
What was the firewall settings of the WLAN zone you are using to pass DHCP to the GVCs? Also, how are you authenticating the users? You'll want to make sure that you give them VPN Access to the zone where the WLAN zone servicing DHCP sits.
IT-Monkey-DaveAuthor Commented:
So I was working on this again this morning, and the firewall went blooey.  By that I mean suddenly there were address objects with corrupted names, the firewall forgot its WAN interface IP address, and everyone lost Internet access.  It was still corrupted following a reboot.  I had to restore the settings from a backup, which fortunately I made a couple days ago right before I started working on this VPN Client thing.

Given this erratic behavior of the firewall and the potential for global disruption here, and the fact I have an acceptable workaround (don't use the SonicWall client), I think I'm going to officially drop this.  It's not worth the hassle or stress.

Bah.
digitapCommented:
I understand. If the settings went corrupt like that, I'd almost wonder if your SW had eminent failure on the horizon. Anyway, all the best!
IT-Monkey-DaveAuthor Commented:
Thanks everyone, esp. digitap.  Sorry we couldn't figure this out but sometimes ya just gotta cut your losses and move on...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
IT-Monkey-DaveAuthor Commented:
Awarding points to digitap because he wrote the article that addressed my problem and tried to help me work through the problem.  Unfortunately no real solution was found.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.