Archive for the ‘RRAS/VPN’ Category

Windows VPN Client Deployment

      subtitled: What happened to the SBS Connection Manager?

VPN name resolution is a common problem for many IT folk.  I have addressed in in previous blogs by manually configuring the VPN client to point to the corporate server for DNS, and adding the corporate domain suffix.  This is not practical as it has to be done on every computer on which the VPN client was configured.

Small Business Server 2003 had a very nice little wizard that would create a deployable VPN client called “Connection Manager” which contained server connection information and allowed for proper name resolution over the VPN.  Though the missing feature from subsequent SBS versions inspired this article, it can be used to create a deployable VPN client for any Windows Server.  The SBS wizard basically ran a mini version of a standard Windows tool called CMAK.

Firstly you need to install CMAK, the Connection Manager Administration Kit.  To do so, on a 2008 or newer server, open Server Manager under Administrative Tools, choose Features, and Add Features.  In the features wizard choose Connection Manager Administration Kit, and complete the wizard.


Though there are many configurable options and features that can be added with CMAK, for the purposes of this article only the basics will be configured to allow for VPN name resolution, automatic installation, and to try to replicate the old SBS 2003 Connection Manager experience.  One of the additional advantages of the Connection Manager Client is it limits the options with which the client can “tinker”, thus reducing support calls and increasing security.

In this example CMAK is being run on a 64bit machine. The deployable VPN client created can only be used on other 64bit machines. If you need to deploy on a 32bit machine you will need to install and run CMAK on a 32bit computer/server.  CMAK may not available from the built-in windows options on older operating systems.  If so, it can be downloaded as part of the Windows Server 2003 Administration Tools Pack (32bit)

Start The Connection Manager Administration Wizard from Administrative Tools, accept the UAC warning, click next, and select the O/S on which the client will be deployed, remembering the above warning about 32/64 bit.


Select New Profile,


Enter a ‘Friendly’ name for the connection and a file name (<9 characters) for the deployment package.


Rather than cluttering this post with unnecessary images, accept the defaults on the next two pages, “do not add a realm name to the user name” and leave the merge profiles boxes empty. In the next window, as per the image below, check Phone book from this profile, always use the same VPN server, and insert the public FQDN or IP of the VPN server.


Next highlight your new connection and choose edit.  Under General select Only IPv4 addresses.  If you like, for added security you can disable file and printer sharing, which blocks access to shares on the connecting client’s computer while connected to the VPN.


Under IPv4 add the internal IP for your corporate DNS server.  If you have multiple corporate DNS servers you can add a second, and if you have WINS servers you can add those as well.  Do not add public DNS servers here.  I recommend checking “Make this connection the client’s default gateway” (disabling split-tunneling) which blocks access to to the client’s local LAN while connected to the VPN.  By doing so Internet access is actually made via the VPN, rather than through the local router.  One reason you may need to un-check this is it also blocks access to a local networked printer, i.e. one that is not physically attached to the connecting computer.  Leave “Use IP Header compression” checked.  Note that in a user created VPN client using the tools built into a Windows PC, the “default gateway” option can be changed.  When created with CMAK it cannot be changed.  This is intentional for security reasons.  Split-tunneling, allowing the client simultaneous local and remote network access, is considered a security risk.


Under security you can leave the defaults or change to “Only use Point to Point Tunneling Protocol (PPTP)”.  If you are connecting to an old server it may also be necessary to also check CHAP authentication, but this is less secure than MS-CHAP v2, so only do so if absolutely necessary.  All 2008 and newer servers use MS-CHAP v2 by default.


Under advanced add the internal corporate domain suffix.  Check “Register this connection’s DNS address in DNS” if for some reason LAN clients need to resolve the name of the remote computer.  I recommend not doing so if not needed as it adds unnecessary entries to DNS that may not be cleaned up if DNS scavenging is not properly configured.  Select OK, Next, and move on to the next window.


We are not using “phone books” so uncheck “Automatically download phone book updates”


From here accept all defaults in the next 4 windows; Configure Dial-up Networking, Specify Routing Tables, Configure Proxy Settings, and Add Custom Actions.

Note: it is assumed the server VPN configuration is basic, assigning IP’s in the same subnet for VPN clients as LAN clients, which is typical of SBS.  However, if the VPN clients are assigned addresses outside of the LAN subnet, and you want to access resources on the corporate LAN other than the VPN server, you will need to add a routing table file, on the “Specify Routing Tables” page, to have the route pushed out to VPN clients.

Though not necessary at all you may want to add a custom graphic or logo to the connection client. This is done on the “Display Custom Logon Bitmap” page followed by the ability to add a custom graphic in the phone book (list of connections), and on the 3rd related page you can choose to use  custom Icon for the deployed VPN connection.

Leave the “Include Custom Help File” as default, and under “Display Custom Support Information”.  You may want to add contact information. This is displayed on the VPN connection client where they enter their user name and password, when trying to establish a connection.


Accept the defaults in the remaining windows; “Display a Custom License agreement” and “Install Additional Files…”.  In the final Window “Build the Connection Manager Profile and its Installation Program” leave Advanced uncheck, and assuming you do not wish to make any changes, click Next, and Finished.  The deployable package will be saved in a folder named profiles in the CMAK folder, the default location being: C:\Program Files\CMAK\Profiles\Windows 7 and Windows Vista\   You only need to copy the .exe file to the client computer, in this case AcmePkg.exe


To configure the client, simply double click on the .exe file.  You will be prompted if you want the client to be available to all users or just the current user.


Click OK, and wizard will complete, add a connection icon to the desktop, add the connection to task bar network icon………


…….and launch the VPN client.

If you wish to connect enter the user name of a member of your VPN User group, their password, and internal domain name.  The domain name does not have to be present just to connect to the VPN, but in most cases if the PC is not domain joined, it needs to be there to access files using server names, rather than IP’s.


You should now have access to resources on the remote server, assuming the VPN at the server end is properly configured, and you have the appropriate Share and NTFS/Security permissions on the server to do so.

If needed, I have bloged in the past about configuring the VPN server.

Configuring a Windows SBS 2003 as a RRAS/VPN Server

SBS 2011 Essentials – Configuring VPN access

Configuring a Windows 2003 RRAS/VPN Server with 1 network adapter

SBS 2011 Essentials – Configuring VPN access

It has been pointed out that SBS 2011 Essentials does not have the familiar wizards to create VPN access to the server.  Though a better and MUCH more secure option is to make use of Remote Web Access, or add a VPN capable router that supports an IPSec client, on occasion there are reasons to still make use of the native Windows VPN feature.  Where SBS has traditionally supported the PPTP protocol for its VPN, this article will address creating similar service.

Add the RRAS Role:

The first step is to add the RRAS (Routing and Remote Access) role.  To do so open the Server Manager under Administrative Tools, click on roles, scroll down to the Network Policy And Access Service role, and choose Add Role Services.


In the resulting window add the RRAS services.


Click Next, and Install.

Configure RRAS:

Open the newly created RRAS console, under Administrative Tools, and then right click on the server name and choose Configure and Enable Routing and Remote Access.  Select Next, and then choose Custom Configuration, and Next.


Select VPN Access and LAN Routing in the next window.


Choose Next, Finish, accept the notification that a default Network Policy Server policy has been created, confirm to start the service (RRAS), and wait for it to complete.

SBS Essentials is not the DHCP server for the network in a default configuration. Though you may be able to configure a DHCP relay it is simplest to create a static address pool for VPN clients from which they can obtain an IP address.  To do so in the RRAS console right click on the server name and choose properties. Under the IPv4 tab select Static Address Pool, Add, and then enter a range of IP’s to be assigned to the VPN clients. Make sure you have enough to support the total number of simultaneous VPN clients you will have.  This range needs to be part of the same subnet as the server itself, and the IP’s selected cannot overlap with any existing DHCP scopes or statically assigned devices on the network.


You also need to verify the number of available PPTP ports is sufficient to support the maximum number of simultaneous VPN connections.  The default with SBS Essentials is 50, which should be more than enough. However if you wish to make adjustments it can be set from 1 and 128. You can also reduce the number of ports for other protocols not in use if you like, though there is no need.  To configure right click on Ports in the RRAS console below the server name, and choose properties.  To make changes highlight the port type and click Configure:


Add a Group:

Next we will create a group for VPN users.  Only members of this group will be granted access to the server using the VPN connection. Open Active Directory Users and Computers, expand your domain, right click on Users and choose New, then Group.


Enter a name for your group such as “VPN Users” and select Global & Security. Click OK.


You can now double click on the newly created group and add members by adding individual users or existing groups. For example you might want to add the Domain Users group, if you want to allow all users access. You can manually type these in and click Check Names, or choose Advanced and Find to browse and locate users and groups.


Configure NPS:

The final server configuration is to add a policy to define who has access to the server using the VPN. In server 2003 and earlier, if RADIUS was not configured, the common way of allowing access was to simply select “Allow Access” in each user’s profile.  This still works, but it is better to make use of NPS and have polices defining protocols, user, hours of access, and more, so I suggest leaving this set as Control Access through NPS Network Policy”.


Again under Administrative Tools, open the Network Policy server console, expand Policies, and click on Connection Request Policies.  You will note to the right, configuring Radius has already created the default Microsoft Routing and Remote Access Service Policy.


We will add a new Network Policy.  Right click on Network Policies and choose New, enter a policy name such as “ VPN User Access”, select Remote Access Server (VPN Dial-up), and Next


In the Specify Conditions window scroll down to find the User Groups option, click Add, Add Groups, enter the name of the group you created earlier (VPN Users), and OK.


In the next two windows you can accept defaults;



Under Configure Constraints choose NAS port type, then under Configure Dial-up and VPN tunnel types select Virtual (VPN), which will automatically check the same under Other.


Accept defaults under Configure Settings, click Next and Finnish.


Though you can add many restrictions within the policy, I recommend configuring with the SBS standards as above and thoroughly testing your VPN before tightening security.  You can also create multiple policies with different restrictions for different groups if needed.

Windows Firewall:

The above configuration should have automatically configured the necessary Firewall Exceptions for RRAS, but to verify compare to the following.

In the Windows Firewall console:


In the Windows Firewall with advanced Security console (Note: The L2TP-In policy was created, but is not necessary for our configuration.):


Router Configuration:

You will also have to manually configure your router to forward the PPTP protocol and enable GRE pass-through.  In an ideal world if UPnP is enabled on the router (which I don’t recommend) the SBS will configure port forwarding for port 1723, but it will not address GRE.  Configuring a router to forward VPN traffic is done in a  multitude of different ways depending on the router used.  Most of the inexpensive SOHO routers are configured by forwarding port 1723 to the IP address of the SBS, and under the firewall section select “allow PPTP pass-through”.  Some others allow you to forward the PPTP service rather than the port, which both forwards port 1723 and enables GRE pass-through.  Still others have different methods or require manual commands.  Keep in mind GRE is a protocol (protocol 47) and not port 47 so it cannot be configured with a forwarding rule. You can test if port forwarding is properly configured by entering 1723 in the “port” box at however this will not test for GRE pass-through.  If the VPN connection fails with a 721 or 806 error, it usually indicates GRE is blocked.  Keep in mind GRE and/or PPTP can be blocked by third party security software on your server, or an ISP that does not support the protocol.

While on the subject of routers, it was mentioned above when creating the static address pool in RRAS that; “the IP’s selected cannot overlap with any existing DHCP scopes or statically assigned devices on the network”.  I strongly recommend verifying that the router’s DHCP address range available to clients does not conflict with that of the static address pool.  If your router supports exclusions, add the RRAS static address range, or in the example above we used for the static address pool, so set the router’s DHCP range to something like  Again make sure neither conflict with any devices that may have a static address such as a printer.

A note about routing: An important fact to note that is that when traffic is sent from one network segment to another, as is done with a VPN, that all segments in the path between the client and host must use a different network ID (Subnet) for routing to take place. For example, if the remote client and server sites both were to use 192.168.0.X locally, the VPN will connect, but you cannot access resources. This is important to be aware of since SBS Essentials defaults to having the router determine the subnet, and if the default router settings are used, it is common to have them overlap with the client site. It is always best to use uncommon subnets for the corporate site. Therefore avoid the common/default subnets listed below and use something like 192.168.123.x when setting up the SBS site.

  • Avoid the following subnets as they are common router or user defaults with the first two being extremely common: 192.168.0.x, 192.168.1.x, 192.168.2.x, 192.168.100.x, 192.168.111.x, 10.0.0.x, 10.0.1.x, 10.1.1.x, 10.10.10.x, 172.16.1.x

Client Configuration:

Creating client access is very straight forward. Open the Network and Sharing Center in control panel, and click on Connect to a workplace, and Next.


Choose No, create a new connection, and in the next window select Use my Internet connection (VPN).  In the resulting window enter the public IP or the FQDN of your SBS site, and a ‘friendly’ name for the connection.   Select allow other people to use this connection, and/or don’t connect now, if you wish.


In the final window enter a user name (member of your VPN User Group) and password.  I do not recommend choosing the save password option, for security reasons.  Then click connect.  If all is in place you should now be able to connect to the server and other resources on the network.  You may wish to test by Pinging the server IP.

Name Resolution:

You will likely not be able to access resources using either their NetBIOS or DNS name. At this point you are best to connect using the IP address such as  \\\ShareName.  If you wish to use DNS names you need to configure the VPN (Virtual NIC) under adapter settings to point to the SBS for DNS, and add the DNS suffix.  For more details see: VPN client name resolution

Connection Manager:

With SBS 2003 there was an option to create a deployable VPN client named “Connection Manager”. This was a fully configured client that did allow you access to the server using DNS names, and was very easy for clients to install on their remote computer.  This is not longer available but if interested you can create your own installation package, with connection and DNS options pre-configured, using CMAK (Connection Manager Administration Kit). For details see:

Updated Jan 31/2011:

After the first client has connected by VPN, check the DNS management console and see if the VPN’s virtual adapter IP has been added under Interfaces. If so you need to uncheck it, or client machines will receive this as their DNS server IP. You can find the VPN IP by running IPconfig and look next to the PPP adapter.



VPN client name resolution (Updated)

VPN clients will often not resolve names for the remote domain to which you are connected, especially if connecting from a non-domain joined machine. There are numerous options to address this such as; using IP’s rather than names, adding entries to LMHost (NetBIOS) and/or Host (DNS) files, or using WINS. However DNS is the best and only practical solution since Server 2008. Though the VPN server should be configured to ‘hand out’ these options via DHCP to VPN client’s, in some configurations such as using a RRAS Static Address Pools, this is not possible. If so, there are two simple additions to the VPN network adapter required on the client machine. Under properties for the VPN/PPP adapter, go to the DNS tab under advanced TCP/IPv4 properties:

  • Add the IP of the remote site’s  DNS server, either under “DNS server addresses, in order of use”, or on the “Internet Protocol Version 4 (TCP/IPv4) Properties” page under “Preferred DNS server”, which will automatically add it to the former.
  • Add the remote site’s internal DNS suffix to the “DNS suffix for this connection” box

Should you wish to explore the other options mentioned above (IP’s, Host & LMHost files, WINS), or need use those methods for legacy systems, you can read more about these on my other blog:

LMHosts and Hosts files

There are two files in the %systemroot%\system32\drivers\etc  directory that can be used for name resolution. The Hosts file, used for DNS name resolution, and the LMHosts.sam file used for NetBIOS name resolution. In an age where DNS dominates your network both locally and throughout the Internet, these two files are seldom ever used, but they can be very useful in a few situations. Both are simple text files that match names to IP addresses, and are very easy to create and implement. Most people are familiar with these files, but are often frustrated when they do not work as expected. This is usually due to the fact that they have some very simple, but specific requirements, for them to work at all.

LMHosts (NetBIOS names):
The primary use today for an LMHosts file, is for name resolution over a VPN. If DNS is configured on the host and client machines there should be no need of static text files for resolving names, but it does work well, and many folks uses them as a dependable simple solution. The catch is there are a few gotcha’s you need to be aware of:

  • The LMHosts file in it’s default form, is named lmhosts.sam  The  .sam represents sample. If you are planning on using this file it needs to be saved without a file extension –  lmhosts. Be careful if using a text editor like NotePad as it will add a .txt file extension to the name. The safest method is to save the file using quotes, “lmhosts” to assure no extensions are added.
  • Text following a # in the LMHosts file is a comment and can be ignored or deleted.
  • A typical entry would look like:      COMPUTERNAME      #PRE       #my notes
  • When making a new entry you must hit enter at the end of the line, which adds a “carriage return”
  • Use the Tab key between items in each line rather than spaces (recommended but not necessary), but there must be a space.
  • Though it is not needed, adding the #PRE parameter or extension will load the entry into the local NetBIOS name cache when the computer boots. This allows for a slightly faster resolving of the name, before it has been added to the cache.
  • Most entries such as #PRE, #DOM, DOMAIN names and such are case sensitive. Always use uppercase to be safe.
  • It is a good idea to add the domain name as well. This requires two lines, and uses extremely critical formatting. A sample would be:   DCNAME   #PRE   #DOM:YOUR-DOMAIN   “YOUR-DOMAIN    x1b”   #PRE
    There must be exactly 20 characters, including spaces, between the quotes in “YOUR-DOMAIN    x1b”, and the spaces need to be between the domain name and the x1b. The domain name used is the NetBIOS name, not the FQDN. If your domain name exceeds 15 characters, you must truncate it at the 15th character, it will still work.
    If you find this last step tedious, the University Of Sait Louis has a little Java script that will create these two lines for you:

Hosts (DNS names):
The Hosts file today seems to be more used for blocking unwanted web sites. This is done by simply entering the website address and substituting the IP address with the localhost IP address such as: #advertising site
There are subscription services that will actually update your Hosts file, according to a schedule, with a list of known unwanted sites.

Another handy use of the Hosts file is to create abbreviations for your own use. For example quick access to a website like Google can be achieved adding an abbreviation like ‘G”, or your firewall with ‘F”, or I frequently uses it for accessing client sites with remote desktop using 3 letter acronyms such as ACL for Acme Corp Ltd. :         G         #Google      F         #my firewall      ACL    #Acme Corp Ltd
Most of the rules that apply to the LMHosts file, apply to the Hosts file as well:

  • The Hosts file already has no file extension, so there is no need to change it like the LMHosts file. Just be careful when editing you don’t accidentally add one such as .txt when using NotePad or a similar editor.
  • Text following a # in the Hosts file is a comment, and can be ignored or deleted
  • A typical entry would look like: #company FTP site
  • When making a new entry you must hit enter at the end of the line, which adds a “carriage return”
  • Use the Tab key between items in each line rather than spaces (recommended but not necessary), but there must be a space.

Keep in mind when editing these files you can run into conflicts, or ineffective changes if you do not reboot or purge the local name caches. To clear the NetBIOS cache ( and PREload), at a command line enter (R is case sensitive):
nbtstat  -R
To clear the DNS cache, at a command line enter:
ipconfig  /flushdns

For the record, the LMHosts and Hosts files can also be used for IPv6 addressing. Vista for example includes the IPV6 localhost entry, by default:
::1        localhost


VPN client name resolution

The most common problem reported with a VPN client is ” I cannot browse the remote network”. Most often if one thinks about the need to browse over a VPN connection, you quickly realize it is seldom necessary at all. You are using a VPN to access a known remote resource to which the location is well documented.  It can easily be accessed using the IP address or computer name.

Within the confines of a LAN, NetBIOS name broadcasts are the primary method for registering and resolving of names, for browsing purposes. Because broadcast packets are not routable, they are not forwarded over the VPN, and thus browsing is not possible.  With the exception of a few routers offering services to forward NetBIOS information over the VPN tunnel, the only possibility for browsing the remote network is using two WINS servers as outlined in option 3 below.

There are numerous ways to access a remote machine as listed below. All will work, however for the simplest and most reliable solution use the IP address. If you want to access a remote network using names, by choice, or because the resource is on a device with a dynamic IP, I would recommend you jump to the last option, and use DNS.

  1. IP address
  2. LMHOSTS files  (HOST Files)
  3. WINS (Windows Internet Name Service)
  4. DNS (Domain Name Service)

1) Most often the resource is located on a server with a static IP and therefore it can easily be accessed using a combination of the machine IP and the share name, such as \\\SharName This is very simple, reliable, and does not rely on other services or applications. Should you need to map a drive, that too can be easily done at a command line or in a script using   Net Use Z: \\\ShareName

2) Assuming again the remote device is using a static IP, dependable name resolution  to allow access such as \\ServerName\ShareName can be done with the LMHosts file.  Located in %systemroot%\syetem32\drivers\etc folder, the LMHosts file is a list stored on the local computer basically mapping NetBIOS (computer) names to IP addresses.  Though this works extremely well, it requires maintaining an updated name/IP list. There is also the Hosts file which is similar, but it is intended for DNS Fully Qualified Domain Names, rather than NetBIOS names. The LMHosts file, is a simple text file, but it has  very specific configuration rules. See the following Microsoft documents for details:

3) If you have A WINS server located at the RRAS server site, it can be used for dynamic NetBIOS name resolution (i.e. it does not rely on static IP’s). In order to do so the VPN client needs two options configured.

  • The client must be assigned the WINS server IP address. This can be done manually on the client, or assigned through DHCP by the RRAS server. If using DHCP, the RRAS server will not supply the WINS address from the DHCP scope options. The WINS server IP must be assigned to the RRAS server’s network adapter, and it will then be inherited by the VPN client when it connects.
  • On the VPN client’s network adapter , under TCP/IP properties, advanced, WINS, you also need to enable NetBIOS over TCP/IP.
    WINS is also your only option for browsing the remote network. In order for this to work, you will need replicating WINS servers configured at both ends of the VPN tunnel. Browsing is still not 100% reliable using the two WINS server option.

4) All Windows 2000 and 2003 active directory environments have DNS configured. Thus, for name resolution of devices with dynamic IP’s, it is generally the best bet. Again there are two requirements for using DNS:

  • Like WINS, the client must be assigned the DNS server IP address. This can be done manually on the client, or assigned through DHCP by the RRAS server. Once again if using DHCP, the RRAS server will not supply the DNS address from the DHCP scope options. The DNS server IP must be assigned to the RRAS server’s network adapter, and it will then be inherited by the VPN client when it connects.
  • On the VPN client’s network adapter, under TCP/IP properties, advanced, DNS, you also need to add the domain DNS suffix, such as MyDomain.local in the “DNS suffix for this connection” box.

Hopefully at least one of these options will assist you with name resolution using your VPN client.

Tag Cloud