You are on page 1of 38

2011

Routing & Remote Access Services


Jetking Institute of Computer Hardware & Networking

1/9/2011

Project Report
Prepared By :-

Gondaliya Yogesh D.

Guidance by:-

Mr. Suresh Suthar Sir

At
Jetking Institute of Computer Hardware & Networking

Ashram road Ahmadabad

Page 2

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
Page 3

Examiner

INDEX
No. 1 2 3 4 5 6 7 8 9 10 11 Name Certificate Introduction of Routing & Remote Access Services Required Component to use RAS Protocol Remote Access Routing Installing the RRAS Troubleshooting of RRAS Common Routing Errors About Us Biblography 3 5 6 7 11 13 14 18 34 37 38 Page No.

Page 4

Introduction of Routing & Remote Access 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 connectivity for your network clients. This includes remote access for clients, either using Dialup 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 operating system 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.
Page 5


* Networking

Required components to use RAS

Required components to use RAS on Clients

* 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.

Page 6

Protocols

Connection 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 bidirectional 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 such as 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. SLIP will 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.

Page 7

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.

Page 8

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/IP properties 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.

Page 9

* 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.

Page 10

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:

Page 11

* 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.

Page 12

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.

Page 13

Installing the Routing & Remote Access Services


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 or connect 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.

Page 14

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.

Page 15

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.

Page 16

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.

Page 17

* 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 & Remote Access 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 passthrough. Not all firewalls support IP protocol 47. You might need to upgrade the firmware

Page 18

>> 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 is listening for L2TP traffic on UDP port 1701. On the VPN server, from the command line, type: netstat -aon you should see the following TCP UDP 0.0.0.0:1723 0.0.0.0:0 0.0.0.0:1701 *:* LISTENING

>> 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 <server_ip_address> -e 1723 To query the L2TP port, use the following command: portqry.exe -n <server_ip_address> -e 1701 -p UDP

If the query output includes "NOT LISTENING/FILTERED," check the port configuration on the server running Routing and Remote Access.

Page 19

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

Page 20

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,

Page 21

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.

Page 22

>> 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 policy corresponding 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.
Page 23

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

Page 24

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.

Page 25

>> 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 can communicate 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.

Page 26

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 chain from 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 Windows Server 2008 L2TP/IPsec server and you cannot establish an L2TP/IPsec connection, verify that the firewall allows L2TP/IPsec traffic to be forwarded.

Page 27

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 the certificates 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.

Page 28

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.

Page 29

Additionally, the authenticating server verifies that the identity sent in the EAPResponse/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 the one 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

Page 30

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 be reached 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.

Page 31

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 IP addresses. 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 Server&#160;2008, 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.

Page 32

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 of Internet 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.

Page 33

Common Routing Errors

When I set about trying to determine the five most common routing errors, I didn'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 a network 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...

Page 34

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 is such 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

Page 35

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 -- and yes, 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 you the 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.

Page 36

About Us
Name : Add. : Gondaliya Yogesh D. 67 No. Devbhumi Society, Hirawadi Road, Mahavir Nagar, Ahmadabad. Gender : Male

Contact No: 9825753888 9033444940 Email Id : yogeshmuskan139@gmail.com yogeshmuskan139@yahoo.in Hobbies : Reading, Traveling

Qualification :

Name H.S.C BCA

Board/University GSEB Suarashtra University

Year 2006/7 2009/10

Result First Class First Class

Page 37

Bibliography

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

1) Wndows Server 2008 Administration by Jetking institute 2) Windows Server Operating System Website 1) www.microsoft.com 2) www.worldnetwork.com 3) www.google.com

Page 38

You might also like