• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Can't access network resources over VPN with Server 2008

Copied from other thread:

Fardringle said:
I was asked today to set up VPN access for a small office with a 2008 sp2 standard server. I have done this before on Server 2003 and it was simple, but this is the first time I've tried it on 2008. So I followed this tutorial since it seemed to be pretty simple and thorough.

Now, remote clients can log in to the server and are given an IP address in the proper DHCP scope for the office, but can't access any network resources by name or IP. They can't even ping the server by name or by IP address (it does respond to pings while on the local network). So obviously something is not configured properly for the VPN but I'm not sure what I am missing. Is the tutorial wrong and/or missing steps somewhere?

I verified that the Routing and Remote Access service is set to allowed in the server's firewall and port 1723 is forwarded from the router to the server's IP address but I don't know what else to check.
Click to expand...

Which router are you using? IIRC, PPTP uses GRE as well -- is that allowed through the firewall?

EDIT: I have PPTP access to my house and I just noticed that on the outside firewall, I do have GRE (protocol 47) explicitly forwarded in addition to port 1723. Could this be your problem?
 
Last edited:
It's a Netgear WNDR3700. And yes, port 1723 and GRE protocol 47 are both forwarded to the server's IP address.
 
so once vpn in, can you ping the server at all ? ie ping the vpn server's internal ip, and ping other ip on the network
 
Nope. Once the connection is established, the client computer gets what appears to be a valid IP address from the server, but can't ping anything at all. Not the server's IP or name, or any other IP on the office network, or any web site. So the client is trying to route all communications through the VPN connection (as it should) but they simply aren't going anywhere.
 
Are you able to see the connected clients on the server? Does the server have multiple NICs? Also, for the heck of it, have you tried disabling the Windows 2008 firewall and running a quick test?
 
The server has one NIC. The firewall is disabled. I'm not sure how I'd check to see if the server can see the connected clients. Where would I go to look at that? Or just see if it can ping them?
 
Fardringle said:
The server has one NIC. The firewall is disabled. I'm not sure how I'd check to see if the server can see the connected clients. Where would I go to look at that? Or just see if it can ping them?
Click to expand...

It has been a long time since I looked at RRAS, but I thought there was a node which showed connected clients.
 
It will probably be several days before I go back to that client's office, but I'll see if I can find that connections list to see if the server actually acknowledges that the client is connected.

Any other suggestions for things I should check when I visit the client?
 
I made it out to the client's office today, and verified that the port 1723 and protocol 47 were forwarded from the router to the server. The server was showing the test client in the active RRAS clients list with the correct IP address, and disconnecting that client from the list also actually disconnected the client itself from the VPN. However, I still couldn't access any network resources.

Using another suggestion I found online, I also forwarded port 500 to the server, and changed the firewall settings on the server so that instead of just allowing the RRAS service (which said it was allowing port 1723) I manually added a new entry specifically for port 1723 and port 500 and now clients are able to ping network resources both by name and by IP address.

I don't know if it was the specific port 1723 firewall entry that fixed the problem or adding port 500, but it's working, and while I could log in to the router from here to disable the forwarding of port 500 for testing, if that kills the access then I'll have to drive an hour and a half back to the client to enable it again (they refuse to let me talk them through even simple changes over the phone) so I think I'll just leave it as it is for now. 🙂
 
Fardringle said:
I made it out to the client's office today, and verified that the port 1723 and protocol 47 were forwarded from the router to the server. The server was showing the test client in the active RRAS clients list with the correct IP address, and disconnecting that client from the list also actually disconnected the client itself from the VPN. However, I still couldn't access any network resources.

Using another suggestion I found online, I also forwarded port 500 to the server, and changed the firewall settings on the server so that instead of just allowing the RRAS service (which said it was allowing port 1723) I manually added a new entry specifically for port 1723 and port 500 and now clients are able to ping network resources both by name and by IP address.

I don't know if it was the specific port 1723 firewall entry that fixed the problem or adding port 500, but it's working, and while I could log in to the router from here to disable the forwarding of port 500 for testing, if that kills the access then I'll have to drive an hour and a half back to the client to enable it again (they refuse to let me talk them through even simple changes over the phone) so I think I'll just leave it as it is for now. 🙂
Click to expand...

Yeah, that's very strange. I've never had to forward port 500 before in any of my PPTP implementations. From what I'm reading here, that should only be a requirement for L2TP as it is an IPsec control path and even then, you'd need some additional ports. Do they have IPsec implemented on their network? That might be why you have to forward that port.
 
No IPSEC that I'm aware of, but it's possible someone enabled something. I don't normally work on their server. I was just asked to set this up because the owner is a friend.

Anyway, I don't know why port 500 might have worked since it is definitely connecting using PPTP, but the connection does work now so I'll leave it alone.
 
Fardringle said:
if that kills the access then I'll have to drive an hour and a half back to the client to enable it again (they refuse to let me talk them through even simple changes over the phone) so I think I'll just leave it as it is for now. 🙂
Click to expand...

no teamviewer, logmein or some agent that gives you remote access?
 
xSauronx said:
no teamviewer, logmein or some agent that gives you remote access?
Click to expand...

As logical (and preferable) as that would be, no. The owner wants to have this VPN connection available, but no 'public' remote desktop programs like Logmein or Teamviewer, and he's the boss so he gets to decide.
 
I'm starting to think that the ISP is doing something and the connection working after I added port 500 was just a coincidence. Without anything being changed at all on the office server or router, the VPN connection is now not working again. It's back to the same situation as before, where clients are able to connect and get an IP address, but can't do anything on the connection..
 
Fardringle said:
I'm starting to think that the ISP is doing something and the connection working after I added port 500 was just a coincidence. Without anything being changed at all on the office server or router, the VPN connection is now not working again. It's back to the same situation as before, where clients are able to connect and get an IP address, but can't do anything on the connection..
Click to expand...

I don't know their network topology, so this may not work as I'm describing it but I'll go ahead and tell you how I would test and maybe you can do something similar. In my home environment, I have an external firewall and an internal firewall and a DMZ between them. If I were having weird issues with VPN and I wanted to rule out my configuration and point at the ISP, what I would do is take a laptop, wire it to the DMZ switch, give it an IP in the DMZ IP range, and I'd put a host entry into the laptop's hosts file which points the VPN host name to the DMZ IP of the VPN server. That way, I would know I'm connecting over my own equipment and network and remove the ISP from the equation. If that test works, then we're looking at only two possibilities as issues -- my external firewall (which I'd double and triple check) or something the ISP is doing.

Is their network topology configured in such a way that you can perform a similar test?
 
Last edited:
I made another trip out to this small office yesterday and finally figured out why the VPN wasn't working. It turns out they have a Comcast router (for their IP phones) that cannot be set to bridged mode, instead of the basic modem that he was absolutely sure he had, and that router wasn't set to forward anything at all to the 'real' router. I don't have any idea why the VPN connections were still able to authenticate when nothing was being forwarded, but now that it's actually set up properly, it's working great. Thank you for the suggestions, and now I'll go sit in a corner and sulk because I missed something so simple (I didn't even look at the modem) the other times I went out there... 🙂
 
Last edited:
If you use a single NIC interface the solution for me was to configure RRAS with VPN and Lan Routing, use a static pool in RRAS and make sure the client has unchecked USE DEFAULT GATEWAY ON REMOTE NETWORK. That is the key actually. On the client side in properties of your VPN connection you will find in the TCP/IP properties under the advanced tab. If you want to access other LAN resources then configure VPN and NAT. For me I only needed to see a share on the server.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top