Share via


Remote client can log in to VPN but cannot access any network resources

Question

Saturday, April 16, 2011 6:03 PM

We have an existing office network (SBS2003) that has been running flawlessly for a few year.  Several home users have been able to connect to the network via VPN and then access network folders and RDP to domain machines.  Our issue started about two weeks ago when I suddenly could no longer access network resources from my home.  I am able to dial and connect to the network via VPN, but I cannot connect via RDP, navigate the network, or even ping any machine on the network.  I have tested the connection from both XP and Win7 clients at home.  The XP client looks like it is connected properly and the Win7 client shows the connection as active but indicates that there is "No Network Access."  How do I even start to hone in on the problem here?  I'm not aware of any changes from the home client side, and I do not believe there were any changes on the office network side because we have other home users that are still able to connect fine.

All replies (19)

Monday, April 18, 2011 8:49 PM ✅Answered

Completely disabled Symantec, including any firewall rules or network protection features?

Are there any event log error in any of the event logs on the SBS server?

Looks like it may be prudent to re-run the wizard to reconfigure it. Are you familiar with the SBS wizard?

 

Side note - And thanks Rob, I thought the subnet rules also applied to SBS 2003. But as you said, not an issue here.

 

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

This posting is provided AS-IS with no warranties or guarantees and confers no rights.


Saturday, April 16, 2011 8:11 PM

The most common cause of this is the business site and the home site are both using the same local subnet such as 192.168.0.x. Might this be the case? They need to be different for routing to take place.

If so, if you are using the standard Windows VPN client, if you check "use remote default gateway" in the VPN/PPP adapter configuration/properties you "should" be bale to access the SBS, but you will not be able to access any other resources. If using the SBS specific client, the option is not present.

Rob Williams


Sunday, April 17, 2011 8:07 PM

I agree, Rob. That is the most common cause. I've seen it numerous times. I always caution and recommend any company to use a subnet ID for their company network other than the subnets that many router/firewall vendors use by default, such as something other than the 192.168.0.0, 192.168.1.0, 10.1.10.0 (as Comcast uses), etc.

Ace

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

This posting is provided AS-IS with no warranties or guarantees and confers no rights.


Monday, April 18, 2011 1:37 AM

Rob and Ace,

Thank you for the response, however I can confirm that my issue definitely has nothing to do with a subnet conflict (Office runs on 192.168.0.X and home runs on 192.168.5.x).  Further, I can confirm that it does not matter whether I have the VPN set up to use the remote default gateway or not.  I see the same behavior either way.  

Let me also add that the VPN issue seems to be isolated to this particular office network.  We have a second office location that I am able to connect to without issue from my home machines.  Given this, I don't believe this to be an issue with how I set up VPNs or with my home firewalls.  Also, as I mentioned in my original post, other home users are able to connect to BOTH office networks without issue.  Given this, I doubt that there is a problem with office firewalls or anything like that.  There just seems to be something quirky between my home machines and this one office network.

Can either of you think of anything else I should try to discover the true cause of this issue?

Thanks.


Monday, April 18, 2011 9:35 AM

Hi tlatch79,

 

Thanks for posting here.

 

So what’s the particular system prompt when access office resources form home computer when VPN connected ? via host name or IP address ?

How did you configure SBS for address distribution for remote computers ? address pool or DHCP service ?

 

You may need collect the network settings form normal remote clients and compare it with problematic remote computers' .If it is possible, please also post here for further investigation.

 

Meanwhile, have you tried testing by running “tracert” utility form affected remote computers when this issue occurred ?

 

VPN Tools and Settings

http://technet.microsoft.com/en-us/library/cc783498(WS.10).aspx

 

Thanks.

 

Tiger Li

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


Monday, April 18, 2011 10:59 AM

Hi Tiger Li,

There really isn't a particular system prompt observed on the bad VPN connections.  The users are able to authenticate and seemingly connect to the network without issue.  The problem only starts when the user attempts to do any action on the remote network (requests for http, RDP, or even ping all fail when aimed at the office network).  The only other symptom is that on my Win7 client the Network and Sharing Center shows that particular VPN connection as "No network access."

The inability to connect to network resources exists whether I try to use host names or IPs.

SBS distributes addresses through DHCP.

As far as I am aware, the network settings of properly functioning clients match the network settings of the clients with issues.  In fact, the clients currently experiencing issues were functioning properly less than 3 weeks ago.  I'd be happy to post the settings of my non-functioning clients here if that is helpful.  What information would you like to see?

I have made several tracert attempts, but each fails before the first step.  It is the exact same behavior as if the client machine was offline.

Thank you.


Monday, April 18, 2011 11:10 AM

Just to confirm you are using the SBS built-in VPN?

Can you ping the SBS itself, assuming it is the VPN/RRAS server, when connected? I know you mentioned you couldn't ping any machine on the network.

Where everyone can connect but some cannot access resources, the only cause of this I have ever seen is

  • duplicate subnets, which could still be an issue if wither site used a 255.255.0.0 subnet mask and your aforementioned subnets
  • too high an MTU value. If this is an issue you can usually ping and sometimes see a resource but trying to connect to any service fails. If you want to test this, on a client machine drop the MTU down to 1200 using something like the DrTCP tool http://www.dslreports.com/drtcp  They list test tools, but because of packet overhead with a VPN best to just lower MTU as a test.

Rob Williams


Monday, April 18, 2011 1:19 PM

Rob,

Again, thanks for your input.  The SBS is my VPN server, but I cannot even ping it when my VPN is connected.  Somehow the VPN is able to establish some sort of connection and authenticate my client, but then absolutely all traffic seems to be lost.

Both sites subnet masks are set to 255.255.255.0, so I don't think this could be a duplicate subnet issue.

At your suggestion I have tested the connections with modified MTU settings with the DrTCP utility.  It did not have any effect.  I then tried by dropping the MTU on my home router from the default 1500 to 800, but I still experience the exact same behavior.  I have also attempted to remove any home router config issues by connecting my home modem directly to one of my clients, but again I can connect to the VPN fine but cannot access any network resources.  

At this point my only guess is that something must have changed in my home ISP's (Comcast) config a few weeks ago so that it is now interfering with my VPN to the office network.  Does anyone have any suggestions on how I can verify this?


Monday, April 18, 2011 1:30 PM

It's not the mask being the same, rather the subnet ID, also known as the network ID. So what Rob means by duplicate subnets is the office subnet network ID and the home subnet network ID may be the same, such as both being one of the following examples:

  • 192.168.0.0/24, with an IP range of 192.168.0.0 - .254
  • 192.168.1.0/24, with an IP range of 192.168.1.0 - .254
  • 10.0.10.0/24, with an IP range of 10.0.10.0 - .254
  • etc

Comcast could be on either the 10.x.x.x.x range or one of the 192.168.x.x ranges, depending on if they are using a Linksys router or not.

To assist us in better evaluating the issue, please provide an ipconfig /all from your client machine at home while connected, and an ipconfig /all of the SBS server to allow us to compare and look for any anamolies in the configuration.

Also, you may want to disable any and all Antivirus and Security software and/or firewalls you may have installed on your home machine. I've seen this as a cause, too.

You may want to run a scan for malware. The free tool at www.malwarebytes.com is a great tool. Just run a quick scan and follow the instructions to remove whatever it finds.

Ace

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

This posting is provided AS-IS with no warranties or guarantees and confers no rights.


Monday, April 18, 2011 4:18 PM

Obviously it is not a routing/subnet conflict based on your last comments but what I meant, more for Ace as I did not explain myself very well; You had stated one network uses 192.168.0.x and the other 192.168.5.x. If using 255.255.0.0 (/16) as the subnet mask it would then be the same Network ID for both. Again, I appreciate you have verified this is not the case.

It is very odd. An ISP, security software, or a dozen other reasons could block the traffic, but you say you can connect to other sites without a problem, which pretty well rules those ideas out.

At either site are there two NAT devices in place such as a modem that is a combined modem/router and a router, or might the router have a private IP for it's public interface rather than a public IP?

Rob Williams


Monday, April 18, 2011 4:22 PM

Rob,

Good point about a /16 mask that could cause an overlap in subnets. :-) I didn't think of that,l but then again being SBS, it won't support that during intial config, of course which can be changed later but the wizard will always want to put it back to a /24.

 

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

This posting is provided AS-IS with no warranties or guarantees and confers no rights.


Monday, April 18, 2011 4:42 PM

I do have a cable modem running to a wired/wireless router at home.  However, the router pulls its external IP from the ISP and we never had an issue for 2 years before with the same setup, so I don't think this is a cause of my issue.  I've just received word from another one of my users that they are also having difficulty with the VPN connection (authenticates but no network resources available).  Given this new info, I am now thinking it must be related to something on the SBS server side.   In looking at a calendar, I think that my issues started within a day or so of upgrading to Symantec Endpoint Protection from an older Symantec product on the office network.  I will play with disabling the antivirus to see if that affects my problem.  Are there any other steps I should take to test this issue and gather more clues from the server side?


Monday, April 18, 2011 4:51 PM

Symantec can definitely block VPN acces. It is notorius for that, but it should affect all users.

=>Ace I belive SBS 2003 (this server) will support /16, but 2008/2011 definitely will not. Again, not an issue at this point.

To add: Symantec clients need the remote site's subnet added as a trusted network to be able to access resources on theat machine. There are aslo Symantec A/V features that have been known to block PPTP traffic. Rob Williams


Monday, April 18, 2011 6:20 PM

Well, I've completed testing of the issue with Symantec totally disabled, but the issue persists.  What else can I try to isolate other potential causes of this problem?


Monday, April 18, 2011 8:57 PM

Oh forgot to ask, did you disable it only on the SBS side, or did you also disable Symantec Endpoint on the client side, too?

 

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

This posting is provided AS-IS with no warranties or guarantees and confers no rights.


Monday, April 18, 2011 8:59 PM

To add to questions: Can any users connect and access shares?

If not can you connect from the LAN using the server's private IP?

Rob Williams


Tuesday, April 19, 2011 3:14 PM

After contacting each of my remote users again, I was able to determine that none of them had given me an accurate assessment of their experience the first time.  In fact, all of my users were able to authenticate but unable to access any network resources.  Given that, I was quickly able to identify Symantec as the root cause.  For some reason the application made a change on how it treated remote network traffic and it was trying to quarantine those requests.  Once we corrected that setting, all users were able to resume with full functionality.  Thanks to each of your for your help during this process.


Tuesday, April 19, 2011 3:53 PM

After contacting each of my remote users again, I was able to determine that none of them had given me an accurate assessment of their experience the first time.  In fact, all of my users were able to authenticate but unable to access any network resources.  Given that, I was quickly able to identify Symantec as the root cause.  For some reason the application made a change on how it treated remote network traffic and it was trying to quarantine those requests.  Once we corrected that setting, all users were able to resume with full functionality.  Thanks to each of your for your help during this process.

Good to hear you found it. Our pleasure for the help.

Note on Symantec - that network protection feature has bonked domain controller replication traffic on some of my customer machines. I don't know why Symantec decided to make this a default setting, but it has cost many companies headaches dealing with it. I'm not saying it's a good or bad product, and I like Symantec as well as McAfee, but just the decision to make "protect remote networks" a default setting with their updated engine, should have been thought out in its entirety for any possible implications before they decided to make this a default setting.

Ace

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

This posting is provided AS-IS with no warranties or guarantees and confers no rights.


Monday, August 22, 2016 3:12 PM

Thank you very much my works after disabling the Symentec Antivirus on the server.