RRAS VPN Issues - Can't see all machines on remote network

I have the following network configuration:

SERVER_A: SBS 2008
Services: DNS, AD, File Sharing

SERVER_B: Server 2003
Services: DNS, AD, RRAS,  DHCP

The router on the network forwards to SERVER_B for RRAS (PPTP)

When clients connect, they get an IP Address and DNS servers and they can connect to SERVER_A most of the time, sometimes it doesn't let them connect and says "Can't find server". Then we use the IP Address and it works OK.

One of the issues is the sporadic nature of this. Sometimes it works, sometimes it doesn't. I have DHCP set up to give out DNS #1 as SERVER_B and DNS #2 as SERVER_A. It's that way because if it's switched around, then they can't access anything on the office network. It's as if SERVER_A (SBS) is not responding to DNS requests.

I've changed settings a number of times, switch RRAS and all services to the SBS server like they should be but the clients connect and can't see any network services. It's almost like the server is not responding to any DNS requests for the VPN.

Any thoughts? I know it sounds garbled. I will clarify for you what I can.
LVL 1
Scott NowackiAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
QlemoConnect With a Mentor Batchelor, Developer and EE Topic AdvisorCommented:
DHCP relay is not needed. (R)RAS either uses a static IP pool, or allocates a block of IP addresses from DHCP on start. In both cases RRAS deploys the IP address to the client, not DHCP.

The non-functioning server has one more single routing entry - for the RRAS service end itself. That is required. The machine hence has two IP addresses.

I didn't get your "Could not disable firewall on the workstation.  Group Policy is running that show." message - what does that mean? You should just allow all traffic, not disable the Firewall service, if it is that. And you can do that despite any GPO setting, if you are fast enough ;-). GPOs are applied periodically, and changes will get reset at some point in time because of that, but there should be enough time for a test. If necessary, create an "allow all" rule, and put it on top of everything else.
On the other hand the local firewall shouldn't be the issue. Packets arrive virtually from the LAN, and the firewall should not block that. But - are you certain you can use shares inside LAN?
As you can reach the other server's shares, the issue seems not to originate from RRAS, but be a local (target client) issue.
For tests, don't rely on being able to browse for shares - that is an UDP broadcast, which will not (necessarily) passed over RAS.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Both servers are in the same domain, I assume? DNS relies on the proper DNS suffixes appended to names, and if the DNS suffixes provided by RRAS are not correct, name resolution will fail.
0
 
Scott NowackiAuthor Commented:
Both server are on the same domain. One is running Small Business 2008 (SERVER_A) and the other is running Server 2003 Standard (SERVER_B).

I'm thinking it's some sort of DNS relay issue. It's as if the RRAS server is doing the DNS work but only for some select devices.
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
That should not happen. The SBS is the server, and its DNS should work great.
How does that work in the office itself? The same DHCP settings, probably - and so all IPs are only registered on Server_B DNS. The issue with Windows DNS is that a second DNS server will never get asked if the first DNS server responds with a "I don't know the IP" message.

The proper setup is that all machines use the same DNS server, or DNS servers replicating their info.
0
 
Scott NowackiAuthor Commented:
I've rearranged the VPN and network configuration as follows:

SERVER_A - RRAS, DNS, DHCP, AD
SERVER_B - AD

I reconfigured the router to go directly to SERVER_A for PPTP.

Now, when clients connect they can access shares on both servers with no issues. They can ping the servers too.

The remaining issue is that they need access to shares that are on some of the network's workstations. We still cannot browse to those machines or ping their IP Addresses. NSLOOKUP resolves the name and IP ok. But I can't browse to the shares using "\\workstationname"

It's almost as if there is something not routing the file sharing traffic to those machines.

Internally, it all works just fine.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Did you use the same IP network for RAS as for the internal network? Otherwise each Windows Firewalll might block access (as the network is unknown and hence untrusted).

You might have to monitor network traffic (with WireShark or MS NetMon, resp. successor "Microsoft Message Analyzer") on the SBS and one of the target workstations.
Instead, you can try to perform a tracert -d -w 100 from a workstation to the connected remote PC.
0
 
Scott NowackiAuthor Commented:
Yes, I'm using the same IP block.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Try if (temporarily) disabling the Windows Firewall on the workstation with the share makes a difference.
0
 
Scott NowackiAuthor Commented:
Could not disable firewall on the workstation.  Group Policy is running that show.

It seems like there is an issue with the traffic to other machines outside of the server. Almost as if the RRAS is not routing traffic to or from those other machines correctly. I attached some screenshots of the RRAS config.

Also does it need a DHCP relay agent if the server is also hosting it's own RRAS?

I also compared it to another SBS 2008 machine that I know is functional and working to see where there were differences. I noticed that the routing table was different (IP addresses notwithstanding). I also noticed that there were a lot more firewall items on the functioning server that start with Network ICMP (all greyed out).

Thanks for any thoughts.
This is the RRAS layout. Note the DHCP Relay item.The NON functioning Server. Another customer's server who has it all working.
0
 
Scott NowackiAuthor Commented:
I am certain that I can use shares inside the LAN. If I go to any workstation on the network I can type \\workstation and press enter and get screen that shows all shared folders from each workstation. I can browse them and save and open files from them. So that all works internally.

That does not work when connected via the VPN. It's apparently a critical requirement of the system. They also want to be able to browse shared folders on the computer that's at the remote end of the VPN too.
0
 
QlemoConnect With a Mentor Batchelor, Developer and EE Topic AdvisorCommented:
"Browsing" and "using" shares are different topics. Browsing works with broadcasts, which won't work (that well) over VPN. But  \\workstation\share  or   \\ipa.ddr.ess.e\share   should work. If it does, we can work on the browsing part.
0
 
Scott NowackiAuthor Commented:
It's the \\workstation or \\ip.address that doesn't work. I've tried \\workstation or ip\share and they don't work either.
0
 
Scott NowackiAuthor Commented:
After 8 hours on the phone with Micrsoft support we narrowed the problem down to a DHCP/DNS issue. The machines all had a static IP record in DNS. Their actual IP Addresses were NOT the same as the static addresses. As soon as I changed the addresses to match, we can access the machine across the VPN.

Now to figure out why DHCP isn't working correctly.
0
 
Scott NowackiAuthor Commented:
Now it's working too - MS support guy turned of the server's firewall! Now it's back on and things seem to be working again.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.