Project Report on 2K8

8/3/2019 Project Report on 2K8

1/38

Routing & RemoteAccess Services

Jetking Institute of Computer Hardware & Networking

2011

1/9/2011


2/38

Page 2

Project Report

Prepared By :-

Gondaliya Yogesh D.

Guidance by:-

Mr. Suresh Suthar Sir

At

Jetking Institute of Computer Hardware & Networking

Ashram road Ahmadabad


3/38

Page 3

Institute of Computer Hardware & Networking

Certificate

This is certify that Mr.Has satisfactorily completed his academic Project-Work on

As a part of the

following course prescribed by the Jetking Institute for the academic

year

Roll No:

Exam Date:

Project Guide Director Examiner


4/38

Page 4

INDEX

No. Name Page No.1 Certificate 3

2 Introduction of Routing & Remote Access

Services

5

3 Required Component to use RAS 6

4 Protocol 7

5 Remote Access 11

6 Routing 13

7 Installing the RRAS 14

8 Troubleshooting of RRAS 18

9 Common Routing Errors 34

10 About Us 37

11 Biblography 38


5/38

Page 5

Introduction of Routing & RemoteAccess Services

A Windows Server 2008 computer that runs the Routing and Remote Access

Server role can provide a number of different type of remote access connectivityfor your network clients. This includes remote access for clients, either using Dial-

up or VPN access. The RRAS services allow you to configure a Windows Server

2008 computer to act as a Network Address Translation (NAT) device, which

allow internal network clients to connect to the internet using a single shared IP

address; you can configure a 2008 server to function solely as a NAT device, or

else to provide both NAT and VPN services simultaneously. Finally, you can

configure a windows server 2008 computer to create a secure site-to-site

connection between to private network, such as two branch offices that need to

connect securely to one another over a public network such as the internet.

Routing, or the process of transferring data across an internetwork from one LAN

to another, provide the basis for the Internet and nearly all TCP/IP network

communication between multiple organizations.

The Routing and Remote Access service in the Windows Server 2008 operatingsystem provides remote users access to resources on your private network over

virtual private network (VPN) or dial-up connections. Servers configured with the

Routing and Remote Access service can provide local area network (LAN) and

wide area network (WAN) routing services used to connect network segments

within a small office or to connect two private networks over the Internet.


6/38

Page 6

Required components to use RAS

Required components to use RAS on Clients* Networking

* Transport Prococol (NetBEUI, NWLink, TCP/IP) - The best protocol

depends on line conditions. TCP/IP is best when line conditions are

poor, but it is slower. If line conditions are good, and speed is

desired, use NetBEUI.

* Workstation service for NTWS or Client for Microsoft Networks fro

Windows 95

Required Server components* Modems or ISDN interface or X.25 PAD. Modems are configured

using the control panel modems applet. ATM and ISDN is installed using

the control panel network applet.

* Networking

* Must run the "Routing and Remote Access" service. This service is

only available on servers but is installed by default.


7/38

Page 7

ProtocolsConnection Protocols Supported

* Point to Point Protocol (PPP) - Point to Point Protocol is a form of serial line

data encapsulation that is an improvement over SLIP which provides serial bi-

directional communication. Packets are delivered in the order they were sent. It is

much like SLIP but can support AppleTalk, IPX, TCP/IP, and NetBEUI along with

TCP/IP which is supported by SLIP. It can negociate connection parameters suchas speed, transport protocol, and selection of PAP or CHAP user authentication

method.

* Serial Line Interface Protocol (SLIP) - Serial Line Internet Protocol. This

protocol places data packets into data frames in preparation for transport across

network hardware media. This protocol is used for sending data across serial

lines. There is no error correction, addressing, compression, or packet

identification. There is no authentication or negotiation capabilities with SLIP. SLIPwill only support transport of IP packets.

* CSLIP - Compressed SLIP is essentially data compression of the SLIP protocol.

It uses Van Jacobson compression to drastically reduce packet overhead by

reducing the TCP/IP headers and not the data. It requires CSLIP support on both

the client and server ends. This may also be used with PPP and called CPPP.

* Point to Point Multilink Protocol - Combines bandwidth from several physical

connections into one logical connection.

* Microsoft RAS - Also known as AsyBEUI.


8/38

Page 8

Other Protocols* Callback Control Protocol (CBCP) - Allows the server to negociate with the client

to call the client back to establish the connection.

VPN Protocols

* Point to Point Tunneling Protocol (PPTP) - Point-to-Point Tunneling Protocol

(RFC 2637) works at the link layer. No encryption or key management included in

specifications. A VPN tunneling Protocol used to send secure communications

from point to point. It is used to access a network through the network using the

speed of a modem. It uses PPP encryption or Microsoft Point to Point Encryption(MPPE) over TCP as a transport protocol. This means that PPP packets are

encrpted, then placed in TCP packets and sent over the internet. On the other

side, the information is unwrapped and decrypted and sent on as PPP. Therefore

the same protocols supported by PPP are supported with PPTP (AppleTalk, IPX,

TCP/IP, and NetBEUI). PPTP Installation is done with the Routing and Remote

Access Administration Tool.

* Layer Two Tunneling Protocol (L2TP) - Layer2 Tunneling Protocol. (RFC 2661)

combines features of L2F and PPTP and works at the link layer. No encryption or

key management is included in specifications. A VPN tunneling Protocol. It uses

IPSec for encryption. It puts data in PPP packets, then adds more headers to route

the packet. L2TP supports header compression and tunnel authentication

support, and PPTP does not.L2TP Installation is done with the Routing and

Remote Access Administration Tool. It is a new protocol with Windows 2000.

* IPSec - Internet protocol security, developed by IETF, implemented at layer 3.

it is a collection of security measures that address data privacy, integrity,

authentication, and key management, in addition to tunneling. Does not cover

key management. A VPN tunneling Protocol. It is a new protocol with Windows

2000.


9/38

Page 9

o IPSec installation - It is installed in Windows 2000 from the Microsoft

Management Console (MMC) by adding the "IP Security Policy Management"

snap-in and choosing the computer the new snap-in will manage.

o IPSec Configuration - Once installed, IPSec is configured from the TCP/IPproperties dialog box in "Network and Dial-up Connections" for the connection

you want to configure.

1. In the TCP/IP properties box, click "Advanced".

2. Click on "Options"

3. Select "IP Security", and click "Properties".

The allowed settings are "Do not use IPSEC" or "Use the IP security policy".

The choices are:

+ Client (Respond Only)

+ Secure Server (Require security)

+ Server (Request Security)

Authentication Protocols Supported* PAP - Password Authentification Protocol is a two way handshake protocol

designed for use with PPP. Authentication Protocol Password Authentication

Protocol is a plain text password used on older SLIP systems. It is not secure.

* CHAP - Challenge Handshake Authentication Protocol is a three way

handshake protocol which is considered more secure than PAP. Authentication

Protocol.

* MS-CHAP (MD5) - Uses a Microsoft version of RSA message digest 5

challenge and reply protocol. It only works on Microsoft systems and enables

data encryption. Selecting this authentification method causes all data to be

encrypted.


10/38

Page 10

* RADIUS - Remote Authentication Dial-In User Service used to authenticate

users dialing in remotely to servers in a organization's network. It can be used

to track users' time on networks. User information is sent to a RADIUS server

for validation when the user logs on to a network. It is a new protocol with

Windows 2000. The RAS server must be configured as a RADIUS client on the

Remote Access Service properties dialog box security tab. The RAS server may

be configured to use any of several RADIUS servers for user authentication.

The "Configure" button is used to add or remove RADIUS server information.

The working sequence between the RAS server and the RADIUS server is as

follows:

1. A server running Remote Access Service (RAS) receives a connection

request from a user on a remote computer.

2. The remote computer is requesting RADIUS authentication.

3. The RAS server forwards the request to a RADIUS server for

authentication. (The RAS server becomes a RADIUS client).

4. The Internet Authentication Service (IAS) on the RADIUS server

responds to the request from the RAS server. (IAS can be installed and

configured in the Control Panel network services dialog box.

5. The RAS server takes appropriate action in verifying the user based on

the RADIUS server response.

* EAP - Extensible Authentication Protocol is used between a dial-in client

and server to determine what authentication protocol will be used. Used to

support smart card and other high tech forms of authentication through its

support of Transport Layer Security (TLS) which is used by these devices. It is a

new protocol with Windows 2000.


11/38

Page 11

What does Routing and Remote Access service do?

The Routing and Remote Access service in Windows Server 2008 provides:

* Remote access

* Routing

Remote access

By configuring Routing and Remote Access to act as a remote access server, you

can connect remote or mobile workers to your organization's networks. Remote

users can work as if their computers are physically connected to the network.

All services typically available to a LAN-connected user (including file and printer

sharing, Web server access, and messaging) are enabled by means of the remote

access connection. For example, on a server running Routing and Remote Access,

clients can use Windows Explorer to make drive connections and to connect to

printers. Because drive letters and universal naming convention (UNC) names are

fully supported by remote access, most commercial and custom applications work

without modification.

A server running Routing and Remote Access provides two different types of

remote access connectivity:


12/38

Page 12

* Virtual private networking (VPN)

VPN is the creation of secured, point-to-point connections across a private

network or a public network, such as the Internet. A VPN client uses special

TCP/IP-based protocols called tunneling protocols to make a virtual call to a

virtual port on a VPN server. The best example of virtual private networking is

that of a VPN client that makes a VPN connection to a remote access server that is

connected to the Internet. The remote access server answers the virtual call,

authenticates the caller, and transfers data between the VPN client and the

corporate network.

In contrast to dial-up networking, VPN is always a logical, indirect connection

between the VPN client and the VPN server over a public network, such as the

Internet. To ensure privacy, you must encrypt data sent over the connection.

* Dial-up networking

In dial-up networking, a remote access client makes a nonpermanent, dial-up

connection to a physical port on a remote access server by using the service of a

telecommunications provider, such as analog phone or ISDN. The best example of

dial-up networking is that of a dial-up networking client that dials the phone

number of one of the ports of a remote access server.

Dial-up networking over an analog phone or ISDN is a direct physical

connection between the dial-up networking client and the dial-up networking

server. You can encrypt data sent over the connection, but it is not required.


13/38

Page 13

Routing

A router is a device that manages the flow of data between network segments, or

subnets. A router directs incoming and outgoing packets based on the

information it holds about the state of its own network interfaces and a list of

possible sources and destinations for network traffic. By projecting network traffic

and routing needs based on the number and types of hardware devices and

applications used in your environment, you can better decide whether to use a

dedicated hardware router, a software-based router, or a combination of both.Generally, dedicated hardware routers handle heavier routing demands best, and

less expensive software-based routers handle lighter routing loads.


14/38

Page 14

Installing the Routing & Remote AccessServices

By default, the Routing and Remote Access service is installed automatically

during the Windows Server 2003 installation, but it is disabled.

To Enable the Routing and Remote Access Service

1. Click Start, point to Administrative Tools, and then click Routing and Remote

Access.

2. In the left pane of the console, click the server that matches the local server

name.

If the icon has a red arrow in the lower-right corner, the Routing and Remote

Access service is not enabled. Go to step 3.

If the icon has a green arrow pointing up in the lower-right corner, the service

is enabled. If so, you may want to reconfigure the server. To reconfigure the

server, you must first disable Routing and Remote Access. To do this, right-click

the server, and then click Disable Routing and Remote Access. Click Yes when you

are prompted with an informational message.

3. Right-click the server, and then click Configure and Enable Routing and

Remote Access to start the Routing and Remote Access Server Setup Wizard. Click

Next.

4. Click Remote access (dial-up or VPN) to permit remote computers to dial in orconnect to this network through the Internet. Click Next.

5. Click VPN for virtual private access, or click Dial-up for dial-up access,

depending on the role you want to assign to this server.


15/38

Page 15

6. On the VPN Connection page, click the network interface that is connected to

the Internet, and then click Next.

7. On the IP Address Assignment page, do one of the following:

* If a DHCP server will be used to assign addresses to remote clients, click

Automatically, and then click Next. Go to step 8.

* To give remote clients addresses only from a pre-defined pool, click From

a specified range of addresses.

NOTE: In most cases, the DHCP option is simpler to administer. However, if

DHCP is not available, you must specify a range of static addresses. Click Next.

The wizard opens the Address Range Assignment page.

1. Click New.

2. In the Start IP address box, type the first IP address in the range of

addresses that you want to use.

3. In the End IP address box, type the last IP address in the range.

Windows calculates the number of addresses automatically.

4. Click OK to return to the Address Range Assignment page.

5. Click Next.

8. Accept the default setting of No, use Routing and Remote Access to

authenticate connection requests, and then click Next.

9. Click Finish to enable the Routing and Remote Access service and to configure

the remote access server.


16/38

Page 16

To set up a client for dial-up access, follow these steps on the client workstation.

NOTE: Because there are several versions of Microsoft Windows, the following steps may be

different on your computer. If they are, see your product documentation to complete these

steps.

1. Click Start, click Control Panel, and then double-click Network Connections.

2. Under Network Tasks, click Create a new connection, and then click Next.

3. Click Connect to the network at my workplace to create the dial-up

connection, and then click Next.

4. Click Dial-up connection, and then click Next.

5. On the Connection Name page, type a descriptive name for this connection,and then click Next.

6. On the Phone Number to Dial page, type the phone number for the remote

access server in the Phone Number dialog box.

7. Do one of the following, and then click Next:

* If you want to allow any user who logs on to the workstation to have

access to this dial-up connection, click Anyone's use.

* If you want this connection to be available only to the currently logged-on

user, click My use only.

8. Click Finish to save the connection.


17/38

Page 17

To set up a client for virtual private network (VPN) access, follow these steps on

the client workstation.

NOTE: Because there are several versions of Microsoft Windows, the following steps may be

different on your computer. If they are, see your product documentation to complete these

steps.

1. Click Start, click Control Panel, and then double-click Network Connections.

2. Under Network Tasks, click Create a new connection, and then click Next.

3. Click Connect to the network at my workplace to create the dial-up

connection, and then click Next.

4. Click Virtual Private Network connection, and then click Next.

5. On the Connection Name page, type a descriptive name for this connection,

and then click Next.

6. Do one of the following, and then click Next.

* If the computer is permanently connected to the Internet, click Do not dial

the initial connection.

* If the computer connects to the Internet by way of an Internet service

provider (ISP), click Automatically dial this initial connection, and then click the

name of the connection to the ISP.

7. Type the IP address or the host name of the VPN server computer (for

example, VPNServer.SampleDomain.com).

8. Do one of the following, and then click Next:

* If you want to allow any user who logs on to the workstation to have

access to this dial-up connection, click Anyone's use.


18/38

Page 18

* If you want this connection to be available only to the currently logged-on

user, click My use only.

9. Click Finish to save the connection.

Troubleshooting of Routing & RemoteAccess Services

Problem 1

I recieved error 800,which says the VPN server is unreachable

Cause: PPTP/L2TP packets from the vpn client cannot reach the VPN server

Solution:

>> Assuming ping is allowed (that is, not blocked) between the VPN client and the

VPN server, ping the VPN server. Confirm that you have network connectivity and

that packet filters configured on the VPN server are not preventing

communication.

>> By default, when you configure the Routing and Remote Access service for the

VPN server role, only PPTP and L2TP/IPsec packets are allowed on the Internet

interface of the VPN server. Internet Control Message Protocol (ICMP) packets

used by the ping command are filtered out. To enable ping on the VPN server add

an input filter and an output filter that allow ICMP traffic

>> To allow PPTP traffic, configure the network firewall to open TCP port 1723

and to forward IP protocol 47 for Generic Routing Encapsulation (GRE) traffic to

the VPN server. Some firewalls refer to IP protocol 47 as VPN or PPTP pass-

through. Not all firewalls support IP protocol 47. You might need to upgrade the

firmware


19/38

Page 19

>> To allow L2TP traffic, configure the network firewall to open UDP port 1701

and to allow Internet Protocol security (IPsec) ESP formatted packets (IP protocol

50).

>> Check that the VPN server is listening for PPTP traffic on TCP port 1723 and islistening for L2TP traffic on UDP port 1701.

On the VPN server, from the command line, type:

netstat -aon

you should see the following

TCP 0.0.0.0:1723 0.0.0.0:0 LISTENING

UDP 0.0.0.0:1701 *:*

>> You can use the Portqry command-line tool to determine if PPTP and L2TP

packets are being dropped between the VPN client and VPN server. For more

information, see Description of the Portqry.exe command-line utility

To query the PPTP port, use the following command:

portqry.exe -n -e 1723

To query the L2TP port, use the following command:

portqry.exe -n -e 1701 -p UDP

If the query output includes "NOT LISTENING/FILTERED," check the port

configuration on the server running Routing and Remote Access.


20/38

Page 20

Problem 2

I recieved error 721,which says the remote computer is not responding

Cause : This issue can occur if the network firewall does not permit GRE traffic (IP

protocol 47).

PPTP uses GRE for tunneled data.

solution :

>> Configure the network firewall between the VPN client and the server to

permit GRE. In addition, make sure that the network firewall permits TCP traffic

on port 1723. Both of these conditions must be met to establish VPN connectivity

by using PPTP. For more information, see article 888201, "You receive an "Error

721" error message when you try to establish a VPN connection through your

Windows Server-based remote access server"

Note:

The firewall might be on or in front of the VPN client or in front of the VPN server


21/38

Page 21

Problem 3

I recieved error 741/742,which says there is an encryption mismatch error.

Cause : These errors occurs if the vpn client requests an invalid encryption level or

if the VPN server does not support an encryption type requested by the clients

Solution :

>> Check the properties (Security tab) of the VPN connection on the VPN client. If

Require data encryption (disconnect if none)is selected, clear the selection and

retry the connection.

>> If you are using Network Policy Server (NPS), check the encryption level in the

network policy in the NPS console or policies on other RADIUS servers. Ensure

that the encryption level requested by the VPN client is selected on the VPN

server.

Problem 4

Connection attempt is accepted when it shuold be rejected

Solution :

>> Verify that the network access permission on the user account is set to either

Deny access or Control access through NPS Network Policy. If set to the latter,

>> verify that the first matching network policy's network access permission is set

to Deny Access. Deny access if the connection request matches this policy To

obtain the name of the network policy that accepted the connection attempt,


22/38

Page 22

scan the accounting log for the entry corresponding to the connection attempt for

the policy name.

>> If you have created a network policy to explicitly reject all connections, verify

the policy conditions, network access permission, and profile settings.

Problem 5

I am unable to establish a remote access VPN connection

>> Using the ping command, verify that the host name is being resolved to its

correct IP address. The ping itself might not be successful due to packet filtering

that is preventing the delivery of ICMP messages to and from the VPN server.

>> Verify that the credentials of the VPN client, which consist of user name,

password, and domain name,are correct and can be validated by the VPN server.

>> Verify that the user account of the VPN client is not locked out, expired,

disabled, or that the time the connection is being made does not correspond to

the configured logon hours. If the password on the account has expired, verify

that the remote access VPN client is using MS-CHAP v2. MS-CHAP v2 is the only

authentication protocol provided with Windows Server2008 that allows you to

change an expired password during the connection process.

For an administrator-level account whose password has expired, reset the

password using another administrator-level account.

>> Verify that the user account has not been locked out due to remote access

account lockout.

>> Verify that the Routing and Remote Access service is running on the VPN

server.

>> Verify that the VPN server is enabled for remote access from the General tab

on the properties of a VPN server in the Routing and Remote Access snap-in.


23/38

Page 23

>> Verify that the WAN Miniport (PPTP) and WAN Miniport (L2TP) devices are

enabled for inbound remote access from the properties of the Ports object in the

Routing and Remote Access snap-in.

>> Verify that the VPN client, the VPN server, and the network policycorresponding to VPN connections are configured to use at least one common

authentication method.

>> Verify that the VPN client and the network policy corresponding to VPN

connections are configured to use at least one common encryption strength.

>> Verify that the parameters of the connection have permission through network

policies.

In order for the connection to be accepted, the parameters of the connection

attempt must:

-Match all of the conditions of at least one network policy.

-Be granted network access permission through the user account (set to

Allow access), or if the user account has the Control access through NPS Network

Policy option selected, the network access permission of the matching network

policy must have the Grant network access permission option selected.

-Match all the settings of the profile.

-Match all the settings of the dial-in properties of the user account.

To obtain the name of the network policy that rejected the connection attempt,

scan the accounting log for the entry corresponding to the connection attempt for

the policy name. If NPS is being used as a RADIUS server, check the System event

log for an entry for the connection attempt

>> If you are logged on using an account with domain administrator permissions

when you run the Routing and Remote Access Server Setup Wizard, it

automatically adds the computer account of the RAS and IAS Servers domain-local

security group. This group membership allows the VPN server computer to access

user account information.


24/38

Page 24

If the VPN server is unable to access user account information, verify that:

>> The computer account of the VPN server computer is a member of the RAS and

IAS Servers security group for all the domains that contain user accounts for

which the VPN server is authenticating remote access. You can use the netsh ras

show registeredserver command at the command prompt to view the current

registration. You can use the netsh ras add registeredserver command to register

the server in a domain in which the VPN server is a member or other domains.

Alternatively, you or your domain administrator can add the computer account of

the VPN server computer to the RAS and IAS Servers security group of all the

domains that contain user accounts for which the VPN server is authenticating

remote access.

>> If you add or remove the VPN server computer to the RAS and IAS Servers

security group, the change does not take effect immediately (due to the way in

which Windows Server2008 caches Active Directory information).

For the change to take effect immediately, you must restart the VPN server

computer.

>> For a VPN server that is a member server in a mixed-mode or native-mode

Active Directory174; domain that is configured for Windows authentication, verify

that:

>> The RAS and IAS Servers security group exists. If not, then create the group and

set the group type to Security and the group scope to Domain local

>> The RAS and IAS Servers security group has Read permission to the RAS and IAS

Servers Access Check object.

>> Verify that IP is enabled for remote access on the VPN server.

>> Verify that all of the PPTP or L2TP ports on the VPN server are not already

being used. If necessary, change the number of PPTP to L2TP ports from the


25/38

Page 25

properties of the Ports object in the Routing and Remote Access snap-in to allow

more concurrent connections.

>> Verify that the VPN server supports the tunneling protocol of the VPN client

By default, Windows2000 remote access VPN clients have the Automatic server

type option selected, which means that they try to establish an L2TP/IPsec-based

VPN connection first, then they try a PPTP-based VPN connection. If either the

Point to Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP)

server type option is selected,

verify that the selected tunneling protocol is supported by the VPN server.

By default, Windows XP remote access VPN clients have the Automatic VPN type

option selected, which means that they try to establish a PPTP -based VPN

connection first, and then they try an L2TP/IPsec-based VPN connection. If either

the PPTP VPN or L2TP IPsec VPN type is selected, verify that the VPN server

supports the selected tunneling protocol.

Depending on your selections when running the Routing and Remote Access

Server Setup Wizard, a Windows Server2008 computer running the Routing and

Remote Access service is a PPTP and L2TP server with five or 128 L2TP ports and

five or 128 PPTP ports. To create a PPTP-only server, set the number of L2TP ports

to zero. To create an L2TP-only server, set the number of PPTP ports to 1 and

disable remote access inbound connections and demand-dial connections for the

WAN Miniport (PPTP) device from the properties of the Ports object in the

Routing and Remote Access snap-in.

>> For L2TP/IPsec connections, verify that computer certificates, also known as

machine certificates, are installed on the VPN client and the VPN server.

>> If the VPN server is configured with static IP address pools, verify that there

are enough addresses. If all of the addresses in the static pools have been

allocated to connected VPN clients,the VPN server is unable to allocate an IP

address for TCP/IP-based connections, and the connection attempt is rejected.


26/38

Page 26

>> Verify the configuration of the authentication provider. The VPN server can be

configured to use either Windows or RADIUS to authenticate the credentials of

the VPN client.

>> For RADIUS authentication, verify that the VPN server computer cancommunicate with the RADIUS server.

Problem 6

L2TP/IPsec authentication issues

The following are the most common reasons that L2TP/IPsec connections fail :

- No Certificate

By default, L2TP/IPsec connections require that the remote access server

and remote access client exchange computer certificates for IPsec peer

authentication. Check the Local Computer certificate stores of both the remote

access client and remote access server using the Certificates snap-in to ensure

that a suitable certificate exists.

- Incorrect Certificate :

If certificates exist, they must be verifiable. Unlike manually configuring

IPsec rules, the list of certification authorities (CAs) for L2TP/IPsec connections

cannot be configured. Instead, each computer in the L2TP connection sends a list

of root CAs to its IPsec peer from which it accepts a certificate for authentication.

The root CAs in this list correspond to the root CAs that issued computer

certificates to the computer. For example, if Computer A was issued computer

certificates by root CAs CertAuth1 and CertAuth2, it notifies its IPsec peer during

main mode negotiation that it will accept certificates for authentication from only

CertAuth1 and CertAuth2. If the IPsec peer, Computer B, does not have a valid

computer certificate issued from either CertAuth1 or CertAuth2, IPsec security

negotiation fails.


27/38

Page 27

The VPN client must have a valid computer certificate installed that was issued by

a CA that follows a valid certificate chain from the issuing CA up to a root CA that

the VPN server trusts. Additionally, the VPN server must have a valid computer

certificate installed that was issued by a CA that follows a valid certificate chainfrom the issuing CA up to a root CA that the VPN client trusts.

By default, L2TP/IPsec connections require that the remote access server and

remote access client exchange computer certificates for IPsec peer

authentication. Check the Local Computer certificate stores of both the remote

access client and remote access server using the Certificates snap-in to ensure

that a suitable certificate exists.

>> A NAT between the remote access client and remote access server

If there is a NAT between a Windows 2000, Windows Server 2003, or

Windows XP-based L2TP/IPsec client and a Windows Server2008 L2TP/IPsec

server, you cannot establish an L2TP/IPsec connection unless both the client and

server support IPsec NAT-T.

>> A firewall between the remote access client and remote access server

If there is a firewall between a Windows L2TP/IPsec client and a WindowsServer 2008 L2TP/IPsec server and you cannot establish an L2TP/IPsec

connection, verify that the firewall allows L2TP/IPsec traffic to be forwarded.


28/38

Page 28

Problem 7

EAP - TLS authentication issues

When EAP-TLS is used for authentication, the VPN client submits a user certificate

and the authenticating server (the VPN server or the RADIUS server) submits a

computer certificate.

In order for the authenticating server to validate the certificate of the VPN client,

the following must be true for each certificate in the certificate chain sent by the

VPN client:

>> The current date must be within the validity dates of the certificate.

When certificates are issued, they are issued with a range of valid dates, before

which they cannot be used and after which they are considered expired.

>> The certificate has not been revoked.

Issued certificates can be revoked at any time. Each issuing CA maintains a list of

certificates that should no longer be considered valid by publishing an up-to-date

certificaterevocation list (CRL). By default, the authenticating server checks all thecertificates in the certificate chain of the VPN clients (the series of certificates

from the VPN client certificate to the root CA) for revocation. If any of the

certificates in the chain have been revoked,certificate validation fails. This

behavior can be modified with registry settings described later in this topic.


29/38

Page 29

To view the CRL distribution points for a certificate in the Certificates snap-in,

obtain the certificate properties, click the Details tab, and then click the CRL

Distribution Points field.

The certificate revocation validation only works as well as the CRL publishing and

distribution system. If the CRL in a certificate is not updated often, a certificate

that has been revoked can still be used and considered valid because the

published CRL that the authenticating server is checking is out of date.

>> The certificate has a valid digital signature.

CAs digitally sign certificates they issue. The authenticating server verifies

the digital signature of each certificate in the chain, with the exception of the root

CA certificate, by obtaining the public key from the certificates' issuing CA and

mathematically validating the digital signature.

The VPN client certificate must also have the Client Authentication certificate

purpose (also known as Enhanced Key Usage [EKU]) (Object identifier

1.3.6.1.5.5.7.3.2) and must either contain a UPN of a valid user account or FQDN

of valid computer account for the Subject Alternative Name property of the

certificate.

To view the EKU for a certificate in the Certificates snap-in, double-click the

certificate, click the Details tab, and then click the Enhanced Key Usage field. To

view the subject alternative name property for a certificate in the Certificates

snap-in, double-click the certificate, click the Details tab, and then click the

Subject Alternative Name field.

Finally, to trust the certificate chain offered by the VPN client, the authenticating

server must have the root CA certificate of the issuing CA of the VPN client

Certificate installed in its Trusted Root Certification Authorities store.


30/38

Page 30

Additionally, the authenticating server verifies that the identity sent in the EAP-

Response/Identity message is the same as the name in the Subject Alternative

Name property of the certificate.

This prevents a malicious user from masquerading as a different user from theone specified in the EAP-Response/Identity message.

In order for the VPN client to validate the certificate of the authenticating server

for either EAP-TLS authentication, the following must be true for each certificate

in the certificate chain sent by the authenticating server:

>> The current date must be within the validity dates of the certificate.

When certificates are issued, they are issued with a range of valid dates, before

which they cannot be used and after which they are considered expired.

>> The certificate has a valid digital signature.

CAs digitally sign certificates they issue. The VPN client verifies the digital

signature of each certificate in the chain, with the exception of the root CA

certificate, by obtaining the public key from the certificates' issuing CA and

mathematically validating the digital signature.

Additionally, the authenticating server computer certificate must have the Server

Authentication EKU (Object identifier 1.3.6.1.5.5.7.3.1). To view the EKU for a

certificate in the Certificates snap-in, double-click the certificate, click the Details

tab, and then click the Enhanced Key Usage field.

Finally, to trust the certificate chain offered by the authenticating server, the VPN

client must have the root CA certificate of the issuing CA of the authenticating

server certificate installed in its Trusted Root Certification Authorities store.

Notice that the VPN client does not perform certificate revocation checking for

the certificates in the certificate chain of the authenticating server's computer

certificate. The assumption is that the VPN client does not yet have a connection


31/38

Page 31

to the network, and therefore cannot access a Web page or other resource to

check for certificate revocation.

Problem 8

VPN clients are unable to access resources bevond the VPN server

Solution :

>> Verify that either the protocol is enabled for routing or that dial-in clients are

allowed to access the entire network for LAN protocols being used by the VPN

clients

>> Verify the IP address pools of the VPN server.

If the VPN server is configured to use a static IP address pool, verify that the

routes to the range of addresses defined by the static IP address pools can bereached by the hosts and routers of the intranet. If not, then an IP route onsisting

of the VPN server static IP address pools, as defined by the IP address and mask

ofthe range, must be added to the routers of the intranet or enable the routing

protocol of your routed infrastructure on the VPN server. If the routes to the

remote access VPN client subnets are not present, remote access VPN clients

cannot receive traffic from locations on the intranet. Routes for the subnets are

implemented either through static routing entries or through a routing protocol,

such as Routing Information Protocol (RIP).

If the VPN server is configured to use DHCP for IP address allocation and no DHCP

server is available, the VPN server assigns addresses from the Automatic Private

IP Addressing (APIPA) address range from 169.254.0.1 through 169.254.255.254.


32/38

Page 32

Allocating APIPA addresses for remote access clients works only if the network to

which the VPN server is attached is also using APIPA addresses.

If the VPN server is using APIPA addresses when a DHCP server is available, verify

that the proper adapter is selected from which to obtain DHCP-allocated IPaddresses. The Routing and Remote Access Server Setup Wizard assigns the efault

adapter automatically. You can manually choose a LAN adapter from the Adapter

list on the IP tab on the properties of a VPN server in the Routing and Remote

Access snap-in.

If the static IP address pools are a range of IP addresses that are a subset of the

range of IP addresses for the network to which the VPN server is attached,verify

that the range of IP addresses in the static IP address pool are not assigned to

other TCP/IP nodes, either through static configuration or through DHCP.

>> Verify that packet filtering on a router interface between the VPN client and

the VPN server is not preventing the forwarding of tunneling protocol traffic.

Problem 9

Unable to establish tunnel

Solution :

>> Verify that packet filtering on a router interface between the VPN client and

the VPN server is not preventing the forwarding of tunneling protocol traffic.

On a VPN server running Windows Server2008, IP packet filtering can be

separately configured from the advanced TCP/IP properties and from the Routing

and Remote Access snap-in. Check both places for filters that might be excluding

VPN connection traffic.

>> Verify that the Winsock Proxy client is not currently running on the VPN client.


33/38

Page 33

When the Winsock Proxy client is active, Winsock API calls, such as those used to

create tunnels and send tunneled data, are intercepted and forwarded to a

configured proxy server.

A proxy server-based computer allows an organization to access specific types ofInternet resources (typically, Web and FTP) without directly connecting that

organization to the Internet. The organization can instead use private IP network

IDs (such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16).

Proxy servers are typically used so that private users in an organization can have

access to public Internet resources as if they were directly attached to the

Internet. VPN connections are typically used so that authorized public Internet

users can gain access to private organization resources as if they were directly

attached to the private network. A single computer can act as a proxy server (for

private users) and a VPN server (for authorized Internet users) to facilitate both

exchanges of information.


34/38

Page 34

Common Routing Errors

When I set about trying to determine the five most common routing errors, Ididn't realize what a challenge it would be to narrow them down. I considered

writing about the five most annoying routing errors, but quickly realized all five

would revolve around ISDN dial, and no one would want to read that. So I

eventually decided to eliminate all the host-based routing problems and focus on

errors that involve routing protocols and that, while not necessarily the MOST

common, are fairly common and easily avoided or resolved.

As you probably know, one of the joys of consulting or doing project work as anetwork reseller, is discovering these little routing errors in customer networks

during an install or change window. It's fairly common to find situations where a

previous administrator committed one of these errors and was unable to resolve

it, so they "fixed" it by adding static routes or changing the administrative

distance of a protocol.

This turns the network into a minefield in which routes aren't propagated as

anticipated when you make your changes, so you have to find and remove the

"fix," then find and resolve the actual problem. You have to be extremely careful

in this situation though, because your "fix" can send a flood of new routes into

the network, changing traffic patterns that may not be transparent to the users.

Another gotcha to be thinking about when troubleshooting routing errors is how

it changes your customer's expectation of the project's scope. If you have to fix a

lot of errors, it could take a lot more time than anyone expected. You also need to

make sure you have the ability to change lots of routers. For instance, if you're

only supposed to be working on one router, and the problem needs to be

corrected on another router, do you have access? Are you allowed to change it? If

not, do you have the contact information for someone who can? How can you

document the change? And let's not forget... are you being paid to change it?

With that in mind, let's move on to the errors...


35/38

Page 35

Error #1: Filtering redistribution

When redistributing routing you need to filter the routes properly to avoid

routing loops and route feedback. Not applying filters at all is usually a significant

problem, but managing the filters in a complex and poorly summarized network issuch an administrative burden that missing a route here or there is extremely

common. The best way to avoid this, of course, is to not do redistribution at all. In

fact, redistribution is almost always a bad decision. Friends don't let friends do

mutual redistribution.

Error #2: Mismatched neighbor parameters in OSPF

In order to form an adjacency, OSPF routers need to have quite a few parameters

in common. These include authentication, area ID, mask, hello interval, router

dead interval, etc. Quite often, due to fat fingers, non-standard configurations or

invalid passwords, deviant parameters will prevent adjacencies from forming.

While it's hard to avoid typos, it's fairly easy to use the debug command for OSPF

adjacencies, which will quickly let you know if mismatched parameters are a

problem. Once you know that, it's trivial to correct the configuration.

Error #3: 'subnets'

It's fairly common, when redistributing routes into OSPF, to find several missing.

Most commonly, the culprit is that someone forgot to tack the 'subnets ' keyword

to the end of the redistribute command. Cisco says, "The subnets keyword tells

OSPF to redistribute all subnet routes. Without the subnets keyword, only

networks that are not subnetted will be redistributed by OSPF." They should

know.

Error #4: Metrics

If you're redistributing routes into EIGRP and find they're all missing, the problem

is almost always that someone forgot to set the metrics. Oddly enough, Cisco

declined the opportunity to set a default metric for EIGRP routes. Instead, they

leave that up to the administrator. (Never mind the fact that it's not really a

'default' if you have to set it.) Thus, if you don't set it, routes will not be


36/38

Page 36

redistributed. I suspect this is penance for making the decision to use EIGRP and

do route redistribution at the same time.

To solve this problem, you need to either set a default metric with the deceptively

named 'default-metric bandwidth delay reliability loading mtu' command -- andyes, you need to specify ALL of those -- or you can set the same parameters with

the 'metric' keyword as part of the redistribute command.

Error #5: Tweaking EIGRP metrics

Speaking of EIGRP metrics, it's often hard for administrators to resist tweaking

them in order to cause traffic to prefer one circuit over another. In my

experience, this is almost always an attempt to send traffic over an Internet VPN

instead of a low-bandwidth frame-relay circuit . The bandwidth and delay

parameters just seem so simple to apply, but the problems come over time after

all these tweaks add up to a little nightmare as administrators try to find all the

metrics they've set and stuff them into the not-so-simple formula for the

composite metric to determine how to get traffic to flow over the right circuit

again.

My advice for avoiding unpredictable traffic flows is simple: if you're thinking

about tweaking the EIGRP metrics, have a friend page you at 3 a.m. and give youthe parameters to three paths through your network. Calculate the correct cost of

each path and then predict which will be preferred. If you get it right, and you

enjoyed the exercise, then go ahead and make your changes.


37/38

Page 37

About Us

Name : Gondaliya Yogesh D.

Add. : 67 No. Devbhumi Society,

Hirawadi Road, Mahavir Nagar,

Ahmadabad.

Gender : Male

Contact No: 9825753888

9033444940

Email Id : [email protected]

[email protected]

Hobbies : Reading, Traveling

Qualification :

Name Board/University Year Result

H.S.C GSEB 2006/7 First Class

BCA Suarashtra

University

2009/10 First Class
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


38/38

Bibliography

While developing this project I am refried the following books and Websites for

guidance :

1) Wndows Server 2008 Administration by Jetking institute2) Windows Server Operating SystemWebsite

1) www.microsoft.com2) www.worldnetwork.com3) www.google.com
http://www.microsoft.com/http://www.microsoft.com/http://www.worldnetwork.com/http://www.worldnetwork.com/http://www.worldnetwork.com/http://www.microsoft.com/

Project Report on 2K8

Documents

Transcript of Project Report on 2K8