Archive for category VPN
SBS 2008 series : VPN setup in Small Business Server 2008
Posted by Mark Raborn in VPN on 2009/03/08
How To Configure a SBS 2008 Virtual Private Network ( VPN )
VPN ( Virtual Private Networks ) are essential vehicles for mobile and home office based employees to gain access to resources on their company internal networks. Included in the software of Small Business Server are the components that also support VPN access. Today’s post is a guide to understanding the setup of up a virtual private network on your Small Business Server as well as an open discussion of some of key aspects of completing that configuration sucessfully.
BTW… our VPN walkthrough for SBS 2003 is here
Remote Access Services ( RRAS ) : using the Windows SBS Console to configure RAS and open TCP port 1723 in Windows Firewall
The first step to granting remote access to mobile or home based workers directly to the internal network is to allow that type of access to occur. In Small Business Server 2008, the process is simple and can be completed using the built in Remote Access wizards. Here’s how:
- Launch Windows SBS Console
- select the Network tab
- select the Connectivity tab
- in the main section, observe the list of connections (their Names, Descriptions and their status)
- in the right hand pane, under Tasks, select Configure a Virtual Private Network
- this will launch the Setup Virtual Private Networking wizard
- select Allow users to connect to the server by using a VPN , click Next
- the system will configure virtual private networking on server and if possible, configure your Internet Router as well.
- These functions functions combine what Small Business Server 2003 accomplished with the CEICW and Remote Access Wizard.
- NOTE: your Firewall and/or Internet Router must have PNP configuration enabled for SBS to configure the Firewall/Internet Router. In many cases it will be necessary to manually configure the router/firewall opening TCP port 1723 for Virtual Private Networking.
- The Setup Virtual Private Networking Wizard will execute at this point configurin VPN on the Server and the Firewall/Internet Router (if possible)
- If the Wizard completes “successfully”, a confirmation is displayed.
- “IF” there are any issues or failures in configuring the VPN or the Firewall/Internet Router, Details on the failure(s) will be linked
- once complete, move on to the Users and Groups and allow VPN access (content below)
HERE ARE A SERIES OF SCREENSHOTS OUTLINING THESE STEPS
The Virtual Private Networking Wizard makes all this look easy (and that’s a good thing unless you like books as much as this writer does
). So that we gain understanding of what accomplished by the wizard, let’s look a little deepr at what VPN Setup wizard is being asked to do:
If any Warnings are present, we should View Warning Details

Warning Details - Server cannot open ports on the router. Manually open port 1723. Small Business Server 2008
What we see here is a reminder to open TCP Port 1723 on our Firewall/Internet Router (i.e. create and Inboud rule passing PPTP traffic). Since our Firewall/Internet Router does not have PNP configuration enabled, we will do this manually later in the article.
Grant SBS 2008 Users permission to remotely access the Small Business Server network
Because Small Business Server takes care of configuring the Routing and Remote Access Service policies for us including which “Security Groups” are allowed VPN access, all that is left for us to do is make sure our VPN users are placed in the appropriate Group.
On Small Business Server 2008 that group is named: Windows SBS Virtual Private Network Users
Group assignment is still entirely wizard based in the new SBS, so being an Admin on the box is still very easy. Here’s how to assign VPN access rights to a User:
- Launch the SBS Console
- Select Users and Groups, then select the Users tab
- Select the User to whom you wish to assign the right to access the VPN.
- Open the Properties dialog for the User, select Remote Access
- click OK, your done! (and of course… move on to the next User until all users have been granted access)
A quick note about the new Groups in SBS 2008: Small Business Server has become far more granular with it’s permissions in the 2008 release. One aspect of this granularity can be found in the variety of new security Groups. To view these groups, select the Users and Groups [tab] in the WIndows SBS Console.
We can also view our specific target Group in assigning a User access to the Virtual Private Network: The Windows SBS Virtual Private Networking Users. This SBS specific VPN Group can be seen here in the Windows SBS Console.
Once Remote Access Services have been configured and once Users have been added to the Windows SBS Virtual Private Network Users security group, it’s time to configure the external Firewall and/or Internet Router Firewall.
Configuring the External Hardware Firewall for VPN Virtual Private Network access
Most Small Business Networks deploy a hardware firewall of some sort (or at least enable the firewall in the Internet Router). “How To” configure a hardware firewall varies from device to device so do your homework. You will need to consult the manufacturers resources and owners manual for specifics. In general , the key first step for our VPN is to open TCP port 1723 allowing PPTP Point to Point Tunneling Protocol traffic INBOUND to your SBS Server. The second step is to allowGRE and IPSec passthrough.
STEPS:
- PPTP “FIRST STEP” – TCP Port 1723 must be allowed to pass PPTP traffic INTO your SBS 2003 server. This is accomplished by port mapping traffic from the Firewall to the IP address of the Small Business Server (remember, the new SBS uses only 1 NIC).
- 1 NIC – create an INBOUND rule “port-mapping” TCP Port 1723 to the Local Area Network (LAN) facing Network Interface card – port mapping is generally done when only one network interface is installed on the SBS Server (NOTE: 1 NIC is the default now in SBS 2008). To pass VPN connection requests from a public facing IP, map them to the internal IP of the SBS 2008 Server.
- Your firewall may describe terms such as: PPTP, Port 1723, VPN, Remote Access, etc….
- GRE “SECOND STEP” – GRE Protocol 47 must be allowed to pass traffic also (this allows “Authentication” to occur over PPTP VPN connection once the connection has been made)
… Generic Routing Encapsulation (the GRE Protocol 47) passes IPSec traffic (Internet Protocol Security) for the IPSec session that is part of Client Computer connection process. If the GRE protocol does not pass, the connection cannot “authenticate”. This “Authentication” failure will occur even when PPTP traffic has been allowed by opening TCP Port 1723 (PPTP) on your firewall. GRE issues most often occur client side when a GRE block results in the Username and Password authentication failing to finish the authentication process because of the block. In this case, the VPN connection attempt simply times-out on the client side. This is experienced by the User as a Verifying User name and password dialog (show during the connection process) that just hangs there with the progress bar running on and on.
To pass GRE Protocol 47 on your firewalls (Client side -and- Server side) look for features that:
- enable the “VPN feature” (if one exists)
- enable “IPSec pass through” (if IPSec pass through exists)
- expressly allows the GRE protocol (GRE = Protocol 47)
- explicitly creates Inbound and Outbound rules allowing GRE and IPSec passthrough
- NOTE: you may have to upgrade your Router’s Firmware or your Firewall’s Firmware to enable/access these features on older devices
An explicit Rule (if you have to define one) would take on these objectives:
#PPTP Virtual Private Network
pass protocol tcp, to port 1723 >> state, done
pass protocol 47 >> done
Whatever the case, passing GRE Protocol 47 from inside>out is needed to allow IPSec traffic for your authentication. This is most often a concern for the end user at their home or reote location (meaning not the Server side – BUT ON THE CLIENT SIDE). Many home firewalls may block (and often do block) GRE traffic by default. Please provide these helpful links about GRE and passing Generic Routing Encapsulation traffic to your users.
- Troubleshooting remote access VPNs
- You receive an “Error 721″ error message when you try to establish a VPN connection through your Windows Server-based remote access server
- VPN Tunnels – GRE Protocol 47 Packet Description and Use
Testing a Client VPN Connection and confirming DHCP is assigning VPN IP Addresses
Once your VPN is setup and the Firewall rules established, testing your VPN is the next step. A Client Computer should be used to create a VPN Connection to the SBS 2008 Server and test the SBS 2008 VPN. Workstations have this connectivity built in and making the connection is as easy as using the Network Connection wizard available in both Windows Vista or Windows XP.
Since this article is about the Server side, I want to focus on one particularly “overlooked” aspect of VPN connections…. DHCP.
Earlier in our article (when we described just exactly what the Remote Access Setup Wizard accomplishes) we learned the RAS wizard completes this task:
- Use DHCP to assign IP addresses to remote client computers
The importance of this can be most effectivly communicated with a screenshot of the DHCP management console. This screen shot is taken after VPN connections have been made.
Looking at the DHCP console, we can see a series of leases assigned to the Remote Access Service (you can confirm a RAS lease is made just by looking under the Unique ID column for the word RAS ). In viewing DHCP we confirm both the RAS description on Unique ID as well as a different icon (computer with phone) for IP leases from RAS. Realizing then that RAS is handing out IP’s from DHCP , we recognize why the SBS DHCP service is so important to the Client VPN connections made through RAS.
When the Remote Acccess service is properly configured and a remote connection is made the the VPN, the Remote Access service grabs a range of IP addresses from DHCP. These IP’s are reserved for additional VPN clients “immediately” upon the first VPN connection being made. The default number of additional leases requested by RAS (and reserved from DHCP) is 10.
The reason we discuss this here is that Small Business Server 2008 is designed to shut down the DHCP Service “automatically” if it senses another DHCP Server anywhere on the network (routers, wireless routers, DSL modems, Firewalls, etc…). Although this may seem a little “off-topic”, in reality it’s not. In short, if DHCP fails or is disabled on SBS, there is no way for SBS DHCP to provide DHCP leases to RAS.
While most administrators review their network topology and know exactly how DHCP is implemented (some small offices do not). When the LAN has been happily functioning based on DHCP “working somewhere”, it’s not always a big deal. However, being clear on where and how IP’s are handed is very important for your VPN Connections. Not only this, but in some Small Business Server deployments I have been asked to review, DHCP is intentionally given over to the Internet Router so that if there is a Server failure, client computers can still access the internet. While this may be a reasonable solution on some levels (one I do not support BTW), it does negate all the additional DHCP configurations that are made or customized by the SBS DHCP Server. Failing to use the SBS DHCP Service in this case can lead to incorrect scope options, proper DNS Server not being defined, entires in SBS DNS never being seen by the network, and so on.
The key point for our article is this, if the DHCP Service has been assigned to an Internet Router or some other device in your network, the Remote Access Service may not be able to provide (or authorized to request) DHCP address to client computers making VPN connections.
A properly configured VPN that can appropriately access DHCP on Small Business Server 2008 will effectivvely provide DHCP leases to both client computers on the LAN and remote access computers connecting on the VPN.
To see this in it’s VPN form, let’s take a look at this sample IP Configuration from a client computer which has connected to a SBS VPN. In this Configuration please note there are two IP leases that have been made.
- one using the PPP WIGITAL VPN Connection
- note the ourcompany.pri Domain (provided by DHCP on the SBS 2008 Server)
- note the 10.13.15.x subnet (provided by DHCP on the SBS 2008 Server)
- one using the Wireless Network Connection
- note the my.homenetwork.local Domain (provided by the home network Wireless Service Set)
- note the 192.168.1.x subnet (provided by the home network Wireless Service Set)
To view this data: from the computer connected to the VPN, go to Start, Run, type CMD, at the command line type IPCONFIG /ALL
Windows IP Configuration
Host Name . . . . . . . . . . . . : my-mackbookpro
Primary Dns Suffix . . . . . . . : ourcompany.pri
Node Type . . . . . . . . . . . . : Broadcast
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : ourcompany.pri
my.homenetwork.localPPP adapter WIGITAL VPN Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WIGITAL VPN Connection
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.13.15.18(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 0.0.0.0
DNS Servers . . . . . . . . . . . : 10.13.15.1
Primary WINS Server . . . . . . . : 10.13.15.1
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter Local Area Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Marvell Yukon 88E8058 PCI-E Gigabit Ethernet
net Controller
Physical Address. . . . . . . . . : 00-2F-F3-D0-EE-93
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : YesWireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . : my.homenetwork.local
Description . . . . . . . . . . . : Brodcom 802.11n Network Adapter
Physical Address. . . . . . . . . : 00-2F-6B-CC-37-2C
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::b81a:ccdf:b0b4:254d%10(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.46(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Sunday, March 08, 2009 7:34:16 PM
Lease Expires . . . . . . . . . . : Monday, March 09, 2009 7:34:18 PM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Reviewing the IPCONFIG DATA should give us all ample reminder to check out DHCP, confirm DHCP is providing leases to the Remote Access Server and work with our client connections to make sure those leases are being handed out properly.
That concludes our article.
Thanks for reading. Please comment for the community. If this information has helped you, please link back here. It helps us as well as others who may need the information.
Thank you.
Mark Raborn
WIGITAL
PS…
| Note | |
| It is recommended that you set up a VPN only if Remote Web Workplace does not meet the needs of your organization. While Remote Web Workplace provides remote access to several network resources, some line-of-business applications require the computer to be connected to the network. For these scenarios, you can use a Virtual Private Network. For information about setting up Remote Web Workplace on Windows SBS 2008, see the Microsoft Web site ( http://go.microsoft.com/fwlink/?LinkId=105270 ). |
more
VPN Guide to Small Business Server 2003
Posted by Mark Raborn in VPN on 2009/03/08
Small Business Owners sometimes need their employees to access network resources from outside the office. One of the tools well suited to provide a Virtual Private Network connection to a company’s internal resources is Small Business Server 2003. Today’s article is about “How to Setup a VPN” ( Virtual Private Network) on SBS 2003 using the built in CEICW and RAS Wizards. We will also visit the Routing and Remote Access Service console in SBS 2003 (just a little bit) to see how access is granted and where current connections can be monitored.
BTW… our VPN walkthrough for SBS 2008 is here
How to configure a SBS 2003 VPN Server
Connect to Internet and open TCP port 1723 in RRAS Routing and Remote Access using the SBS 2003 CEICW
(NOTE: the default port for PPTP is TCP 1723)
- launch Server Management
- from the Home Page, select Internet and Email
- from the links in Manage Internet and Email, select Configure Remote Access
- this will launch the Configure Email and Internet Connection Wizard
- click Next and move through the configuration screens until you reach the Firewall configuration screen
- select ( ) Enable Firewall, click Next
- check the box [ ] Virtual Private Network, click Next
- click Next and move through the configuration screens until you reach the final Completing the CEICW configuration screen and click Finish
At this point the CEICW wizard has gathered the fields and parameters necessary to execute our selections. Most importantly for this walkthrough, CEICW configures the RRAS (Routing and Remote Access Service) for our VPN. This opens the firewall TCP port 1723 which is the default port for PPTP VPN traffic in Windows Server. The CEICW also opens other ports based on our selections for all services that the wizard has configured.
The next step (now that TCP Port 1723 is open), is to enable and configure the Remote Access Services (RAS).
Enable Remote Access and VPN from the SBS 2003 To Do List
- launch Server Management
- select the To Do List
- in the To Do List, select (3) Configure Remote Access
- this will launch the Remote Access Wizard ,click Next
- select ( ) Enable remote access
- select the check box [ ] VPN access
- if needed, select the check box [ ] Dial-in access
- enter the VPN Server Name and click Next
- at the Completing the Remote Access Wizard screen, click Finish
I consider this final page of the SBS 2003 Remote Access Wizard (directly above) a little gem for the Administrator. It’s helpful because it provides details informing us of what is about to occur:
- Enable virtual private networking (VPN)
- Create packet filters for Point-to-Point Tunneling Protocol (PPTP)
- Enable Point-to-Point Tunneling Protocol (PPTP) to pass through the firewall (NOTE: this step already completed using CEICW)
- Use DHCP to assign IP addresses to remote client computers
- Create the Client Connection Manager configuration file, which is used to configure remote access settings on remote client computers.
- Configure the remote access policy to allow members of the Mobile Users group to use remote access.
- Mobile client computers, such as laptops, that are currently connected to the local network can now be configured with the connection settings. Do this by running the Setup Computer Wizard and selecting the option to install Connection Manager.
- Remote client computers not currently connected to the local network can download Connection Manager from the Remote Web Workplace Web site at https://vpn.ourcompany.com/remote. Alternatively, you can create a remote connection disk. You can then use the disk to configure the remote client computer to connect to the local network.
Understanding where Remote Access Service lives in Small Business Server 2003
The Remote Access Service can be viewed by launching the Microsoft console for Routing and Remote Access Management (RRASMGMT.msc) from the Administrative Tools of Windows Server.
- GO TO Start menu
- hover over Administrative Tools and then select Routing and Remote Access
- the RRASMGMT.msc will launch
Among thenodes for Network Interfaces, Ports, and IP Routing are Remote Access Clients, Remote Access Policies and Remote Access Logging. It is here where the Remote Access Wizard has configured RAS to permit your Client Workstations and Client Laptops to connect to your VPN. Becoming familiar with the RRASMGMT console is important when managing, troubleshooting, and maintaining Remote Access to your server.
By looking at Remote Access Policies, we can see the RAS Wizard has created a Small Business Remote Access Policy (a set of rules to govern the connection – such as “who” can connect)
The Small Business Remote Access Policy Properties dialog box displays which Windows Groups must match the policy to be allowed access to the VPN. In this case, it is the SBS Mobile Users Group. Therefore, whatever users you intend to have access to the SBS 2003 VPN must have membership in the SBS Mobile Users Group.
Opening this Policy entry confirms that in Small Business Server 2003, there is only one Group by default that is granted access by the RAS Wizard. Adding users to this group is easy. As an administrator, access the Users tools in the SBS Server Management console. Any user may be granted VPN Access by giving them membership in the Mobile Users Security Group. (NOTE: Power Users Security Group, or Administrators Security Group also have access).
SBS Default User Templates are:
- Users Template
- Mobile Users Template (includes membership in the SBS Mobile Users Group)
- Power Users Template
- Administrator Users Template
The SBS Mobile Users is sufficient as Power Users and Administators obviously have additional access permissions.
To read more about RAS and Routing and Remote Access in Small Business Server, please read the Elements of a remote access policy section of the Remote Access Help.
Configuring the External Hardware Firewall for VPN Virtual Private Network access
Once the CEICW and RAS wizards have been properly run on the Small Business Server, the next step is configuring the hardware or “external” FIREWALL.
Most Small Business Networks deploy a hardware firewall of some sort (or at least enable the firewall in the Internet Router). How to configure a hardware firewall will vary from device to device. The key first step is to open the TCP port 1723 to pass PPTP Point to Point Tunneling Protocol traffic INBOUND to your SBS Server. Please read your firewall documentation to confirm your methods.
Key points include:
- PPTP “FIRST” – TCP Port 1723 must be allowed to pass PPTP traffic INTO your SBS 2003 server. This is accomplished in two ways depending on the number of Network Interface Cards installed on the SBS server.
- 2 NICs – create an INBOUND rule passing TCP Port 1723 to the Wide Area Network (WAN) facing Network Interface card installed on the SBS Server. This routes an Internet request to a special NIC uses specifically to harden access to the SBS Server (SBS 2 NIC scenario).
- 1 NIC – create an INBOUND rule “port-mapping” TCP Port 1723 to the Local Area Network (LAN) facing Network Interface card – port mapping is generally done when only one network interface is installed on the SBS Server and an outside IP address must be “mapped” to an internal LAN IP address. This routes a request from the Internet directly to a Local Network IP inside your network for the SBS Server (SBS 1 NIC scenario).
- Your firewall may describe these terms: PPTP, Port 1723, VPN, Remote Access, etc….
- GRE “SECOND but not least important” – GRE Protocol 47 must be allowed to pass traffic also (this allows “Authentication” to occur over PPTP VPN connection once the connection has been made)
… Generic Routing Encapsulation (the GRE Protocol 47) passes IPSec traffic (Internet Protocol Security) for the IPSec session that is part of Client Computer connection process. If the GRE protocol does not pass, the connection cannot “authenticate”. This “Authentication” failure will occur even when PPTP traffic has been allowed by opening TCP Port 1723 (PPTP) on your firewall. GRE issues most often occur client side when a GRE block results in the Username and Password authentication failing to process because of the block. In this case, the VPN connection simply times-out on the client side. This is experienced by the User as a Verifying User name and password dialog (show during the connection process) that just hangs there with the progress bar running on and on.
To pass GRE Protocol 47 on your firewalls (Client side -and- Server side) look for features that:
- enable the “VPN feature” (if one exists)
- enable “IPSec pass through” (if a simple IPSec pass through exists)
- expressly allow the GRE protocol (GRE = Protocol 47)
- explicitly create Inbound and Outbound rules allowing GRE and IPSec passthrough
- NOTE: you may have to upgrade your Router’s Firmware or your Firewall’s Firmware to enable/access these features on older devices
An explicit Rule (if you have to define one) would take on these objectives:
#PPTP Virtual Private Network
pass protocol tcp, to port 1723 >> state, done
pass protocol 47 >> done
Whatever the case, passing GRE Protocol 47 from inside>out is needed to allow IPSec traffic for your authentication. This is most often a concern for the end user (NOT THE SERVER SIDE – BUT ON THE CLIENT SIDE) in that their home firewalls may block and often block GRE traffic by default. Please provide these helpful links about GRE and passing Generic Routing Encapsulation traffic to your users.
- Troubleshooting remote access VPNs
- You receive an “Error 721″ error message when you try to establish a VPN connection through your Windows Server-based remote access server
- VPN Tunnels – GRE Protocol 47 Packet Description and Use
Connect Client Workstations to the Small Business Server 2003 VPN Virtual Private Network
For administrators it should be clearly understood: Clients that frequently connect to a VPN “should be JOINED” to the Domain. This includes users who work at home, mobile sales people (laptop users), etc… Joining COMPUTERS to the Domain achieves a fundamental goal (improving security) by enabling the Domain to authenticate the “computers” as well as the users. Verifying COMPUTER ACCOUNTS provides a 2nd additional form of identity and therefore an additional layer of security. Joining computers to the Domain happily also makes accessing domain resources much easier.
In Small Business Server specifically, special consideration must be given to the “way users are joined to the SBS domain”. Small Business Server primarily uses the connectcomputer wizard. This must be taken into account for VPN users when first establishing their connections to SBS as the SBS Network Configuration Wizard (i.e. connectcomputer wizard) cannot be invoked “over the internet”. Machines therefore, intended for VPN use, should be brought into the corporate office if at all possible.
Note, a manual join over the internet can be achieved “IF” the user has the Join Workstations to Domain User Right or if the Administrator has previously created the COMPUTER ACCOUNT on SBS.
The two solutions are:
- CONNECTCOMPUTER WIZARD: Bring Client Computer to the Office. Use CONNECTCOMPUTER wizard in SBS 2003. Join computers intended for VPN connectivity to the Domain while connected to the SBS LAN. It is really best (and simplest) to plug-in directly to the internal network (and the Small Business Server) prior joining workstations/laptops
- In this scenario the COMPUTER is connected to the LAN and the connectcomputer wizard is accessed using Internet Explorer and typing http://connectcomputer.
- Once joined, the computer(s) can be relocated offsite, placed in a remote offices, secured for mobile use, etc….
- NOTE: this provides the added benefit of also being able to distribute applications, scripts and policies right away throug your network via Group Policy.
- MANUAL JOIN: VPN computers can be manually joined to the domain by adding the COMPUTER account using traditional manual methods
- Administrators can first “manually add” the COMPUTER account on SBS Server (this is done in advance of a User connecting to the VPN). The User then connects to the VPN and then JOINs the machine to the Domain the first time. The Users must already be a member of the SBS Mobile Users Group to connect to the VPN. In this scenario the Users logs on to VPN – and then – using the computers System dialog, changes the DOMAIN NAME and the COMPUTER NAME to the Name created manually by the Administrator. This will JOIN the workstation to the domain
- End Users can also JOIN a computer to the domain if they are granted the Join Workstations to Domain User Right. The Users must already be a member of the SBS Mobile Users Group to connect to the VPN. In this scenario the Users logon to the VPN first – and then – using the computers System dialog, change the COMPUTER NAME themselves and JOIN the workstation to the domain themselves. End Users must be given the Join Workstations to Domain User Right to JOIN workstations outright with Administrator help (NOTE: this user right can be granted temporarily).
EXAMPLE – HOW TO CHANGE COMPUTER NAME AND DOMAIN NAME AND “JOIN A DOMAIN” FROM A REMOTE SITE (for your Mobile/Remote Users)
- Open the System tool in Control Panel
- ON WIndows XP and Windows Server 2003 clients, click the Computer Name tab and then click Change
- ON Windows 2000 clients, click the Network Identification tab and then click Properties
- enter the Computer Name provided by the administrator
- click OK confirm the settings
- restart the computer
- logon to the computer
- Connect to the SBS network using a VPN connection
- Open the System tool in Control Panel
- ON WIndows XP and Windows Server 2003 clients, click the Computer Name tab and then click Change
- ON Windows 2000 clients, click the Network Identification tab and then click Properties
- sele in the Member of section ct the radio button ( ) Domain:
- in the Domain: field, enter the name of your DOMAIN
- NOTE: the computer name should already have been changed correctly in the previous step (this is done in a 2 step process with a restart because I’ve seen failures numerous times on SBS if the COMPUTERNAME is not already configured when JOINING the network)
- click OK, click OK, restart the Computer
Testing a Client VPN Connection and confirming DHCP is assigning VPN IP Addresses
Once your VPN is setup and the Firewall rules established, testing your VPN is the next step. A Client Computer should be used to create a VPN Connection to the SBS 2003 Server and test the SBS 2003 VPN. Workstations have this connectivity built in and making the connection is as easy as using the Network Connection wizard available in both Windows Vista or Windows XP.
Since this article is about the Server side, I want to focus on one particularly “overlooked” aspect of VPN connections…. DHCP.
Earlier in our article (when we described just exactly what the Remote Access Setup Wizard accomplishes) we learned the RAS wizard completes this task:
- Use DHCP to assign IP addresses to remote client computers
The importance of this can be most effectivly communicated with a screenshot of the DHCP management console. This screen shot is taken after VPN connections have been made.
Looking at the DHCP console, we can see a series of leases assigned to the Remote Access Service (you can confirm a RAS lease is made just by looking under the Unique ID column for the word RAS ). In viewing DHCP we confirm both the RAS description on Unique ID as well as a different icon (computer with phone) for IP leases from RAS. Realizing then that RAS is handing out IP’s from DHCP , we recognize why the SBS DHCP service is so important to the Client VPN connections made through RAS.
When the Remote Acccess service is properly configured and a remote connection is made the the VPN, the Remote Access service grabs a range of IP addresses from DHCP. These IP’s are reserved for additional VPN clients “immediately” upon the first VPN connection being made. The default number of additional leases requested by RAS (and reserved from DHCP) is 10.
The reason we discuss this here is that Small Business Server 2008 is designed to shut down the DHCP Service “automatically” if it senses another DHCP Server anywhere on the network (routers, wireless routers, DSL modems, Firewalls, etc…). Although this may seem a little “off-topic”, in reality it’s not. In short, if DHCP fails or is disabled on SBS, there is no way for SBS DHCP to provide DHCP leases to RAS.
While most administrators review their network topology and know exactly how DHCP is implemented (some small offices do not). When the LAN has been happily functioning based on DHCP “working somewhere”, it’s not always a big deal. However, being clear on where and how IP’s are handed is very important for your VPN Connections. Not only this, but in some Small Business Server deployments I have been asked to review, DHCP is intentionally given over to the Internet Router so that if there is a Server failure, client computers can still access the internet. While this may be a reasonable solution on some levels (one I do not support BTW), it does negate all the additional DHCP configurations that are made or customized by the SBS DHCP Server. Failing to use the SBS DHCP Service in this case can lead to incorrect scope options, proper DNS Server not being defined, entires in SBS DNS never being seen by the network, and so on.
The key point for our article is this, if the DHCP Service has been assigned to an Internet Router or some other device in your network, the Remote Access Service may not be able to provide (or authorized to request) DHCP address to client computers making VPN connections.
A properly configured VPN that can appropriately access DHCP on Small Business Server 2008 will effectivvely provide DHCP leases to both client computers on the LAN and remote access computers connecting on the VPN.
To see this in it’s VPN form, let’s take a look at this sample IP Configuration from a client computer which has connected to a SBS VPN. In this Configuration please note there are two IP leases that have been made.
- one using the PPP WIGITAL VPN Connection
- note the ourcompany.pri Domain (provided by DHCP on the SBS 2008 Server)
- note the 10.13.15.x subnet (provided by DHCP on the SBS 2008 Server)
- one using the Wireless Network Connection
- note the my.homenetwork.local Domain (provided by the home network Wireless Service Set)
- note the 192.168.1.x subnet (provided by the home network Wireless Service Set)
To view this data: from the computer connected to the VPN, go to Start, Run, type CMD, at the command line type IPCONFIG /ALL
Windows IP Configuration
Host Name . . . . . . . . . . . . : my-mackbookpro
Primary Dns Suffix . . . . . . . : ourcompany.pri
Node Type . . . . . . . . . . . . : Broadcast
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : ourcompany.pri
my.homenetwork.localPPP adapter WIGITAL VPN Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WIGITAL VPN Connection
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.13.15.18(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 0.0.0.0
DNS Servers . . . . . . . . . . . : 10.13.15.1
Primary WINS Server . . . . . . . : 10.13.15.1
NetBIOS over Tcpip. . . . . . . . : EnabledEthernet adapter Local Area Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Marvell Yukon 88E8058 PCI-E Gigabit Ethernet
net Controller
Physical Address. . . . . . . . . : 00-2F-F3-D0-EE-93
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : YesWireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . : my.homenetwork.local
Description . . . . . . . . . . . : Brodcom 802.11n Network Adapter
Physical Address. . . . . . . . . : 00-2F-6B-CC-37-2C
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::b81a:ccdf:b0b4:254d%10(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.46(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Sunday, March 08, 2009 7:34:16 PM
Lease Expires . . . . . . . . . . : Monday, March 09, 2009 7:34:18 PM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Reviewing the IPCONFIG DATA should give us all ample reminder to check out DHCP, confirm DHCP is providing leases to the Remote Access Server and work with our client connections to make sure those leases are being handed out properly.
That concludes our article.
Thanks for reading. Please comment for the community. If this information has helped you, please link back here. It helps us as well as others who may need the information.
Thank you.
Mark Raborn
WIGITAL
Troubleshooting VPN Connections for Client Workstations and Laptops
Posted by Mark Raborn in VPN on 2009/03/07
Connecting to a Windows Domain based network can be very advantageous for remote workers who “really do need” access to their company or branch office Local Area Network (LAN). LAN access is not always necessary but when it is needed, connecting the proverbial dots is the first step. Today’s article is a pro-active attempt to help Users troubleshoot VPN Connections when they are “initially attempting to connect” to a company LAN from their home environments.
Assuming that the Remote Access Server at the Corporate Office has been properly configured and the firewall is set to allow VPN traffic, the next step is connecting from a client maching (i.e. a Laptop or Workstation outside the office). To accomplish a connection, the firewall in the location at which the “remote User” resides is going to have to be configured.
Let’s look at a sample connection attempt as a lesson in how we configure the “User side” Firewall and why we make these adjustments:
Step 1 – launch the VPN Connection
Step 2 – enter credentials for the Domain
Step 3 – attempting the connection
Failure message – cannot connect
This CANNOT CONNECT error (specifically when the error occurs prior to ever reaching the point where Verifying the username and password takes place) commonly occurs because TCP Port 1723 has not been opened.
- IF: a connection cannot be made??
- THEN: Oconfigure the Firewall to pass PPTP traffic (TCP Port 1723)
- IF: it appears as though a connection is being made BUT!!! the Verifying your user name and password screen is never reached or shown
- THEN: PPTP traffic is generally not being passed and you will need to configure the Firewall to pass PPTP traffic (TCP Port 1723)
Once a PPTP Point to Point Tranfer Protocol connection can be made, we can attempt the next step: Your VPN connection attempt must authenticate the User name and password of the user.
Let’s say that the first 3 steps above complete successfully.
- Step 1 – launch the VPN Connection = SUCCESS
- Step 2 – enter credentials for the Domain = SUCCESS
- Step 3 – attempting the connection = SUCCESS
and you reach the Verifying user name and password screen BUT!!! the Verifying user name and password screen “DOES NOT AUTHENTICATE SUCCESSFULLY”
EXAMPLE: a PPTP connection can be made but the Verifying user name and password screen simply persists and runs on for a long period time without authenticating. In this circumstance, the Connecting to succeeds but Authentication HAS FAILED…
If this occurs, Windows may offer this Error message (Vista example).
this is a Generic Routing Encapsulation (GRE) Protocol 47 error
Let’s learn a little more about GRE and review.
A simple VPN connection requires two primary rules to be configured on a Home Office / Remote Office firewall
- TCP Port 1723 (discussed above) must be allowed to pass traffic originating from Inside (permitting the PPTP Point To Point Protocol traffic used by the VPN) – this would take the form of an Outbound rule
- GRE Protocol 47 must be allowed to pass traffic originating from the inside (permitting IPSec traffic relating to the PPTP VPN connection) – this would also take the form of an Outbound rule
… the 2nd requirement, (the GRE Protocol 47) Generic Routing Encapsulation is required to pass IPSec (Internet Protocol Security) traffic for the IPSec session that is part of making the overall VPN Connection. If the GRE protocol does not pass, the connection can’t “authenticate” even though a connection has been made. A GRE block results in the Username and Password authentication failing and the VPN connection simply timing-out.
To pass GRE Protocol 47 on your firewall may:
- enable the “VPN feature” (if one exists)
- enable “IPSec pass through” (if a simple IPSec pass through exists)
- you may have to expressly allow the GRE protocol. GRE = Protocol 47)
- you may have to explicitly create an Outbound rule and then confirm that all requests made from the Internal network subsequently allow the returning traffic from outside to pass through to the Internal network once again (this causes the “State” on the internal side of the Firewall).
- NOTE: you may have to upgrade your Router’s Firmware or your Firewall’s Firmware to access these features
- NOTE: Some ISPs block VPN traffic intentionally (sometimes to sell a higher priced service that allows it). Most often though, configuring the Firewall properly is all that’s needed.
An explicit Outbound Rule (if you have to define one) would take on these objectives:
#PPTP Virtual Private Network
pass protocol tcp, to port 1723 >> state, done
pass protocol 47 >> done
Whatever the case, passing GRE Protocol 47 from inside>out is needed to allow IPSec traffic for your authentication. Here are some helpful links about GRE and passing Generic Routing Encapsulation traffic
- Troubleshooting remote access VPNs
- You receive an “Error 721″ error message when you try to establish a VPN connection through your Windows Server-based remote access server
- VPN Tunnels – GRE Protocol 47 Packet Description and Use
Try these articles and the above steps to find resolution to your VPN connection issues. Contact your administrator for additional help.
Thanks for reading. Please comment or link back to this article if it has helped you.
Mark Raborn
WIGITAL



































