configuring isa server phần 9 pdf

NetMeeting clients on the internal network should be configured to use the internal interface of the ISA server as their gatekeeper.. Even users who are directly connected to the Interne

compatriots versed in VoIP and related technologies

You can still call external machines on the Internet if you know the IP address of that computer If the machine does not have a static IP address, but uses a dynamic DNS registration method such as TZO, you can dial up external hosts directly connected to the Internet through an FQDN

One of the biggest differences between using NetMeeting from behind the ISA server H.323 gateway and how you might have used it in the past with a plain NAT

solution is that you can no longer register with ILS servers on the Internet (including the external interface of the ISA server) and have full functionality The reason is that when your internal host registers with an ILS server, its internal private IP address is

registered, rather than the public IP address of the NAT server This is the case even when the ILS server is located on the ISA server itself

The result is that you can no longer use NetMeeting to call users on Internet ILS servers If you require this feature, do not enable the H.323 gatekeeper

NetMeeting clients on the internal network should be configured to use the internal interface of the ISA server as their gatekeeper When the NetMeeting clients are

configured to use the gatekeeper, user information is stored in the registration database, and you can see information about the registered clients in the ISA Management console These clients dynamically register user information with the gatekeeper, and the

registrations are removed automatically when the client is shut down

To configure the NetMeeting client to use the gatekeeper, perform the following steps:

1 Open NetMeeting Click on the Tools menu, and then click Options You will

see something like Figure 10.50

Figure 10.50 The NetMeeting Option Dialog Box

2 In the Options dialog box, click Advanced Calling You will see what

appears in Figure 10.51

Figure 10.51 The Advanced Calling Options Dialog Box

In the Advanced Calling Options dialog box, you have the following

options:

· Use a gatekeeper to place calls Since we want to use the ISA server’s

H.323 gatekeeper to place calls, you need to enter the computer name or the IP address of the internal interface on which the H.323 gatekeeper listens If you use a computer name, make sure you have the DNS

infrastructure that can resolve the name

· Log on using my account name Select this option if you would like to

register an email address or username with the gatekeeper Users on networks behind an H.323 gatekeeper will be able to call other networks behind an H.323 gatekeeper by using an email address Note that you

cannot use an email address to call a NetMeeting host if both the hosts

are not behind a gatekeeper For example, if a user running NetMeeting

on his personal computer wants to call you by the email address you registered with the gatekeeper, it will not work, because the external NetMeeting user is not behind a gatekeeper

· Log on using my phone number Type in a telephone number you want

to have registered with the gatekeeper This number should contain only numbers, and should not contain letters, dashes, spaces, or anything

other than numbers External users can call you by using the telephone number you register with the gatekeeper Even users who are directly connected to the Internet and are not behind an H.323 gatekeeper can call you using your telephone number if they configure their NetMeeting

to use the external interface of the ISA server as their gateway

3 Click OK, and then click OK again You’ll see a little icon in the lower-right

corner of the NetMeeting application that looks like two terminals If you let your mouse pointer rest over it, it should say “logged onto gatekeeper.”

4 Go to the ISA Management console Assuming that you’ve installed the

optional H.323 Gatekeeper Service, expand the H.323 Gatekeepers node in the left pane, expand your server name, and click on the Active Terminals

node You should see something like what appears in Figure 10.52

Note that both the account name and the telephone number of the

NetMeeting client is registered with the gatekeeper Note that the Type column states that the registration is dynamic When the NetMeeting client is closed, the registration will be dynamically removed from the list

Figure 10.52 The Active Terminals Node

Gatekeeper-to-Gatekeeper Calling

As mentioned earlier, the H.323 Gatekeeper Service was designed to optimize the

benefits of LAN-to-LAN calls When each LAN has a gatekeeper and NetMeeting clients registered with their respective gatekeepers, users can call NetMeeting clients on other networks by using either an email address or a telephone number

Calling by email address is actually the easiest way to do this, because you do not need to set up any routing rules on the ISA server to support calling by email address—allthat is required is a Q931 resource record entry for your domain The DNS entry needs to

be on a publicly available DNS server The type of entry is an SRV record called the Q931 address record

To configure the Q931 address record for your domain on a Windows 2000 DNS server, perform the following steps:

1 Open the DNS console, and right-click on your domain Click Other New

3 In the New Resource Record dialog box, type in the entries as they appear in Figure 10.54

Figure 10.54 The New Resource Record Dialog Box

The entries you should configure are:

Service = _q931

Protocol = _tcp

Port number = 1720

Host offering this service: [the name of your ISA server’s external interface]

Click OK to create the record

After each network using the H.323 gatekeeper has registered its Q931 address in the DNS, all a user on the internal network needs to do is call the other user by his email address Note that unlike the ILS server method, there is no way for the caller to search the registrations on the gatekeeper The caller must know the address of the person he orshe wants to call, and it is the sole responsibility of each user to configure NetMeeting with the correct information so that it is properly entered into the registration database

Hosts on networks behind gatekeepers can also call hosts on other networks

behind gatekeepers using a telephone number However, routing rules must be in place

to support these types of calls, since there is no centralized database such as DNS or ILS

to support locating hosts using telephone numbers However, routing rules can be

configured using prefixes for other networks that will direct the call to the appropriate remote gateway We will discuss routing rules later in this section

ILS Servers

NetMeeting clients can be configured to use ILS servers on the internal network, and call other internal NetMeeting clients registered with the ILS server However, a NetMeeting client cannot register with both an ILS server and an H.323 gatekeeper Registering with

an ILS server is not a recommended configuration, because external users will never be able to call users on the private network through an ILS server

However, external clients can register with an internal ILS server Internal clients can then call external users through ILS The gatekeeper will manage conversations between the internal client and the external client External users can dynamically

register with the ILS

NetMeeting Clients on the Internet

Internal machines can call external NetMeeting clients that are directly connected to the Internet The internal client must have permissions to use the H.323 protocol There is a protocol definition for H.323 that you can use in protocol rules to allow access to Internet clients This protocol definition is installed by the H.323 filter If you disable the H.323 filter, the protocol definition will be unavailable Both SecureNAT and firewall clients have access to this protocol, and you can implement user/group-based access controls for the protocol if you are using firewall client machines

NetMeeting clients on the internal network cannot call an external NetMeeting client that is directly connected to the Internet by calling a telephone number or email address Calling by telephone number or email address is only available when the

destination NetMeeting client is behind an H.323 gatekeeper

External NetMeeting clients directly connected to the Internet can have static

registrations for them entered into the registration database However, the client must have a static IP address, because static entries do not support using FQDNs for entering the Q931 IP address information If you do create a static entry, you can use a telephone number to call the external NetMeeting client One way around this problem is to create a routing rule that directs calls to the address for the static user to the registration

database

External NetMeeting clients directly connected to the Internet can call internal NetMeeting clients that are behind the H.323 gatekeeper The external client must be configured to use the ISA server’s external interface as its gateway to the internal

network that it wants to call

Perform the following steps to configure the external NetMeeting client to use the external interface of the ISA server as its gateway:

1 Open NetMeeting Click on the Tools menu, and then click Options You will

see something like Figure 10.55

Figure 10.55 The NetMeeting Option Dialog Box

2 In the Options dialog box, click Advanced Calling You will see what appears

in Figure 10.56

Figure 10.56 The Advanced Calling Options Dialog Box

Place a check mark in the check box for Use a gateway to call telephones and videoconferencing systems, and type in the IP address or the FQDN

that resolves to the external interface of the ISA server

3 Click OK, and then click OK again The NetMeeting client can now call an

internal user behind the gatekeeper by using the internal user’s telephone number.

A common misconception we’ve heard is that its possible for an external client on the Internet to dynamically register with the gatekeeper Sometimes it appears that the client actually does register with the gatekeeper, but the

connection is quickly lost or simply does not work It is not possible for the external NetMeeting client on the Internet to dynamically register with the gatekeeper, so don’t even try it

Configuring the Gatekeeper

There are just a few basic steps to configure the gatekeeper:

· Creating destinations

· Creating phone number rules

· Creating email rules

· Creating IP address rules

Destinations are used in the routing rules After the destination is created, it is used in the routing rule so that the ISA server knows where to send the request

Creating Destinations

To create a new destination, perform the following steps:

1 Open the ISA Management console, expand your server or array, and then expand the H.323 Gatekeepers node Expand your server, and finally expand the Call routing node Right-click on the Destinations node, and click Add destination

2 The New Destination Wizard appears Click Next to continue

3 The Destination Type page appears, as seen in Figure 10.57

Figure 10.57 The Destination Type Page

From the Destination Type page, you can create one of the following

destination types:

· Gateway or proxy server This is the address of an H.323 gateway If you

wish to call NetMeeting clients on other networks, you can configure a gateway for the ISA server to route the request You would use this gateway

destination in a routing rule so that the ISA server knows where to send requests for an email address, telephone number or IP address

· Internet Locator Service (ILS) Create an ILS destination if you want to

route calls to an internal ILS server Do not configure an ILS destination for ILS servers on the Internet

· Gatekeeper While a single gatekeeper can handle up to 50,000

registrations, larger environments may wish to partition their internal client registration database If you do so, you should configure a gatekeeper destination that can be used in rules to search for clients registered with those gatekeepers For example, you might have all clients with the prefix

999 register with one gatekeeper, and have all clients with the prefix 888 register with another gatekeeper Then you can create routing rules so that calls with a particular prefix are routed to the appropriate gatekeeper

· Multicast group All gatekeepers listen on the multicast address 224.0.1.41

If you have a large network and do not want to configure routing rules for multiple gatekeepers, you can configure a multicast destination to search all gatekeepers on the LAN

Select a Destination, and click Next

4 The Destination Name or Address page appears as shown in Figure 10.58 Figure 10.58 The Destination Name or Address Page

In the Destination name or address, type in the FQDN or IP address associated with the destination you are configuring Click Next

5 On the Destination Description page, type in a short description for the destination, and then click Next

6 The last page lists your selections If it looks good, click Finish

One you have created your destination, you can then create routing rules and use the destination in the rule

Call Routing Rules

There are three types of call routing rules:

· Phone number rules

· Email address rules

· IP address rules

Let’s look at each type and how they are configured

Phone Number Rules

Phone number rules can be used to route requests based on telephone number strings These are helpful if you plan to implement multiple H.323 gatekeepers in your

organization, and partition client registrations based on prefixes For example, all

machines with prefix 999 would register with one H.323 gatekeeper, and all machines with prefix 888 would register with another H.323 gatekeeper If all numbers in your company use the same prefix, you can configure a routing rule that will direct the request

to a local registration database

Phone number rules can also be implemented if you plan to call other

organizations For example, another organization could use a prefix of 972 for all its clients In this case, you can create a phone number rule to direct requests with that prefix to the other organization’s gateway You can even configure a routing rule that allows you to configure custom prefixes that will route calls to remote networks, even when the remote network does not use a standardized prefix system in their telephone number scheme

If your company uses an IP-to-PSTN gateway, you can implement a routing rule that forwards all requests destined for a POTS network to a specific gateway device that handles these requests

To create a phone number routing rule, perform the following steps:

1 Open the ISA Management console, expand your server or array, expand the H.323 Gatekeepers node, and expand the Call routing node Right-click on the Phone number rules node, and click Add routing rule

2 The Welcome page for the New Routing Rule Wizard appears Click Next to

continue

3 The Name and Description page appears Type in a name for this rule, and a short description that will let you know what this rule is used for Click Next

4 The Prefix or Phone Number page appears as in Figure 10.59

Figure 10.59 The Prefix or Phone Number Page

On the Prefix or Phone Number page, type in a prefix or entire telephone

number that will trigger this routing rule For example, the prefix 973 might be used by all NetMeeting clients in the south office, which is connected to the Internet by an H.323 gatekeeper You can also enter a single telephone number here, and route requests for that particular number If you choose to enter the

entire telephone number, remove the check mark from the Route all phone numbers using this prefix check box

Click Next to continue

5 The Destination Type page appears as shown in Figure 10.60

Figure 10.60 The Destination Type Page

On the Destination Type page, select the type of destination that the

request for the telephone number or prefix should be directed In this case, we entered a prefix that should route numbers to another division of the company that is behind another H.323 gatekeeper connected to the Internet Therefore,

we will direct these requests to a Gateway or proxy server

Note that only options for phone number rules are available If a particular destination type can’t be used to route a telephone number, it won’t be

available as you can see in Figure 10.60

Click Next to continue

6 The Destination Name page presents you with a list of Destinations that you’ve already created in the Destinations node The only destinations

displayed on this list are those that you configured as gateways or proxies

Select the appropriate destination for the rule, and click Next

7 The Change a Phone Number page appears as in Figure 10.61

Figure 10.61 The Change a Phone Number Page

The Change a Phone Number page allows you to alter the called number

before it is actually sent to its destination The options you have include:

· Discard digits Select this option if you wish to discard digits in the

telephone number before the request is sent to its final destination This is helpful if you want to institute your own routing scheme to connect to other networks that have not implemented their own prefix-oriented numbering system For example, suppose you have two partners that have H.323 gateways Neither partner has implemented a numbering scheme that allowsyou to use the prefix to route properly to his or her gateway In this case, you can tell your employees to use the prefix 111 to dial one company, and

222 to dial another company Then, when one of your employees calls a number such as 2222875252, the gatekeeper will strip off the 222 because

we told it to remove the first three digits After removing the digits, the request for the remaining portion of the number will be routed to the

destination gateway

· Add prefix Choose this option if you wish to add a prefix to numbers This

might be helpful if the destination network users a specific prefix in its number, and you wish to have the gatekeeper add these numbers before sending the request

Click Next to continue

8 The Routing Rule Metric page appears You can enter a metric value that will

be used to determine the most favored route for a particular request Using a metric allows you to order rules and make available multiple paths for a single request, while allowing you to determine the best path

Click Next to continue

9 On the last page of the wizard, click Finish to complete the rule

The rule will appear in the left pane of the ISA Management console Note that there is a default rule called Local, which will route all requests to the local registration database if there is no other number that can specifically route the request If you ever need to make changes to the rule, double-click on it and it will open the rule’s Properties dialog box Email address routing rules are configured in a manner similar to how you created the phone number routing rule Note that if the destination email domain has a Q931 record in a publicly available DNS, you do not need to implement an email routing rule to support connections made by email address

To create an email address routing rule, perform the following steps:

1 Open the ISA Management console, expand your server or array, expand the H.323 Gatekeepers node, and expand the Call routing node Right-click on the Phone number rules node, and click Add routing rule

2 The Welcome page for the New Routing Rule Wizard appears Click Next to

continue

3 The Name and Description page appears Type in a name for this rule, and a short description that will let you know what this rule is used for Click Next

4 The Domain Name Suffix page appears as shown in Figure 10.62

Figure 10.62 Domain Name Suffix

Enter the domain name suffix for the email rule If you wish the rule to route a particular address, remove the check mark from the Route all e-mail

addresses that include this general DNS domain name Click Next

5 The Destination Type page appears as shown in Figure 10.63

Figure 10.63 The Destination Type Page

On the Destination Type page, you can choose from a number of

destination types, some of which we haven’t covered yet The “other”

destination types include:

· None This would be your “black-hole” route

· Registration database Requests for NetMeeting clients already registered

with the H.323 gatekeeper can be sent to the registration database You can see these entries in the Active Terminals list Listings in the registration database have a TTL of six minutes (by default) At the end of the TTL, the gatekeeper will inform the NetMeeting client that its registration is about to

be dropped, and that it should renew it If it is not renewed, the registration

is dropped from the database Note that the database does not enforce

uniqueness If two registrations have the same value, calls will be routed to the most recent registration

· DNS (using the domain part of the address) Use this to specify an

internal DNS server to resolve the domain name in email rules Note that

you do not need to configure a DNS destination for external domains,

because the external interface of the ISA server will attempt to resolve names automatically through its external interface

· Active Directory (using the NTDS User Object ipPhone attribute When

users log on to a Windows 2000 domain and use a TAPI-aware application such as the Windows 2000 Phone Dialer, the FQDN of their machine is

registered in the Users account in the Active Directory You can leverage this feature of the Active Directory by configuring the routing rule to use the Active Directory to search for the user’s location on the internal network

Click Next to continue

6 On the Destination Name page, choose the appropriate Destination, and click Next

7 On the Routing Rule Metric page, configure a metric for this rule, and click

Next

8 On the last page of the wizard, click Finish to complete the rule

IP Address Routing Rules

IP address routing rules work in the same way that the other rules work However, in this case, the caller uses the destination IP address to make the call When an ISA server receives the request to call a particular IP address, it will search though the IP address rules to see if there is a destination to which the request should be routed If one is found, it will forward the request to the appropriate destination

Generally, users will not call each other by IP address, since most internal

networks use DHCP, which makes calling by IP address problematic

To create an IP address routing rule, perform the following steps:

1 Open the ISA Management console, expand your server or array, expand the H.323 Gatekeepers node, and expand the Call routing node Right-click on the Phone number rules node, and click Add routing rule

2 The Welcome page for the New Routing Rule Wizard appears Click Next to

8 On the last page of the wizard, click Finish to complete the rule

Managing the Gatekeeper

There are relatively few housekeeping and setup procedures for the H.323 Gatekeeper Service once it’s installed However, you should be aware of a few options

Right-click on your server name list under the H.323 Gatekeepers, and click Properties You will see the Properties dialog box shown in Figure 10.64

Figure 10.64 The H.323 Server Properties Dialog Box

There are four tabs:

· General

· Network

· Advanced

· Security

The General tab contains information about your version of ISA Server, and

provides a space for you to enter a description of the gatekeeper

The Network tab allows you to select the interfaces you wish the gatekeeper to

use Since external users cannot register with the gatekeeper, you should uncheck any boxes that contain IP addresses for the external interface of the ISA server

The Advanced tab allows you configure expiration times for entries in the

registration database and an active call expiration time The former setting determines how long a NetMeeting client can remain in the registration database before renewing its registration, and the latter determines how long an active call can be idle before being removed from the active calls list

The Security tab allows you to set security on this object

Another housekeeping duty you can perform on the H.323 gatekeeper is to create

static entries in the registration database Right-click on the Active Terminals node in

the left pane, and then click on the Register static user entry You will see the

Welcome page for the Register Static User Wizard Click Next to continue

The Static User Information dialog box appears as shown in Figure 10.65 Figure 10.65 The Static User Information Page

Enter an Account name, a Phone number, and an IP address for the user Note thatyou cannot enter an FQDN for a static entry, so the user must have a static IP address in order to register This type of entry is useful for users who have NetMeeting running and are directly connected to the Internet Your internal users can call the account name or the telephone number When the call is made, the ISA server will forward the call request

to the IP address and port number you enter here Do not change the port number if you

want to call a NetMeeting client Click Next to continue

On the last page of the Wizard, click Finish to create the static registration

NOTE

This discussion on the H.323 Gatekeeper Service was aimed at getting you up and running with the H.323 gatekeeper Once you are comfortable with using the gatekeeper and have configured it by creating destinations and basic routing rules, you might want to check out more information about how the H.323

Gatekeeper Service works The ISA Server Help File contains information on how rules are processed and has definitions for the various address types We strongly recommend that you review this information once you are comfortable with the H.323 gatekeeper Also, look for us to post white papers on this subject and

others in the future

Virtual Private Networking

ISA Server supports virtual private networking by allowing inbound access to the ISA server by VPN clients, and by configuring ISA Server in a gateway-to-gateway

configuration There are wizards built into ISA Server that make the process of

configuring inbound VPN very easy, and they greatly simplify the process of configuring a gate-to-gateway ISA server VPN solution

The Routing and Remote Access Service (RRAS) is required in order to configure the VPN server components on the ISA server This is one instance when you want to have RRAS enabled However, the ISA server VPN wizards take care of the process of enabling and configuring the ISA server to support your VPN configuration There is no need for you to manually configure any component of the VPN through RRAS

Configuring VPN Client Access

If you want to allow external VPN clients to dial in to the ISA server, you can use the VPN Client Wizard to allow inbound access

Perform the following steps to allow inbound access:

1 Open the ISA Management console, expand your server or array, and then right-click on the Network Configuration node in the left pane Click on the Allow VPN client connections command

2 The Welcome page of the ISA Server Virtual Private Network Configuration

Wizard appears Click Next to continue

3 The last page of the Wizard informs you that packet filters have been

configured to support VPN access Click Details, and you’ll see something like

what appears in Figure 10.66

Figure 10.66 The VPN Server Summary Dialog Box

4 The dialog box informs you that the RRAS server will be configured as a VPN server The ports listening for VPN connections will enforce secured

authentication and encryption Static packet filters will be opened on the ISA server to support both PPTP/MPPE and L2TP/IPSec connections, and the number

of ports opened (for each protocol) will be 128 You can change this if you like via the RRAS console

5 Click Back, and click Finish If the RRAS is not enabled, the wizard will enable

and configure it If RRAS has already been enabled, it will restart the service

NOTE

When you configure ISA Server to be a VPN server through the VPN Wizard,

RRAS will not show the change in the number of ports configured The number of ports is configured directly in the Registry However, if you restart the server, the number of ports will show up correctly in the RRAS console

Gateway-to-Gateway VPN Configuration

ISA Server makes it easy to configure a gateway-to-gateway solution using ISA Server at

each end of the VPN Included are Local VPN Server and Remote VPN Server Wizards

You run the Local VPN wizard on a machine that will initiate outbound connections to a

remote machine You can also configure the wizard to allow calls to be initiated at both ends of the VPN connection

For example, say you have a branch office that needs to connect to the main office through a VPN connection You would run the Local VPN wizard at the branch office, and then run the Remote VPN Wizard at the main office

Configuring the Local VPN

To configure the Local VPN connection, perform the following steps:

1 Open the ISA Management console, expand the server or array, and then right-click on the Network Configuration node Click Set up Local ISA

Server VPN Server

2 The Welcome page of the wizard appears Click Next to continue

3 The ISA Virtual Private Network (VPN) Identification page appears, as in

Figure 10.67

Figure 10.67 The ISA Virtual Private Network (VPN) Identification Page

Type in a name to describe the local network, and type in another name to describe the remote network Note that each name must be less than 10

characters Click Next

4 On the ISA Virtual Private Network (VPN) Protocol page, you’ll see what

appears in Figure 10.68

Figure 10.68 The ISA Virtual Private Network (VPN) Protocol Page

On this page, you choose the VPN protocol you want to use:

· Use L2TP over IPSec

· Use PPTP

· Use L2TP over IPSec, if available; otherwise, use PPTP

In this example, we’ll choose the option that lets us use both protocols Then

click Next

5 The Two-way Communication Page appears as in Figure 10.69

Figure 10.69 The Two-way Communication Page

On this page, you can configure the wizard to create a connection that allows call initiation from both the local and the remote VPN servers

Select Both the local and remote ISA VPN computers can initiate communication if you want bidirectional call initiation

In the Type the fully qualified domain name or IP address of the remote VPN computer text box, type in either the FQDN or IP address of the

remote computer This entry is used to locate the remote computer

In the Type the remote VPN computer name or the remote domain name text box, type in the computer name if the machine is a stand-alone or

member server If the destination computer is a domain controller, use the NetBIOS name for the domain Do not enter the FQDN for the remote domain

After entering the information on this page, click Next

6 The Remote Virtual Private Network (VPN) Network page appears as in

Figure 10.70

Figure 10.70 The Remote Virtual Private Network (VPN) Network Page

On this page, enter a range of IP addresses included on the remote network This entry is used to create a static route that can be used to route calls to the remote network through a VPN demand-dial interface Be sure to include all the

network IDs on the remote network Click Add to add more IP address ranges

If you need to remove a range, select the range, and click Remove

After entering in your IP address ranges, click Next

7 The Local Virtual Private Network (VPN) Network page appears as in

Figure 10.71

Figure 10.71 The Local Virtual Private Network (VPN) Network

On this page, you tell the wizard what network IDs or ranges of IP addressesare on the local network This will allow the wizard to configure the remote computer with static routing table entries that will route packets to these IP addresses through a virtual demand-dial interface on the remote computer to the local network Make sure that you enter all the ranges of IP addresses that you want the remote network to access

Note that there is a route for IP address 127.0.0.1 This is included because these entries are drawn from the local routing table You do not want this

address to be routed, so be sure to click on this loopback entry, and click Remove before going to the next page You can add more IP address ranges by clicking Add, and remove existing ones by clicking Remove If you accidentally remove a range, and want to get it back, click Restore

After you are finished adding the local address ranges, click Next

8 The ISA Server VPN Configuration File page appears as in Figure 10.72 Figure 10.72 The ISA VPN Computer Configuration File Page

On this page, enter the name of the vpc file the wizard will create You will use this file on the remote VPN server to configure the remote VPN server settings Enter a password, and confirm the password

After entering this information, click Next

9 The last page of the wizard allows you to review your settings Click Details

You’ll see text similar to the following describing your configuration:

ISA Server Virtual Private Network (VPN) connection identification:

DalNorth_DalSouth will be created on this router

DalSouth_DalNorth will be written to file

VPN protocol type:

Use L2TP over IPSec, if available Otherwise, use PPTP

Destination address of the remote ISA Server computer:

isa.tzo.com

Dial-out credentials used to connect to remote computer running

ISA Server:

User account: DalSouth_DalNorth

Domain name: CONFEDERATION

Remote Network IP addresses range:

192.168.9.0 - 192.168.9.255

Remote ISA computer configuration:

IP address of this machine: 222.222.222.222

Local Network IP addresses range:

192.168.1.0 - 192.168.1.255

192.168.10.0 - 192.168.10.255

The configuration file created for the remote ISA Servercomputer:

c:\vpndal.vpc

Dial-in credentials created:

The user account DalNorth_DalSouth was created on this computer,

with the password set to never expire

Note:

A strong password was generated for the user account

Changes made to the password will need to be applied to the

dial-on-demand credentials of the remote computer.

Note that in addition to the demand-dial interface, a user account has been created on the machine that will allow the remote router to dial in to the local machine When you run the wizard on the remote machine, a user account will also be created on that machine to allow the local machine to dial in using the virtual routing interface

10 After reviewing the configuration, click Back, and then click Finish

You can open the Routing and Remote Access console to see that a new static route has been added, as well as a new demand-dial interface that will be used to access the destination network included in the static route

Configuring the Remote VPN

After you have completed the Local VPN Wizard and created the vpc file, copy the file to

a floppy disk, or email it to the remote site Once the file is available at the remote site, you can begin to create the VPN interface on the remote computer to complete the

gateway-to-gateway VPN configuration

Perform the following steps on the remote VPN server:

1 Open the ISA Management console, expand your server or array, and click on the Network Configuration node in the left pane Click Set Up

right-Remote ISA VPN Server

2 You will see the Welcome page as shown in Figure 10.73 Click Next to

continue

Figure 10.73 The Remote ISA Server VPN Configuration Welcome Page

3 The ISA VPN Computer Configuration File page appears as in Figure 10.74 Figure 10.74 The ISA VPN Computer Configuration File Page

On this page, enter the path to the vpc file that you’ve created You can

click Browse to find the file on the hard disk or floppy Enter the same

password as you used when you created the file Click Next

4 On the last page of the wizard, you can review the settings by clicking Details

You will see something like what appears here:

Configuration read from file:

ISA Server Virtual Private Network (VPN) connection identification:

DalSouth_DalNorth will be created on this router

Destination address of the remote ISA Server computer:

222.222.222.222

Dial-in credentials created:

The user account DalNorth_DalSouth was created on this computer,

with the password set to never expire

Note:

A strong password was generated for the user account

Changes made to the password will need to be applied to the

dial-on-demand credentials of the remote computer

Dial-out credentials used to connect to remote computer running

ISA Server:

User account: DalNorth_DalSouth

Testing the Configuration

After running the wizard on both the local and remote computers, open the RRAS

console on the local computer, and then initiate a call from a machine on the local

network to the remote network by requesting a resource on the remote network Your RRAS Routing Interfaces node will show that the Demand-dial interface has connected, as shown in Figure 10.75

Figure 10.75 The Local Demand-Dial Interface Is Connected

Click on the Port node in the RRAS console, and you’ll see the status of the VPN port as Active, as shown in Figure 10.76

Figure 10.76 The VPN Port Is Active

To view the static routes created to access the remote network, click on the Static Routes node in the RRAS console, and you’ll see something like what appears in Figure

10.77

Figure 10.77 The Static Routes Node in the RRAS Console

Summary

In this chapter, you learned about publishing services to external network users By publishing services, you can maintain services on your internal network, and safely make them available to external users with minimal risk from external intruders

We first discussed secure Web publishing The Web Publishing Wizard makes it easy to publish Web services to external network users Inbound requests for Web

services are received by the Web Proxy Service’s Inbound Web Requests Listener, which listens on the external interface’s port 80 These requests are processed by the Web Proxy Service, and subject to rules and forwarded to internal servers

The advantage of using the Web Proxy Service to intercept inbound Web requests

is that you can publish multiple Web servers on the internal network You can publish multiple Web servers through port 80 on the external interface of the ISA server, becausethe Web proxy server can read the destination Web site address in the request, and compare that information to the Web publishing rules If a destination set in one of those rules contains an entry that matches the request, it will be forwarded to the internal Web server

We then discussed server publishing The Server Publishing Wizards allow you to publish servers on the internal network based on protocol definitions If there is a

protocol definition that allows the primary connection for inbound access, then you can use the definition in a server publishing rule

The server publishing method isn’t quite as sophisticated as the Web publishing method While the Web Publishing Wizard allows you to publish multiple Web sites that alllisten on the ISA server’s port 80 on the external interface, server publishing allows you

to publish a single service bound to a particular port per IP address For example, after you publish an internal SMTP server, that server will be bound to port 25, and you will not

be able to publish any other mail servers on port 25 on that IP address

The Secure Mail Publishing Wizard walks you through the steps of publishing a mail server on the internal network The wizard makes it easy to select the appropriate mail-related protocols, and automatically configures the protocol rules required to publish the internal mail server The wizard also supports enabling message screening for mail

coming in to, and out of, the internal network

In this chapter, we reviewed some of the features of the H.323 gatekeeper You learned that the H.323 Gatekeeper Service is comprised of two important components: the gatekeeper and the gateway The gatekeeper makes decisions regarding routing of requests, and then the gateway component forwards those requests For inbound

connections, the gateway receives the requests, and then forwards them to the

gatekeeper for resolution of internal network hosts

The gatekeeper allows for audio/visual and text messages to be shared between computers using H.323-compliant applications such as Microsoft NetMeeting You saw that clients using NetMeeting behind the gatekeeper should configure the NetMeeting application to use the gatekeeper’s internal interface External clients that are not behind

a gatekeeper should configure their NetMeeting application to use a gateway that is the external interface of an ISA server computer

The H.323 gatekeeper was designed with a gatekeeper-to-gatekeeper design in mind When you have such a setup, the gatekeeper can easily connect to the destination gateway based on routing rules, and internal clients on both sides can connection to internal clients on the other side of a gatekeeper This is in contrast to the fact that you cannot have a NetMeeting client that is directly connected to the Internet initiate inbound calls to an internal NetMeeting host behind the gatekeeper

Finally, you saw how to configure ISA Server as a VPN server to allow inbound callsfrom VPN clients, and how to configure a gateway-to-gateway ISA server VPN solution The configuration of VPNs is easy using the VPN wizards included with ISA Server

A wizard allows you to enable inbound VPN client calls using PPTP/MPPE and

L2TP/IPSec After running the wizard, VPN clients anywhere on the Internet can initiate

inbound calls to the ISA VPN server The clients will be assigned an IP address that

is valid on the destination remote network, and will be able to access resources on the network depending on how you configured the server

When you use the wizards to create a gateway-to-gateway solution, you actually run two VPN Wizards: the Local VPN and the Remote VPN The Local VPN Wizard is run onthe network that will initiate inbound calls The Remote VPN Wizard configures the VPN server that will receive the calls from the machine configured with the Local VPN Wizard The wizards create demand-dial VPN interfaces and static routes that use the demand-dial interfaces to reach the remote network The wizards allow you to create a one-way VPN call initiation, or you can choose a two-way call initiation so that both the local and remote VPN servers can initiate outbound calls to the other VPN server

Solutions Fast Track

n The Server Publishing Wizard allows you to publish services on the internal

network In order to do so, there must be a protocol definition to support that

service

n When you publish a server on the internal network using the Server Publishing Wizard, you include the server protocol definition required to publish the server

Web Server Publishing

n The Web Publishing Wizard makes the process of publishing an internal Web server very easy The wizard will walk you through the process of choosing the internal Web server and the ports you want to use on it

n Users on the Internet will access your published Web sites via fully qualified domain names (FQDNs), such as www.isaserver.org

n In order for your publishing rules to work, make sure you have your DNS

client/server infrastructure in place Remember, your published servers are SecureNAT clients of the ISA server

n Firewall clients allow the ISA server to resolve requests on their behalf This is

n ISA Server web publishing rules allow you to redirect HTTP requests as other protocols

n Destination sets allow you a great deal of flexibility in your Web publishing solutions For example, you can use a path statement in a publishing rule to redirect a request to a particular server on the internal network

n ISA Server supports secure Web site publishing using SSL

n Another way to publish a secure Web site is to use server publishing rules rather than Web publishing rules You would publish the internal server using a protocol definition for port 443

Publishing services

n You can publish virtually any service running on your internal network using server publishing rules Server publishing takes advantage of protocol

definitions you’ve created for inbound access to server services

n When a service on the internal network is published via server publishing rules, the port number (for that interface) assigned to the server is dedicated to that rule

n Port redirection is a feature of the Windows 2000 RRAS NAT Service Using this feature, you can forward a message received at one port number on the

external interface of the ISA server to a different port number on the internal server

n It is highly recommended that you use the Web Publishing Wizard if you wish to publish Web protocols

n In order to publish services on the internal network, there must be a protocol definition defined to support the server publishing rule

n Most of your published servers will be configured as SecureNAT clients

n ISA Server includes a special wizard that can guide you through the process of publishing a mail server The Secure Mail Publishing Wizard allows you to

publish multiple mail-related protocols at once

n Outlook Web Access (OWA) allows users to access their Exchange mailboxes by using a Web browser

n Publishing a terminal server on the internal network works the same way as publishing the internal interface of the ISA server

The H.323 Gatekeeper Service

n The H.323 Gatekeeper Service allows H.323-aware applications to communicatewith each other over an intranet or over the Internet

n The H.323 Gatekeeper Service was designed to optimize the benefits of LAN calls When each LAN has a gatekeeper and NetMeeting clients registered with their respective gatekeepers, users can call NetMeeting clients on other networks by using either an email address or a telephone number

LAN-to-n NetMeetiLAN-to-ng clieLAN-to-nts caLAN-to-n be coLAN-to-nfigured to use ILS servers oLAN-to-n the iLAN-to-nterLAN-to-nal

network, and call other internal NetMeeting clients registered with the ILS

server

n Phone number rules can be used to route requests based on telephone number strings These are helpful if you plan to implement multiple H.323 gatekeepers

in your organization, and partition client registrations based on prefixes

Virtual Private Networking

n ISA Server supports virtual private networking by allowing inbound access to the ISA server by VPN clients, and by configuring ISA Server in a gateway-to-gateway configuration

n The Routing and Remote Access Service (RRAS) is required in order to

configure the VPN server components on the ISA server

n If you want to allow external VPN clients to dial in to the ISA server, you can use the VPN Client Wizard to allow inbound access

Frequently Asked Questions

Q: Can I publish multiple Web sites using a single IP address on the external interface of the ISA server?

A: Yes You need to configure a destination set that includes an FQDN for each of your sites, and then have an entry in a publicly available DNS server for each site The DNS should resolve your names to the external interface of the ISA server After creating the DNS entries and the destination sets, use the destination sets to publish your Web sites

Q: I want to publish an internal FTP site, but I also want to require authentication to access the site Is there any way I can do this with ISA Server?

A: Yes You can configure a Web publishing rule for your FTP site After you create the rule, redirect the inbound HTTP requests so that the ISA server sends an FTP request

to the internal server When creating the rule, require authentication In this way, you can publish an FTP server and use authenticated access at the same time

Q: The IIS logs do not show information about which external users are accessing my Web sites on my internal Web server I would like to get that information on the IIS server, and not have to parse the Web Proxy Service logs to get user information I would also like to install my server certificate on the internal Web server, and not have to install it on the ISA server Is there any way I can do this?

A: Yes, but at the cost of some functionality You can have your user information

recorded in the IIS logs, and install your certificate on the internal server and allow SSL connections directly to the server if you use server publishing In order to do this, you must change the port the Inbound Web Requests Listener uses, and then create a publishing rule using the HTTP (server) protocol definition You would then create a second publishing rule using a protocol definition that allows inbound access to TCP port 443 The drawback of using server publishing for your Web sites is that you

bypass the Web Proxy Service; therefore, you can only publish a single Web server on the internal network using the default HTTP port, TCP 80

Q: Can I publish an internal terminal server that is using the Terminal Services Advanced Client?

A: Yes However, you must publish both the terminal server using a protocol definition that allows inbound access to TCP port 3389, and you must also publish the Web site that contains the TSAC server extensions Note that when you publish a Terminal Service to be used by TSAC, you cannot change the port number on which the

terminal server listens, and you cannot change the port to which the client will make its requests

Q: I have published an internal mail server Inbound mail seems to come in fine, but the outbound mail received by the internal mail server seems to get stuck in the queue I have my mail server configured to resolve domain names for outbound mail, and I do not use a smart host What might be the problem?

A: That fact that inbound mail comes in indicates that the DNS is functioning properly on the Internet, so that external servers are able to send mail to the external interface of your ISA server However, the problem with sending mail out is probably related to the internal mail server not being able to access a DNS server that can resolve domainnames to properly route the mail The best solution is to configure an internal DNS server that can use a forwarder on the Internet to resolve Internet names Make sure that there is a protocol rule that will allow outbound DNS queries for the DNS server, and make sure the DNS server is a SecureNAT client

Q: I am trying to publish a multiplayer game server that requires multiple primary and secondary connections I have configured the server as a SecureNAT client, but the games do not seem to work correctly What can I do to fix this?

A: Some services cannot be published properly when the internal server is configured as

a SecureNAT client In order to allow such services to operate properly, you will need

to configure a wspcfg.ini file on the internal server that will allow you to bind the appropriate ports on the external interface of the ISA server You will also have to configure the internal server as a firewall client This server publishing configuration is