Managing Routing And Remote Access in Windows Server 2003

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-5089192.html?tag=rbxccnbtr1

Takeaway: When you connect your network to the Internet, you don't want every machine to interface directly with it. Instead, you can use RRAS to allow your server to act as a barrier. Microsoft has updated RRAS in Windows Server 2003. Here's what you'll face.

Like its predecessors, Windows Server 2003 provides the ability to act as a router on your network and to provide remote access services to users outside your network. Routing And Remote Access (RRAS) in Windows Server 2003 provides VPN, routing, NAT, dialup and basic firewall services. Here's how to use and configure these services.

Getting started
To get started, open up the Routing And Remote Access configuration utility at Start | Administrative Tools | Routing And Remote Access. Initially, RRAS is not enabled on the server. To enable it, right-click the server on which you wish to enable the services and choose Configure And Enable Routing And Remote Access. In Figure A below, you can see that I am enabling the service on the server named RAS.

Figure A

Starting the initial RRAS configuration

The initial RRAS configuration starts a wizard that walks you through the steps that need to be taken to enable the services that you would like to offer. For the first example, I will enable VPN and NAT services on this server as shown below in Figure B.

Figure B

Choose the services you wish to support.

When configuring VPN services under Windows Server 2003, you generally need to have two network interfaces if you also want the remote users to be able to use other services on the network. If you want them to use just the services on the VPN server, a single interface will do. In either case, you need to select the interface which faces the Internet. In Figure C, the adapter with address 192.168.229.128 acts in this capacity while 192.168.1.103 is the LAN side of the server.

Figure C

Select the adapter that faces the Internet.

If you do decide to use Windows Server 2003’s VPN services, I still recommend the use of a hardware firewall between the Internet and your VPN server. Windows has too many holes to be allowed a direct connection to the Internet.

To work on the local network, remote clients need to be assigned appropriate IP addresses. You can choose to use your network’s DHCP for this purpose or you can specify a range of addresses that are used by RRAS. If you decide to use a range of addresses, make sure that you remove them from any DHCP scopes in order to prevent conflicts.

I prefer to provide RRAS with a range of addresses rather than use DHCP. By providing a range, I always know exactly which IP addresses are being used by remote users.

If you select the option to provide RRAS with a range of addresses, they are defined on the next step of the wizard, shown in Figure D. For this example, I have assigned 192.168.1.200 to 192.168.1.224. Remember to assign addresses from the right network. I’m not using the 192.168.229 network because that one faces the Internet, while 192.168.1 faces my network, which has the resources that remote users need.

Figure D

Provide a range of addresses for remote clients to use.

If you are using RADIUS to authenticate users for other services, you can include RRAS in the mix if you like. This is especially useful in larger networks as RRAS will simply forward authentication requests to the RADIUS server. For this example, I will not use RADIUS, as shown in Figure E.

Figure E

Do you want to use RADIUS for authentication?

That’s all there is initially to configuring VPN and NAT services. While there were no NAT specific configuration options during the wizard, NAT was enabled and configured based on responses to other questions. For example, the NAT interface was designated as network interface facing the Internet and the private interface was designated as the LAN interface.

NAT
Even though NAT was configured during the wizard, there will come a time when you want to modify its configuration. To view NAT parameters and statistics, from the RRAS console, choose Your Server | IP Routing | NAT/Basic Firewall, as shown in Figure F.

Figure F

NAT/Basic firewall parameters

To configure the NAT services, right-click an interface and choose Properties. This will display the External Network Properties screen shown in Figure G. Since it’s responsible for the most NAT functions, the external adapter has more options related to the service.

Figure G

NAT properties for the external network interface

The NAT/Basic Firewall tab provides a place for you to configure the details directly relating to the service. If you don’t want to do NAT, you can uncheck the box marked Enable NAT on this device and vice versa. You can also choose to enable a basic firewall on the interface. If your server is directly connected to the Internet, I can’t stress enough the importance of enabling the firewalling feature as well as defining appropriate inbound filters.

You can configure both inbound and outbound filters by clicking the associated button at the bottom of the window. You can define filters based on the traffic destination or source, by the source or destination ports, or by ICMP type.

The Address Pool tab, shown in Figure H, requires that you enter the ranges of IP addresses assigned by your ISP and available for use on the external interface for NAT applications. Once you have this information in place, you can reserve addresses for specific internal machines by clicking the Reservations button and providing the IP address of the internal machine and the NAT IP address you would like it to use. Additionally, you can allow incoming connections to this machine by selecting the Allow incoming connections to this machine box (not shown).

Figure H

The Address Pool tab

On the Services And Ports tab, seen in Figure I, you can configure the services on your network to which you would like to provide access. Since I have a VPN server on this system, some options such as L2TP, PPTP, IKE and IKE NAT Traversal are already enabled. (IKE NAT Traversal, you say? Yes - under Windows Server 2003 with the appropriate client on the remote machine, you can use IPSec when using NAT). If you run other services on your network to which you would like to provide access to Internet users, select it from the list.

Figure I

The Services And Ports tab

Finally, the ICMP tab, Figure J, provides a place where you can allow specific ICMP services such as PING to traverse the router. Since ICMP can be used for nefarious purposes as well as to provide troubleshooting information, be careful what you enable.

Figure J

The ICMP interface

Routing
Routing is a basic component to both providing VPN services and NAT services under RRAS on Windows Server 2003. These services configure the router in order to best provide their individual services. However, you can use your server to provide more granular routing services as well. Specifically, Windows Server 2003 supports the RIP2 (Routing Information Protocol version 2) and OSPF (Open Shortest Path First) routing protocols. Of course, static routing capability is also provided.

To add RIP2 or OSPF to your RRAS server, right-click General under Your Server | IP Routing. From the shortcut menu, choose New Routing Protocol. A list of the currently unused routing protocols will be presented. Select the one you wish to enable and click OK. Once enabled, an option for configuring that protocol will appear under the IP Routing option in the RRAS console.

General IP routing options
Under the General option in the IP Routing section, there are a number of things you can do. Selecting this option shows a list of available network interfaces including the internal and the loopback interfaces, as seen in Figure K.

Figure K

The General IP routing tab

To perform further operations on an adapter, right-click the adapter and choose Properties from the shortcut menu. As you can see below in Figure L, there are a number of things that can be configured including filters, whether or not TCP/IP is enabled on this interface, router discovery advertisements, and more.

Figure L

General interface configuration

RIP2
RIP2 is a distance-vector-based routing protocol which means basically that it directs traffic based on the number of router hops that have to be taken to reach a destination. It’s an excellent choice for small- to medium-sized networks where static routes have become unwieldy. To see which interfaces on which RIP is enabled, select the RIP option under IP Routing, which will show the screen in Figure M. See above if you have not yet enabled RIP.

Figure M

RIP-enabled interfaces

To configure RIP parameters, right-click an interface and choose Properties. The first tab is the General tab, shown in Figure N, which is where you can define general information about how RIP will operate on your server. On this tab, Operation Mode refers to how RIP will update its tables. The two choices are Auto-static Mode and Periodic Update Mode, which is the default. Auto-static Mode means that an update will be triggered when another router requests an update while Periodic Update Mode means that the routing table will be updated at a defined interval (defined on the Advanced tab).

Figure N

The RIP General tab

The General tab also provides a place for you to define the incoming and outgoing protocol. For outgoing packets, you can choose RIP1 broadcast, RIP2 broadcast, RIP2 multicast or silent RIP. In silent mode, the system only listens for new RIP announcements but does not make any itself. If your network uses consistent network masks throughout, you can use RIP1, but I don’t recommend it unless you have devices that can only use RIP1. You can also specify the route cost for this interface as well as a tag number for the routes on this interface. Finally, a password can be specified to be used for RIP2 updates as a means of identification.

As with everything, security is a concern with network routing. You don’t want bad routes propagating across your network and interrupting communications. Fortunately, the WS2K3 RIP service allows you to provide lists of incoming and/or outgoing route updates that should be ignored. This is accomplished on the Security tab, shown in Figure O.

Figure O

The RIP Security tab

The Neighbors tab, Figure P, lets you specify how the RIP service should interact with its neighbors. On this tab, you can configure RIP to only broadcast its routes, to broadcast its routes in addition to notifying each neighbor, or to just notify neighbors.

Figure P

The RIP Neighbors tab

Finally, the RIP Advanced tab, Figure Q, provides a place to configure more advanced parameters such as the update interval, route expiration time, whether split-horizon and/or poison reverse is enabled and much more. Split horizon and poison reverse are useful in preventing routing loops.

Figure Q

The RIP Advanced tab

OSPF
Like RIP, OSPF is a routing protocol but that is where the similarities end. While RIP is distance-vector-based (loosely, “hop count”) protocol, OSPF is a link state protocol meaning that OSPF routers exchange information about the current state of their network connections when making routing determinations. While more complex than distance vector protocols, using link state protocols can result in more efficient network traffic flow as each router always has a map of the network and its current state.

To enable OSPF, you need to define which interface(s) it will act on. To do this, right-click OSPF and choose New Interface from the shortcut menu. As an example, I’ll enable OSPF on my internal network.

The General tab for the OSPF properties for the interface defines whether or not OSPF is enabled, its Area ID, priority, cost and password as well as the network types. Since I’m using Ethernet, OSPF assumes a broadcast-based environment, as you can see in Figure R.

Figure R

OSPF is enabled on the internal interface

The NBMA neighbors tab, Figure S, is only used by X.25, ATM, and Frame Relay networks. This allows you to manually specify neighbors in these types of networks.

Figure S

OSPF NBMA Neighbors tab

The OSPF Advanced tab, Figure T, allows you to customize OSPF operation to your network by configuring options such as the MTU, Hello Interval, and Transmit Delay.

Figure T

OSPF Advanced tab

Static Routes
The old standby and most people’s introduction to IP routing, static routes are also available in RRAS. Static routes allow you to manually define routes for this server rather than using a routing protocol such as RIP or OSPF. Static routing is generally used on small, static networks.

To create a new static route, right-click Static Routes under IP Routing and select New Static Route from the shortcut menu. To define a static route, you need the destination network’s address (the network address for a network route or the host address for a host route), the network mask for the destination, and the IP address of the gateway used to get to this network. Figure U below shows a route from my RAS server to the network 172.16.1.0.

Figure U

A list of the static routes on the server

To see the current routing table, right-click Static Routes and choose Show IP Routing Table. Figure V shows the routing table from the RAS server I have been using in these examples.

Figure V

The IP routing table

That's it!
Remote VPN access, NAT, and IP routing are all integral parts of RRAS available in Windows Server 2003. While I don’t recommend a Windows server being directly exposed to the Internet, these services can still be safely used on the internal network to provide network connectivity and access to services that your users need

---

موضوعات مشابه:

• Configure Windows Small Business Server 2003 R2 Remote Access
• Managing Routing And Remote Access in Windows Server 2003
• Virtual Private Networking with Windows Server 2003: Deploying Remote Access VPNs

---

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-5814036.html?tag=rbxccnbtr1

Takeaway: Connect to a Windows Server 2003-based PPTP virtual private network (VPN) with this step-by-step user installation and configuration guide.

Once you get a Windows Server 2003 PPTP-based VPN up and running, you'll probably want to connect clients to the new service. For this article, I'm connecting to a Windows Server 2003 server that has the Remote Access role enabled, and that accepts incoming PPTP connections. Further, I've made sure that the user account I'm using to connect has been granted remote dial-in privileges. Steps to configure all of this, and more, are found in this article's companion piece. Finally, I'm using a Windows XP Professional SP2 machine for the connection, although these steps will work with pre-SP2 systems.
Network Connections is where it's at

Get started by visiting Start | Control Panel | Network Connections. Now, you need to create a new network connection. To do this, either go to File | New Connection, or click the Create a new connection option in the left hand pane, as shown below in Figure A.
Figure A

Whichever method you choose, the result is the same—the new connection wizard starts On the first screen of the wizard, which contains just information about the wizard's purpose, click Next.
The first useful screen of the wizard asks you to determine exactly what kind of network connection you'd like to create. For this article, you're connecting to a VPN, so choose the "Connect to the network at my workplace" option. It doesn't really matter where your VPN resides. Click Next when you're ready.
Figure B

Choose your network connection type There are two ways that you can connect to your workplace—(1) dial-up; or (2) VPN. For this step, select the Virtual Private Network connection option and click the Next button.
Figure C

Choose the Virtual Private Network connection option for this step The next step of the wizard asks you to name the new connection. You can use just about anything you want here since this just helps to keep track of what's what on your client machine. A name is useful if you have more than one VPN connection to manage.
Figure D

Name your connection to help keep track of it The next step of the wizard asks you to decide which users should be able to use this new connection. Do you want it available for just the use of the currently logged in user, or should it be available for any user? Keep in mind that, even if a connection is available to a logged in user that you don't want connected to the VPN, user must still provide valid credentials to actually attach to the VPN services. For this example, I've enabled the VPN connection for my use only.
Figure E

Who should be able to start this connection? Finally, you're finished creating the initial connection, as evidenced by a screen that looks like the one shown in Figure F. Click Finish.
Figure F

Your new connection is created Configure the connection

The Network Connection Wizard just creates the initial connection with common parameters. Now that it's created, you need to make modifications based on your environment. In particular, I've often run into trouble with Network Connection Wizard-created VPN connections' default gateway setting—more on that in a bit.
As soon as you're done with the Network Connection Wizard, the new connection pops up so that you can connect to the remote VPN server. The example, shown below in Figure G, contains the username and password, which I provided.
Figure G

Don't hit that Connect button quite yet… Before you hit the Connect button, take a little time to adjust the client settings. To do so, click the Properties button. I will go through most of the screens, and provide explanation where I recommend that you change the default settings.
General tab

There isn't much to change here, except if you need to change the name or IP address of the server to which you will connect. You can also configure this connection to dial a different connection before attempting to connect to the VPN. This is useful for clients that need to establish a dial-up connection before connecting to the VPN as it reduces the number of steps the remote user must take to attach to your server. Also located on this tab is a checkbox that enables the network adapter icon to appear in the system tray whenever this connection is active.
Short version: You don't need to make changes here if you provided all of the necessary information during the wizard.
Options tab

The Options tab provides choices for how to handle the initial connection and any subsequent redial attempts. The word "dial" on this screen is a little misleading since the options aren't strictly for modem-only users.
On this screen, you can dictate whether the system should provide you with information about the connection status and how user names, passwords and domain names should be handled. Further, you can tell Windows what to do if the connection is dropped—should it be automatically redialed or not, for example?
Figure I

The Options tab provides different ways of handling authentication and redialing Short version: You don't need to make changes here if you provided all of the necessary information during the wizard.
Security tab

As you can imagine, this is where you specify security settings for the connection. If you set up your VPN server as per the instructions in the previous article, you shouldn't need to change these settings. If you want to increase security, though, select the "Advanced (custom settings)" option and make sure those match your server setup. I won't be going into these options in this article, however. This article series' scope is simply to get a PPTP server up and running and accepting connections from clients.
One option I never recommend that you enable is the "Automatically use my Windows logon name and password (and domain if any)" option since it can result in a big, gaping security hole. Basically, if you forget to log out, or whatever, anyone that walks up to the client computer could connect to your organization's network and do what they will. It's not that much work to type a user name and password.
Figure J

The security tab has many different options for securing your connection Short version: You don't need to make changes here if you provided all of the necessary information during the wizard.
Networking tab

This tab provides a means for you to configure the various network options for this connection. The first option asks you about the type of VPN to which you're connecting. The default is Automatic meaning that Windows will determine whether the remote VPN is PPTP or L2TP. If you want, you can set this specifically to PPTP.
At the bottom of this window, you can change network settings, including IP addressing information. One setting, in particular, deserves attention: the choice of whether the VPN connection will use the default gateway of the remote network as its own default gateway. Most of the time, users will be connecting from home, from a hotel, or from a cybercafé of some kind—and they will probably be using a high-speed Internet connection.
By default, Windows configures new connections with the option enabled that uses the default gateway on the remote network. This can often cause problems with confused traffic, and you might find that a connected client is only able to use resources on the remote network when this is enabled. This setting may be required if you need to access resources on different subnets at your company. For example, if your VPN client gets an IP address on the 192.168.32.0 network, and you need to access resources from 172.16.1.0, you will either need to use the remote network's default gateway, or locally configure a number of static routes, which can be a pain. In these cases, use the remote network's default gateway and disconnect if you have trouble accessing Internet resources.
If you're on a smaller network, or only need to access resources on the local subnet, disable this gateway feature. To do so, select "Internet Protocol (TCP/IP)" from the item list at the bottom of the window and click Properties. On the resulting TCP/IP configuration page, click Advanced. On the Advanced settings window, uncheck the box "Use default gateway on remote network".
Figure K

If you want to change the gateway setting, select TCP/IP and click Properties Figure L

…Next, click the Advanced button… Figure M

…Finally, deselect this checkbox Short version: If you need to access resources on multiple networks at your company, use the remote gateway. If not, don't use the remote gateway.
Advanced tab

The Advanced tab does not have any options that would be useful for a typical connection. You can configure the Windows firewall and Internet Connection Sharing from this tab, though.
Figure N

The Advanced tab is used a lot for VPN connections Connect!

Now that you're connection is configured, you can click the Connect button on the main window. After you do so, you can select the connection in Network Connections and view its properties. You will get screen similar to the ones shown below in Figures O and P.
Figure O

The client has been connected to the server for a couple of minutes Figure P

And here are the details for the connection It works

This download provided a quick overview for getting a Windows Server 2003-based PPTP VPN up and running quickly and easily. It's not the most secure VPN in the world, but it works, and is simple, which is sometimes all that's needed

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-5034703.html?tag=rbxccnbtr1

Takeaway: Take advantage of Windows Server 2003s enhancements to VPN/remote access services

Virtual private networks have fast replaced dial-up connections as the preferred method for achieving remote access to corporate information resources. Although Windows NT and 2000 both boast remote access services, including VPN, Windows Server 2003 offers the next level of these services, providing a secure communications mechanism for your users and infrastructure.

The services at a glance
Windows Server 2003 provides a number of enhancements to VPN/remote access services that are superior to the features found in older versions of the operating system. The core support is still available for Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), IP Security (IPSec), Extensible Authentication Protocol (EAP), Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP 2) and Remote Access Services (RAS), but there are also some desirable new features.

In Windows Server 2003, Microsoft has improved the reach, security, and availability of the VPN services by providing NAT-aware L2TP/IPSec services and enabling VPN services to be used in conjunction with Network Load Balancing Services. Previously, to provide VPN services to clients behind NAT devices, the solution was to use the less secure PPTP.

To use L2TP/IPSec services from behind a NAT device, the remote end of the connection must be running a VPN client that supports drafts from the IPSec Protocol Working Group: Negotiation of NAT-Traversal in the IKE and UDP Encapsulation of IPSec Packets. Microsoft’s L2TP client has the appropriate support. The Network Load Balancing Services work in conjunction with both PPTP and L2TP/IPSec-based connections.

Windows Server 2003 also includes the ability to support client NetBIOS name resolution without the need for DNS and WINS servers through the use of a NetBIOS over TCP/IP (NetBT) name resolution proxy service running at the VPN server. This resolves some name resolution problems at the client side.

Up to 1,000 PPTP and 1,000 L2TP connections can be supported in Windows Server 2003 Standard and Enterprise editions, while a single connection of each type is supported in the Web edition. A single connection in the Web edition can help to support a secure remote administration mechanism.

Preparing the Windows Server 2003 system for VPN services
Like all other services in Windows Server 2003, the Routing And Remote Access Services (of which VPN is but one component) are disabled by default. Before they are enabled, a couple of things need to be verified. First, are two communications devices enabled at the server? At least one of them should be a network adapter. After all, the point of a remote access VPN is to provide access to internal network resources from outside the organization.

Second, check to make sure you’re running the proper protocols on your server and workstations. As far as protocols go, today’s typical VPN uses TCP/IP in one form or another with either PPTP or L2TP for security. To provide users with access to resources on the internal network via a VPN connection, you must distribute IP addresses to them. You can accomplish this via the network’s existing DHCP server or by defining an address pool in the Routing And Remote Access Services configuration. This will also provide the remote client with appropriate addressing information for DNS and WINS to enable efficient name lookups.

Allowing and restricting access
Any type of remote access to a network opens up the potential for abuse and unauthorized access, although you can take steps to mitigate these risks. For example, with Windows Server 2003 RRAS/VPN, you must explicitly allow each user to make use of the services by granting dial-in privileges in each user's profile. In addition, you can create strict policies, such as time of day restrictions, maximum session times, and MAC address restrictions, at the server to reduce the inherent security risk.

Enabling VPN services
To enable VPN services, you must enable Routing And Remote Access Services, which include VPNs. First, open Start | All Programs | Administrative Tools | Routing And Remote Access on the server where you want to support VPN. Next, right-click on the server name and choose Configure And Enable Routing And Remote Access. This will start a wizard that will help you configure these services.

RRAS includes a number of other capabilities besides VPN services, including NAT and dial-up (PPP). On the Configuration screen, shown in Figure A, you can specify which services you want to enable. For this example, we'll enable only dial-up/VPN.

Figure A

Enable VPN and/or dial-up services on the local server.

Choosing dial-up/VPN brings up the Remote Access screen, shown in Figure B. Here, you must select which of these services (or both) that you want to offer from this server. For this example, we'll choose only the VPN components.

Figure B

This server will allow only VPN connections.

Since VPN servers are generally installed with one interface facing outside the organization to support remote connections, the wizard will now display the VPN Connection screen, shown in Figure C. You'll need to identify which interface will act in this capacity.

Figure C

The 192.168.1.120 interface is used for remote connections.

On the VPN server in my lab for this exercise, I have two interfaces. The first interface’s address is 192.168.1.120/24 and the second’s is 192.168.2.2/24. Since this server is in my lab, it does not have a true “public” address. However, for the purposes of this example, I'll use the 192.168.1.120 interface. Below the interface list, you'll notice a check box indicating that static packet filters can be applied to this interface to allow VPN traffic only. I recommend that you enable this feature, especially if this interface is outside the corporate firewall.

To access resources on the internal network, the remote client needs an IP address that is allowed to do so. The IP Address Assignment screen, shown in Figure D, gives you two choices for automatically providing the client with an IP address. First, you can use an existing DHCP server on your network after making sure that it is configured properly. Second, you can provide the VPN server with a range of addresses that it can dole out to the clients.

Figure D

Choose an IP addressing mechanism.

I prefer the second method, as it makes me feel a little more in control. I have to provide a range of addresses, and it allows me to quickly determine just by looking at a list of IP connections to a server if they are internal or VPN clients. If you choose this method and are using addresses from the same space as your internal network, make sure you exclude the range you choose from any DHCP scopes you've defined on other DHCP servers to prevent addressing conflicts. For this article, we'll choose this option.

Because we’re assigning addresses from a specified pool, the pool or pools must be set up, which you’ll do on the Address Range Assignment screen, shown in Figure E. Unless you have specific needs, you can specify a range of addresses from the LAN side of the VPN server. In this example, that network is 192.168.2.0/24.

Figure E

Create an address space for remote clients.

To add a range, click the New button. You need to supply the starting address of the range and either the ending address or the number of addresses you would like in the pool. For this example, we'll create a range of 25 addresses ranging from 192.168.2.100 to 192.168.2.124.

A key aspect in providing remote access services is authentication. Without it, anyone can access your internal network as long as they can get to your VPN server. If your network includes a RADIUS server, the Windows Server 2003 VPN services are more than capable of using it for authentication. If you don’t have one, you can just let the RRAS services handle the authentication. You’ll specify authentication on the Managing Multiple Remote Access Servers screen.

After this step, the wizard will configure RRAS based on the parameters you specified. When the process is completed, you'll be notified that you need to allow DHCP relays to clients if you chose to use an existing DHCP server. You should then see a green arrow next to your local server on the RRAS screen indicating that the service is active, as shown in Figure F.

Figure F


More options are available now that RRAS is enabled.

Connecting clients
With the VPN server minimally installed to support PPTP and L2TP connections, you can now initiate these connections as long as the user has permissions to use the VPN services. One good thing about RRAS is that Windows does not automatically enable every user to use RRAS. Rather, an administrator needs to proactively enable this privilege for each user who needs it.

To enable someone to use the VPN services, start Active Directory Users And Computers. Next, right-click on a user object and choose Properties. On the properties page for the user, go to the Dial-in tab and choose the Allow Access option under Remote Access Permission (Dial-in Or VPN). Click Apply or OK to continue. The user will now be able to use the VPN services. In Figure G, the Administrator user VPN dial-in permissions are enabled, but this is for demonstration purposes only. I would not recommend enabling the Administrator user outside of a lab setting, since this account is a favorite target for exploitation.

Figure G

Enabling someone to use the VPN server

Testing the connection
With this out of the way, a client computer can now be connected to the VPN server using this user’s credentials. For this step, we'll use a Windows XP Professional SP1 client. This system resides on the outside of the network and needs to use the VPN services to gain access to the inside.

To begin, choose Start | My Network Places and choose View Network Connections from the Network Tasks shortcut menu. Next, click Create A New Connection. This will start a wizard to help you set up the connection.

The wizard first asks what kind of connection you want to create. Since this example is designed to test the new VPN server, choose the Connect To The Network At My Workplace option.

The next step asks whether this will be a dial-up or a VPN connection. Because your users are going to connect to a VPN, naturally you'll choose a VPN connection. The wizard will also ask for a name for this connection.

If you need to dial up to an ISP before establishing the VPN connection, you can allow the VPN connection to do so when you open it. If you're using DSL, a cable modem, or another always-on connection, you don't need to dial anything beforehand. The IP address or DNS name for the VPN server is required in the next step of the wizard. Finally, you need to provide the username and password credentials for a user who is allowed dial-in access to the network.

Click Connect to establish the connection. If everything is set up properly, you will be connected to the VPN server and be provided an IP address from the static pool that was created during the installation of the VPN server. As you can see in the VPN connection details for this test, shown in Figure H, the server IP address is the VPN server, and this connection has been assigned an IP address from the pool.

Figure H

These are the details for our VPN connection.

On the VPN server, you can also view details about the connection by choosing RRAS Console | VPN Server Name | Remote Access Clients and then right-clicking on the connection. Just choose Status from the shortcut menu, and you'll see the screen shown in Figure I.

Figure I

You can also view server details for our VPN connection.

It's as easy as that
To provide a better level of security, you can enable remote access policies that, for instance, allow only L2TP/IPSec connections or specific authentication types. VPN services in this new operating system are flexible and can give your users secure remote access to the network to increase their productivity

[patris1]

http://articles.techrepublic.com.com/5100-22_11-5302652.html?tag=rbxccnbtr1

Takeaway: Windows Server 2003 has many powerful features, including a built-in router. Here's how you can configure Windows Server 2003 to act as a router on your network.




Windows Server 2003 has many powerful features, including a built-in router. Why would you want to use Windows Server 2003 for routing? Because you can? Okay, that’s not really a good answer. But you’ve probably wondered why you'd use Windows Server 2003 as a router rather than using a dedicated router from Cisco, Bay Networks, or another manufacturer. In a lot of situations, a dedicated router makes more sense and is generally less expensive. There are situations, however, where it makes sense to use Windows Server 2003 for routing. Here's how you can configure Windows Server 2003 to act as a router on your network.
How Windows Server 2003 routing works

Windows Server 2003’s RRAS service supports several capabilities, one of which is supporting dial-up clients through POTS, ISDN, and other connectivity options. You can use integrated Windows authentication or rely on a RADIUS server (which could be the RRAS server) to authenticate clients. PPTP and L2TP support enable the RRAS server to function as a VPN server, giving remote clients a means of establishing a secure, private network connection to the LAN through a public network such as the Internet. Typically, the VPN connections come in through a dedicated, 24/7 Internet connection.
For example, assume you have three network segments, which currently are not interconnected, and you're setting up a remote access server on one of those segments. At the same time, you want to provide dial-up capability to each segment by remote clients. In this situation, it makes sense to install a single RAS server and let it provide routing services to all segments. Windows Server 2003 can fulfill both roles with no problem. So, using Windows Server 2003 as a router makes sense when you’re providing services to your LAN that require routing and no other routers are currently online to handle the traffic, or you don’t want the additional expense and management of a dedicated router in addition to your server.
Another reason to use Windows Server 2003 for routing is to provide DHCP Relay services for DHCP clients that reside on network segments where there is no DHCP server. Windows Server 2003 includes a DHCP Relay agent that provides this functionality in conjunction with RRAS.
A third reason to use Windows Server 2003 RRAS for routing is ease of use. Although router manufacturers have come a long way toward improving the configuration and management interfaces for their routers, the GUI management tools in Windows Server 2003 make it very easy to configure and manage Windows Server 2003 routers.
A Windows Server 2003 RRAS server can function as a dedicated router, connecting other routers continuously, or it can function as a demand-dial router. In this latter scenario, the router dials and connects to a remote router only when traffic that requires routing to the remote network comes to the router. Demand-dial routing is often used to reduce connectivity costs. If you send traffic over a metered connection only once or twice a day, for example, why pay for a full-time connection? With demand-dial routing, the router dials the remote network when traffic needs to be routed, then disconnects automatically after a defined period of inactivity. This helps keep costs down by keeping the connection live only when needed.
Understanding IP routing

Without IP routing, the Internet and many private networks would stop functioning instantly. Routing is a crucial aspect of IP networking. Understanding how routing works is the place to start when you’re thinking about setting up a Windows Server 2003 RRAS server to function as a router.
The primary function of a router, whether it is a dedicated box or a Windows Server 2003 router, is to route network packets between different network segments. When you open a browser to connect to a Web site, for example, your computer looks up the IP address of the remote site through DNS and then sends network packets to the remote site’s IP address to request the site’s content.
Your network router, identified by your workstation at its default gateway, receives the traffic, analyzes the destination IP address for the packets, and determines that the packets are destined for a network segment beyond your own. Based on its routing tables, the router sends the packet out on the appropriate interface to another router. The traffic gets routed through potentially several routers and eventually reaches the server where the site is hosted. Then, the process happens again in reverse for the traffic coming from the server to your computer.
Routers generally are connected to at least two subnets and, in effect, the router resides as a node in each of the subnets to which it is connected. This gives the router local connectivity to each of the subnets on which it resides and is the mechanism by which routing is possible. Figure A illustrates a router connected to three different subnets, which in turn are connected to other subnets and eventually the Internet. Each router is sometimes referred to as a “hop,” and a packet’s hop count is increased by one each time it passes through another router (more about this later).
Figure A

An example of a router connected to multiple subnets As the figure illustrates, Router A connects subnet 1 to subnets 2 and 3, which are in turn connected to the Internet by other routers, B and C. Router A therefore is assigned three IP addresses, one in each subnet, making it a member of each subnet and directly accessible to the nodes in each connected subnet. When a client in subnet 1 sends traffic destined for subnet 3, the traffic is directed to the client’s default gateway, which in this case is the IP address of the router at A1. The default gateway is defined in the client computer’s TCP/IP properties.
The router analyzes the packets when they come in to determine the destination address. Discovering that the traffic is destined for subnet 3, the router directs the traffic out the interface A3, based on its internal knowledge that the destination node must reside on subnet 3.
But what happens when the traffic is destined for a subnet that resides beyond the router’s locally connected segments, such as a remote Internet server? The router uses its routing table to determine which interface to use to route the traffic. The router’s default route, which you configure, is the route used when traffic is destined for an address that resides beyond the router’s local interfaces. The default route specifies the IP address of the router to which all traffic that isn’t destined for a known interface (also determined by the routing table) should be routed. So, the router analyzes the packet, recognizes that the destination IP address doesn’t match the subnets of defined routes in the routing table, and directs the packet to the default route. The router specified by the default route analyzes the packet and routes it based on its routing table.
Each route in a routing table falls into one of three categories:

• Network route: Provides a route to a specific network ID and all addresses within that network
• Host route: Provides a route to a specific host (A host route entry defines the host IP address as well as the network address.)
• Default route: Used to route traffic for which there is no corresponding network route or host route

The routing table contains routing entries against which the router checks the destination address of all packets to determine how to route each packet. Each entry in the routing table has specific general properties:

• Network ID, host address, subnet mask: These properties serve to identify the destination network ID or host address and the destination’s subnet. If the router determines that the destination address stored in the packet’s header matches these properties in a routing table entry, it forwards the packet to the forwarding address associated with the route (see next).
• Forwarding address: This is the address of the remote router to which the router forwards packets that match the network ID, host address, or subnet defined by the entry.
• Interface: This property specifies the local router port through which the traffic should be routed for packets that satisfy the criteria of the routing table entry.
• Metric: This value identifies the relative cost of the route, which is based on actual connection cost, available bandwidth, and other factors that you determine when you create a route. If more than one route exists for the same destination, the router uses the one with the lowest metric, if available.

Here’s a summary of the whole process: A packet comes into the router. The router analyzes the destination address in the packet’s header. The router then examines its routing table, attempting to match the packet’s destination address against the network ID, host address, or subnet properties of each routing table entry. If a match is found, the router directs the packet to the forwarding address defined by the matching routing table entry, using the interface and metric to decide how to physically route the packet out of the router. If the packet’s destination address doesn’t match any of the routing table entries, the router sends the packet to the forwarding address defined by the router’s default route. If no default route is defined, the packet is rejected and routing fails. The routing table is therefore the blueprint by which the router accomplishes its job.
How are routing entries added to the routing table? A router can learn its routes dynamically from other routers, or it can use statically defined routes, or static routes. With dynamic routes, routers communicate with one another to share learned routes, which enables routes to propagate to adjacent routers. Routing protocols are used to enable the routers to share this routing information. The two most common routing protocols are Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), both of which are supported by Windows Server 2003.
The administrator who configures the router creates static routes manually. In a small network with few subnets, static routes are an effective means of routing all traffic. As the number of routers grows, however, dynamic routing becomes more desirable because of the reduced management overhead. You don’t have to manage existing routes or create new ones when another segment is added to the network. Instead, the router learns its routing table from adjacent routers automatically when the router comes online.
Overview of RIP

Of the two routing protocols included with Windows Server 2003, RIP is easier to configure. RIP is limited to a maximum hop count of 15, making RIP useful for small- to medium-size installations. Any address more than 15 hops away is deemed unreachable by the router.
Each time a router boots, it re-creates its routing table. The routing table initially only contains the routing table entries for physically connected networks. A router using RIP periodically broadcasts announcements regarding routes, which enables adjacent routers to modify their routing tables. So, after a router comes online, it begins using RIP announcements to build its routing table. Also, RIP provides for triggered updates in addition to broadcast updates. These triggered updates occur when a router detects a network change, such as an interface going down. The router then broadcasts the change to adjacent routers, which modify their routing tables accordingly. When the interface comes back up, the router that recognizes the change broadcasts a triggered update to adjacent routers, which again modify their routing tables to accommodate the change.
Windows Server 2003 supports RIP version 1 and version 2. RIP v2 provides additional features over RIP v1, such as authentication for security and route filtering. RIP v2 also supports multicast broadcast of RIP announcements and several other features. RIP v1 routers are forward-compatible with RIP v2 routers, enabling them to coexist.
Overview of OSPF

OSPF was developed to address the needs of large networks, such as the Internet. Each OSPF router maintains a link-state database (LDB) that contains link-state advertisements (LSAs) from adjacent routers. The LSA contains information about a router, its connected networks, and configured costs. The cost is similar to a route metric discussed earlier, in that it defines the relative cost of using the route. OSPF uses an algorithm to calculate the shortest path for routing based on the information contained in its LDB, making it a very efficient means of routing. Adjacent routers recalculate and synchronize their LDBs as network changes occur, such as network interfaces going down or coming online.
OSPF is more complicated to configure than RIP. Its performance advantages are geared primarily toward very large networks, so if you’re setting up a router for a small- or medium-size network, RIP is generally the better option. Where network size is a factor, however, OSPF is the better choice.
Unicast routing vs. multicast routing

Another important aspect to understand about routing is the difference between unicast routing and multicast routing. In unicast routing, a packet is sent from one node to only one other node, as illustrated in Figure B. This is the most common type of routing and the one you use every time you open a Web browser and browse an Internet site, retrieve your e-mail, move a file with ftp, and perform most other common IP-based network tasks.
Figure B

Unicast routing directs packets from one node to another. In multicast routing, however, traffic is broadcast from one node to many nodes, as illustrated in Figure C. Multicasting is most commonly used for audio and video conferencing, enabling packets to be efficiently transmitted to multiple clients from a single host. Without multicasting, the packets would have to be transmitted multiple times to each client, generating a considerably larger amount of network traffic and imposing more overhead on the server. Plus, as you can imagine, conferencing would be difficult to set up without multicasting, as the conferencing server would need to be preconfigured with the list of all participants. With multicasting, the participants simply listen on a designated multicasting address, which can be allocated by a DHCP server to automate configuration.
Figure C

Examples of conferencing with and without multicasting Configuring a unicast router

As with other RRAS configurations, you can use the RRAS wizard to configure Windows Server 2003 as a router. Setup installs RRAS by default, so you only need to enable and configure the server according to your routing needs. To start the RRAS wizard, open the RRAS console from the Administrative Tools folder. Right-click the server and choose Configure And Enable Routing And Remote Access. In the wizard, select the option to configure a network router. The wizard prompts you for the following information:

• Protocols: Select the protocols to be supported for routing, such as TCP/IP and/or IPX. If the protocols are not installed, the wizard gives you the option of adding them. By default, all installed protocols are enabled for routing, but you can choose to disable some if you don’t want the protocol to be routed.
• Use demand-dial connections: You can choose to enable demand-dial routing at this point or accomplish the task later.

In addition to configuring the router through the wizard, you also can enable routing manually. You need to choose this latter option if the server is already configured and enabled for RRAS (such as a VPN server) and you want to add routing to the server’s list of roles.
To enable routing for a server that already has RRAS enabled, open the RRAS console from the Administrative Tools folder. Right-click the server and choose Properties. Select the Router check box and then select the type of routing you want to support, either LAN or LAN and demand-dial. Then click OK.
Next, configure the IP address for which RRAS performs routing on that interface. By default, Windows Server 2003 uses the first interface to process routing tasks on that interface, and on interfaces with only one address, no configuration is needed. If the interface has multiple addresses, however, you’ll need to reconfigure RRAS if the default address is not the one you want to use. To configure the address, open the RRAS console, expand the server, and expand the IP Routing branch. Click General and, in the right pane, right-click the interface you want to modify and choose Properties. Use the Configuration page to set the IP address, subnet mask, and default gateway (if needed) for the interface. To set the metric for the interface, click Advanced.
Configuring a router with static routes

At this point, I assume you have the server enabled for routing and have configured the desired address on each interface. Now it’s time to think about how you’ll implement routing. As mentioned earlier, you can use static routes, RIP, or OSPF (if the router only routes traffic between two subnets, you don’t need to worry about creating routes or using RIP or OSPF). Let’s take a look at static routes, which are a good option if you’re setting up your Windows Server 2003 RRAS router in a small network.
For this example, we’ll use privately addressed network segments. Figure D shows our sample network structure. We’ll work on configuring router B, which we’ll assume has two network interfaces. As Figure D illustrates, router B resides on subnets 192.168.0.n and 192.168.1.n. The IP addresses of the router’s interfaces are 192.168.0.20 (LAN 0) and 192.168.1.1 (LAN 1). In these examples, I’ve renamed the network interfaces from their default names of Local Area Connection and Local Area Connection 2 to LAN 0 and LAN 1, respectively. It’s a good idea on multihomed systems to rename the interfaces to help you keep track of what’s what. To rename the interfaces, open the Network And Dial-Up Connections folder, right-click an interface, and choose Rename.
Figure D

Sample network for configuring routing Let’s add a static route at Router B to route traffic to the 192.168.2.0 subnet (subnet 2) through interface LAN 1. To add a static route, first open the RRAS console. Expand the IP Routing branch and click Static Routes. Either right-click in the right pane or right-click Static Routes and choose New Static Route. RRAS displays the Static Route dialog box in which you provide the following data:

• Interface: Choose the network interface that RRAS should use to route traffic that meets the static route criteria. In this example, you want to configure a static route for traffic destined for 192.168.2.0 to be routed through LAN 1, so select the LAN 1 interface.
• Destination: Rather than create a host route, you’ll create a network route. Enter the network ID of the destination network, which in this example is 192.168.2.0. Remember that the router compares the destination IP address of incoming packets against this network address to determine if the route entry matches and if the route is appropriate for routing the packets. You can specify a network address, host address, or use 0.0.0.0 for this value (this latter option creates a default route). Use the low network address to specify a network address, as I did in this example, or specify the actual IP address of the host if creating a host route.
• Network mask: Specify the subnet mask of the destination network or host. In this example, enter 255.255.255.0, the subnet mask for our Class C private network.
• Gateway: Specify the IP address to which packets matching the route criteria are routed. In this example, you need to specify the IP address of Router C on the 192.168.1.0 subnet. As you can see from Figure D, the address to enter is 192.168.1.2.
• Metric: Enter the relative cost for the route by specifying a metric. If more than one route exists, the one with the lowest metric is used to route the traffic if that route is available.
• Use this route to initiate demand-dial connections: If you have configured at least one demand-dial interface for the router, this option is available. Select this option if you want the router to initiate a demand-dial connection when it receives traffic that matches the selected route.

Next, you create a static route to accommodate the 192.168.3.0 subnet. The data for this static route is the same as the one you just created, except the destination network address is 192.168.3.0. The Gateway is the same as in the previous route. The static routes you set up on Router C handle the traffic from that point, routing it to Router D.
Finally, you should create a default route on Router B that directs all other traffic not destined for subnets 1, 2, or 3 to Router A, with the assumption that the traffic is destined for a public address on the Internet. So, create another static route on Router B using the following values:

• Interface: LAN 0
• Destination: 0.0.0.0
• Network mask: 0.0.0.0
• Gateway: 192.168.0.1
• Metric: As desired
• Use this route to initiate demand-dial connections: As needed

It's not all that bad

You can see that setting up static routes takes a little work but can be an effective means of configuring routing for small networks. As the number of routers you manage grows, you’ll likely turn to RIP and/or OSPF to provide dynamic routing. While RIP and OSPF are a little more complicated to set up, they are much easier to manage. In an upcoming article, we’ll take a detailed look at both protocols, as well as demand-dial routing and multicast routing

[iceninja]

how maping aport in windows 2003 ?