I have a Windows 2003 server configured as a RRAS (Routing and Remote Access Server). This server was configured by the previous IT person, who didn't do a lot of things correctly. The VPN works okay, in the sense users can connect via VPN and then use remote desktop to remote into a PC inside the network and then do work from that PC. However, my understanding with VPN is, I should be able to do anything on the remote network as if I was actually there such as map network drives and printers without having to remote control a PC. Currently I am unable to do this and I believe the problem is that the RRAS server is setup to give out IP addresses to the VPN connections that are completely different than our internal network IP range, which use the standard 192.168.10.n. Once I connect to the VPN and run an IPCONFIG /ALL, I see the VPN gets the auto IP range of 169.254.12.xxx

I guess my question is wouldn't I want my RRAS to give out IP's in the range of my internal network that I reserved in the DHCP server? Also, is my understanding of VPN correct? Shouldn't users be able to access network resources that they have permission to in Active Directory?

Dani AI

Generated

Short answer: the 169.254.x.x address is APIPA (the client didn’t get a DHCP/RRAS-assigned address), and RRAS can either hand out addresses from a static pool or obtain them from your DHCP server — you need one of those working correctly plus proper DNS/routing for drive mappings to work. (learn.microsoft.com)

Why the /32 and “gateway = same IP” you saw isn’t usually the problem: PPP is a point‑to‑point link so Windows commonly shows a 255.255.255.255 mask for the VPN adapter; that by itself is normal. What matters is whether the VPN client has a routable IP, correct DNS/WINS, and the server/firewall is allowing SMB traffic to the file server. Test in this order after connecting:

ipconfig /all
route print
ping <fileserver-ip>
net use \\fileserver\share /user:DOMAIN\username

If ping by IP works but name or share fails, it’s DNS/credentials/permissions; if ping fails, it’s routing/ACLs. (datatracker.ietf.org)

Practical checks and fixes (matches things and were discussing)

  • In RRAS console check the IP Address Assignment method — pick DHCP if you want leases from your DC/DHCP, or use a static pool inside the 192.168.10.0 subnet and exclude that range on your DHCP server. Make sure the RRAS server can reach the DHCP server (or enable the RRAS DHCP relay agent if DHCP is remote). (learn.microsoft.com)
  • If RRAS is not domain‑joined you may be authenticating against local accounts by default; joining it to the domain (or using a centralized RADIUS/IAS/NPS server) simplifies AD authentication and the AD “dial‑in” attributes. You can also change the RRAS default domain behavior via the registry as documented by Microsoft. (ftp.zx.net.nz)
  • Check RRAS packet filters / NAT / Windows firewall (it’s also acting as your firewall), and ensure SMB (TCP 445/139) and DNS are allowed between VPN clients and the file server.

If you want, list exact RRAS settings/screenshots and the ipconfig/route output seen after connecting and the forum can point at the minimal change (static pool vs DHCP/relay, DNS push, or domain join) to finish the fix.

Recommended Answers

All 5 Replies

Go into Acive Directory users and groups and you can change the dial-in IP settings for each user/group.

I don't know if it matters, but the RRAS is on a separate box from my PDC. The RRAS has it's own users for VPN setup under Computer Managment. I can change the users dial-in settings there, which I did and it assigned me an IP for the correct range, however I still can't map to a drive. When I try to do so I get prompted for a username and password. I've tried my own user pass and the admin user pass.

The IP address is the correct range, as are the network DNS servers, however the gateway is the same IP as the connection's IP and subnet mask is 255.255.255.255.

Okay, this could be part of the problem. The RRAS is not part of the domain its a member of WORKGROUP. Wouldn't I want this on the domain?
The original IT guy set this up to replace a hardware firewall that croaked, so this is also functioning as our firewall.

It depends. In theory, it should be, in order for authentication, remote logon, accessing roaming profiles etc... but if you attach it to your domain you need to beware the security repercussions.

So can I do what I want to do, allow VPN users to map drives, without having it on the domain? I don't need much in the way of roaming profiles, etc. Just one mapped drive for a couple of my users.
I'm aware of the potential issues, but since I didn't configure it I can't be sure I can button it up either.
Ideally, if there is way to map the drive without attaching it to the domain, I would like to do that. And then I can lobby for putting a real hardware firewall in place.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.