At our small business, we have a server running Windows Server 2008 that acts as active domain directory, DNS, and DHCP, and a SonicWall router running our VPN services, with SonicWall NetExtender as the client software. Our problem is that when someone is connected through the VPN, they cannot initiate communication with anything on our local network.

SonicWall shows that the user is connected. The DHCP on our Windows Server 08 machine is telling me that he's been given exactly the address his NetExtender client says he has. I am able to ping the user from both my computer and the server he's trying to access, but his pings are timing out. I cannot remote desktop into his machine, either.

To my knowledge, there has been no change to either the server or the firewall. Yesterday, before an area-wide internet outage, he said he was able to connect and access the files on our server just fine.

What in the world is going on?

  • Do you have the routes in SonicWALL configured correctly? Should be under "SSL VPN -> Routes" or similar.
    – Nathan C
    May 22 '13 at 16:01
  • I don't see why I wouldn't have. I've changed nothing, and it was working just fine before. i.imgur.com/CuI9lm5.jpg
    – Nerdrage87
    May 22 '13 at 16:07
  • You need to do some more troubleshooting and give us some more details, like to what and how they're trying to connect; via name, ip address, etc. What happens if they run nslookup for an internal name? What happens if they tracert to an internal ip address? These come to mind as possible causes: name resolution, routing, VPN firewall rules.
    – joeqwerty
    May 22 '13 at 16:09
  • Thanks for the suggestions, I'll work on it after lunch. If I find the answer, I'll post it.
    – Nerdrage87
    May 22 '13 at 16:14

I found the answer. The IP range selected for the VPN services (190-199) was entirely within the range of Server 08's DHCP range (.150-.255). To fix it, I set the VPN range to 70-89, outside of the DHCP range. What I think was causing it is we have devices leased at 190 and 191, and when I tried to ping him, I was actually pinging those devices. He'd said it was working fine previously, and that was because in the screenshot he'd sent me of it working, he had been given 195, an unleased address on the DHCP. Not necessarily a VPN-DHCP conflict as a rule, but instead an individual IP conflict that's resolved by setting the VPN's target IPs outside the range of IPs that might be leased at random to other machines.

I suppose what I should've been looking for was whether the MAC address listed for the DHCP's leased IP matched his network card. What tipped me off was that 191, which he was connected to when we were on the phone troubleshooting, had a lease expiration set to tomorrow, 5/24/13, while the rest were all the 30th or later.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.