TMG Back to Basics - Part 1: Server Publishing Rules

[alika]

If you’re new to the TMG firewall, you might have wondered what Server Publishing Rules are all about. The good news is that Server Publishing Rules are really simple – they are essentially reverse Network Address Translation rules that allow you to reverse NAT for a number of protocols. However, Server Publishing Rules are more than just reverse NAT, because the TMG firewall includes a number of Application Filters (essentially NAT Editors) to support complex protocols, and there are also a number of security related application Filters that improve the security of the reverse NAT.
In contrast to Web Publishing Rules, which can be extraordinarily complex, Server Publishing Rules are typically very simple. Because of their simplicity, some TMG administrators prefer to use Server Publishing Rules over Web Publishing Rules, even though a Web Publishing Rule might be the better decision from a security point of view. For example, publishing Exchange 2010 can be very complex, and while there is a wizard that does part of the work for you, it ignores the auto discovery feature that is so useful. Thus many people will do an SSL Server Publishing Rule to publish Exchange instead of going through the major hassle of trying to Web Publish Exchange.
In fact, because that scenario is so common, in today’s example we’ll create an SSL Server Publishing Rule to show you exactly how it’s done. To begin creating a Server Publishing Rule, click on the Firewall Policy node in the left pane of the console, and then click the Tasks Tab in the Task Pane. On the Task Pane, click the Publish Non-Web Server Protocols link, as shown in Figure 1.
http://www.isaserver.org/img/upl/image0021290459471188.jpg
Figure 1
This brings up the Welcome to the New Server Publishing Rule Wizard page, shown in Figure 2. In the Server publishing rule name text box, enter a number for the Server Publishing Rule. In this example, we’ll name the rule Complex SSL Site (we’ll pretend, for purposes of this example, that this is an Exchange CAS server that we’re publishing). Click Next.
http://www.isaserver.org/img/upl/image0041290459471203.jpg
Figure 2
On the Select Server page, shown in Figure 3, enter the IP address of the server on the internal network that you want to publish. If you don’t know the IP address, you can click the Browse button.
http://www.isaserver.org/img/upl/image0061290459471203.jpg
Figure 3
When you click the Browse button, it will bring up the Find Internal IP Address dialog box that’s shown in Figure 4. Enter the name of the server you want to publish in the Server name text box and click Browse. When the system finds the server, it will list the IP address in the IP addresses list. Click OK after finding the IP address.
http://www.isaserver.org/img/upl/image0081290459471203.jpg
Figure 4
After you see the IP address on the Select Server page, shown in Figure 5, click Next.
http://www.isaserver.org/img/upl/image0101290459517422.jpg
Figure 5
On the Select Protocol page, as seen in Figure 6, select the protocol you want to allow to be used by the published server. In this example, we want to allow SSL to the published server, so we select the HTTPS Server protocol from the drop down list. Note that when publishing sites using Server Publishing Rules, you use “Server” protocols, such as the HTTPS Server protocol we used in this rule. Click the Properties button.
http://www.isaserver.org/img/upl/image0121290459517438.jpg
Figure 6
This brings up the Properties dialog box that’s shown in Figure 7. Click the Parameters tab. Here you can see the port or port ranges that are used by the protocol. When you use the built in protocols, you typically won’t want to change the ports. Here you get information about the primary and secondary connections that are supported by the protocol. You also get information about any Application Filtersthat are bound to the protocol. In this example, you can see that this server has Bandwidth Splitter installed on it, and the Bandwidth Splitter Application Filter appears in the Application Filters list. Click Cancel to dismiss this dialog box.
http://www.isaserver.org/img/upl/image0141290459517438.jpg
Figure 7
Click the Ports button. In the Ports dialog box shown in Figure 8, you can exercise more fine-tuned control over the ports used by the Server Publishing Rule. In the Firewall Ports section, you can use the default port for the protocol, or you can change the port. For example, the default port used by the HTTPS Server protocol is TCP 443. However, if you wanted to use an alternate port, you could select the Publish on this port instead of the default port option and name an alternate port. As long as no other rule or application is listening on that port and IP address, it’ll work fine.
You can also do port redirection if you like. In the Published Server Ports section, you see that the default setting is to Send requests to the default port on the published server. In this example, the HTTPS Server protocol uses the default port of TCP 443 so it would forward the connection to that port on the published server. However, if you wanted to use another port on the published server to accept SSL connections, you can change it to something else, and then select the Send requests to this port on the published server option and enter the alternate port. This is pretty user friendly stuff.
You can also control which source ports are used by the user who wants to connect to the published server. In the Source Ports section, the default setting is Allow traffic from any allowed source port. Since most applications are going to use a dynamically assigned source port, this is generally the best way to go. However, if you want to improve the security for some applications (such as RDP publishing), you could select the Limit access to traffic from this range of source ports and then enter a limited range, and force the RDP client application to use the ports you designate here.
http://www.isaserver.org/img/upl/image0161290459517438.jpg
Figure 8
Click Next after selecting the protocol that you want to publish on the Select Protocol page, shown in Figure 9.
http://www.isaserver.org/img/upl/image0181290459560813.jpg
Figure 9
Before we move to the next page of the wizard, let’s take a look at the Server Protocols that are available to you “out of the box”. Remember, when you create Server Publishing Rules, you need to use a “Server” protocol. When you click on the Firewall Policy node in the left pane of the console and click the Toolbox tab (you can’t do it right now because you’re in the middle of the wizard) and then click the Server Protocols node, shown in Figure 10, you’ll see a list of Server Protocols that you can use in Server Publishing Rules. This is a pretty comprehensive list! Of course, if the protocol you want to use isn’t in this list, you can always create your own Server Protocol by clicking on the New menu.
http://www.isaserver.org/img/upl/image0201290459560813.jpg
Figure 10
Now let’s get back to the wizard. On the Network Listener IP Addresses page that’s shown in Figure 11, select the Network or Networks on which you want to listen for incoming requests. In most instances you’ll want to accept incoming connections from the default External Network, so you’ll put a checkmark in the External checkbox on this page. However, in most cases you don’t want to listen on all the IP addresses on the NIC. If you have more than one IP address bound to the external interface, you should click the Addresses button and select the specific IP address to which you want users to make the connection. If you have a NAT device in front of the TMG firewall, then you should select the IP address to which the NAT device is forwarding the connections when external users are trying to connect to the published server.
http://www.isaserver.org/img/upl/image0221290459560813.jpg
Figure 11
Review your settings on the Completing the New Server Publishing Rule Wizard page, shown in Figure 12, and then click Finish.
http://www.isaserver.org/img/upl/image0241290459560828.jpg
Figure 12
After you click Finish, you can see the new Server Publishing Rule in the Firewall Policy list, as seen in Figure 13.
http://www.isaserver.org/img/upl/image0261290459599750.jpg
Figure 13
Double click on the Server Publishing Rule you just created. There are a couple of tabs worth taking a look at here, as they expose some options that you didn’t have when you went through the wizard. Click on the From tab, shown in Figure 14. Notice on the From tab that This rule applies to traffic from these sources lists Anywhere. In most cases, you’ll want to leave it this way. But what if you have some addresses or networks that you don’t want to have access to the published server through this rule? You can click the Add button in the Exceptions section and enter those addresses. This gives you some measure of access control over which addresses can connect through this Server Publishing Rule.
http://www.isaserver.org/img/upl/image0281290459599766.jpg
Figure 14
On the To tab, shown in Figure 15, notice the two options in the Request for the published server section. The default setting is Requests appear to come from the original client. This means that the published server will “see” the actual IP address from which the connection came over the Internet. If you choose this option, the published server will need a route to the Internet and its default gateway must provide access to such a route. If you don’t want to provide the published server a route to the Internet, you can select the Requests appear to come from the Forefront TMG computer. When you select that option, the published server only needs a route that enables it access to the internal IP address of the TMG firewall. However, when you select that option, the source IP address for the incoming connections to the published server will be the IP address on the internal interface of the TMG firewall and that address will appear in the published server’s log files.
http://www.isaserver.org/img/upl/image0301290459599766.jpg
Figure 15
Once you’re done, click Apply at the top of the middle pane of the TMG firewall console and save the changes to firewall policy. After that, connections to the published server will be allowed on the protocol you selected for the rule

[alika]

Continuing our Back to Basics series, this time we’re going to talk about how to use the TMG Firewall log viewer. The TMG firewall, like the ISA firewall before it, is a product that can do many good things. It can serve as a network firewall, forward and reverse web proxy server, remote access VPN server, site to site VPN server, and web anti-malware and URL filtering server; these are some of the key roles the TMG firewall can play on your network. But one feature that might not be apparent to the new TMG firewall administrator is the powerful and useful logging feature. In this article, we’ll provide an overview of the TMG firewall’s logging feature.
There’s no better way to understand how it works than to see it in action. To begin our overview, let’s click the Logs & Reports node in the left pane of the TMG firewall console, as seen in Figure 1 below.
http://www.isaserver.org/img/upl/image0021291404768114.jpg
Figure 1
In the Task Pane, on the Tasks Tab, you’ll see a number of options available for configuring and running the logging function on the TMG firewall. Let’s start by clicking the Configure Firewall Logging link in the Tasks Tab, as seen in Figure 2 below.
http://www.isaserver.org/img/upl/image0041291404768129.jpg
Figure 2
This brings up the Firewall Logging Properties dialog box. On the Log tab, you can choose what type of logging you want to enable. There are three options:

SQL Server Express Database (on local server)
DQL Database
File
The default setting is SQL Server Express Database (on local server). If you want to log to an off-box SQL server, you would select the SQL Database option and then click the Options button to configure what SQL database the TMG firewall would use for logging. If you want to log to a flat file, you can select the File option and then select the file type; in this case, both W3C extended log file format and TMG Log File format are available options.
So how do you decide which is best for you? File logging is faster than SQL logging, but you have limited query abilities on flat file logging, so if you don’t have an off-box SQL database you want to use, I recommend that you use the default logging option. Click the Options button to the right of the SQL Server Express Database (on local server) option, which is shown in Figure 3.
http://www.isaserver.org/img/upl/image0061291404768145.jpg
Figure 3
In the Options dialog box, configure the location where you want to save the log files, as shown in Figure 4. The default location is the Logs folder in the default TMG installation folder on the local hard disk, but you can select another location by typing in the full path or browsing for it. You can also configure log file storage limits. The defaults are:

Limit total size of log files is limited to 8 GB by default
Main free disk space is set to 512 MB by default – this prevents the hard disk from becoming full with log files
Main log storage limits by : Deleting older log files as necessary is the default setting when storage limits are exceeded; you also have the option to discard new entries if you prefer to keep the old entries
Delete files older than (days) is set to 7 by default
Notice that the Compress log files option is grayed out when we selected to log to a SQL or SQL Express database. This is because you can only compress flat file logs.
http://www.isaserver.org/img/upl/image0081291404768145.jpg
Figure 4
Click the Fields tab, shown in Figure 5. Here you can specify which fields the TMG firewall will log for each of the connections that are logged to the firewall service. If you find that your log files are too large, one thing you can do to decrease the size is to reduce the number of fields that are logged for the connections.
http://www.isaserver.org/img/upl/image0101291404801223.jpg
Figure 5
Note that similar options are available when you click the Configure Web Proxy Logging link in the Tasks Tab on the Task Pane.
Now, we will click the Configure Log Queue link in the Tasks Tab on the Task Pane. This brings up the Log Queue Storage Folder dialog box that’s shown in Figure 6. Here you can configure where you want to place the log queue. The log queue is a storage location for log entries that need to wait for the firewall to format them properly. The purpose of the log queue is to allow the TMG firewall to keep log entries that might have otherwise been lost because they were coming in too quickly. With the TMG firewall log queue, these entries are quickly placed in the queue and will wait there until the firewall is able to process the log entries.
http://www.isaserver.org/img/upl/image0121291404801254.jpg
Figure 6
Now click the View Log Status link in the Tasks Tab in the Task Pane. This will display the Log Status dialog box, which is shown in Figure 7. You can view the following information here:

Server shows the server where the log queue is being reported
Updated Up To shows the time to which the log file has been updated
Log Queue (KB) shows the number of log entries that are currently in the log queue
Status shows the status of the log queue
This is all useful information to check when you suspect that you’re getting flooded by a virus or worms.
http://www.isaserver.org/img/upl/image0141291404801254.jpg
Figure 7
Next, click the Define Log Text Colors link on the Tasks Tab in the Task Pane and you will see the Define Log Text Colors dialog box that’s shown in Figure 8. The default colors are listed here for the most common log file entries of interest. Color coding of the log file entries makes it much easier for you to get a quick visual representations of what how many entries of each type there are, and to find the entries you’re looking for. You can click the Color button if you want to change the color of any of these entries. Another handy feature is that you can use the Export Colors Scheme and Import Colors Scheme button to export and import color schemes from other TMG firewalls.
http://www.isaserver.org/img/upl/image0161291404801286.jpg
Figure 8
The Hide IPv6 log entries link in the Tasks Tab on the Task Pane, shown in Figure 9, is a very useful option. When you spend a lot of time reading TMG log files, you’ll find that there are a very large number of IPv6 broadcasts on your network. These IPv6 entries can make the log file very cluttered and hard to “eyeball”. When you click this button, the IPv6 entries will still be logged, but they will be hidden from view so that it’s easier for you to view the log entries without the IPv6 noise.
http://www.isaserver.org/img/upl/image0181291404837098.jpg
Figure 9
Now click the Edit Filter link in the Tasks Tab on the Task Pane. Here you will see that there are three default values:

Log Record Type is set to firewall or web proxy filter. You typically will not change this.
Log Time is set to live – you will sometimes want to change this
Action is set to not equal Connection Status – this helps reduce the noise in the log file filter
In Figure 10 below, you can see that I have selected the Log Time entry and then clicked the down arrow for the Condition drop down box. You will see here that there are many options for filtering the time window for the log file entries you want to see. Note that after you change the value, you will need to click the Update button to change the filtering value.
http://www.isaserver.org/img/upl/image0201291404837114.jpg
Figure 10
You can filter the log files by a large number of factors. In Figures 11, 12 and 13 below you can see the options in the Filter by drop down list. When you select a value on this list, you then click the Condition down arrow to select the condition and then you set the Value. After you do these three things, you click the Add To List button so that it will appear in the list of filters.
http://www.isaserver.org/img/upl/image0221291404837114.jpg
Figure 11
http://www.isaserver.org/img/upl/image0241291404837114.jpg
Figure 12
http://www.isaserver.org/img/upl/image0261291404871739.jpg
Figure 13
In the Figure 14 below, I selected the Client IP entry in the Filter by drop down list. Then I clicked the down arrow for the Condition drop down box. Here you can see that you have a number of choices, which allows you to drill down to the entries that interest you the most.
http://www.isaserver.org/img/upl/image0281291404871739.jpg
Figure 14
After you make the selections you want for the log filter, click the Start Query button. After a while, you will see in the status bar on the bottom on the console that the Query is done and it will show you the number of log file entries that match the parameters of your query, as shown in Figure 15.
http://www.isaserver.org/img/upl/image0301291404871754.jpg
Figure 15
The results of the query will appear in the console and the colors of the entries will match those that you configured in the log colors dialog box we saw earlier. Notice that the names of the fields are in the columns for each of the log file entries, as shown in Figure 16. You can scroll to the right to see the details of each of the log file entries.
http://www.isaserver.org/img/upl/image0321291404871754.jpg
Figure 16
Note that the columns you see at first are the default fields configured to be displayed. If there is a field that you’re interested in and it doesn’t appear, you can right click one of the columns and click the Add/Remove Columns command, as seen in Figure 17 below.
http://www.isaserver.org/img/upl/image0341291404902598.jpg
Figure 17
This brings up the Add/Remove Columns dialog box. On the left side is a list of Available columns, which you can see in Figure 18. Scroll through the list and find the field(s) that you’re interested in and then click the Add button to move it to the Displayed columns section. Click OK and then return to the console. Now scroll to the right and you’ll see the information for those columns you added listed for the log file entries you filtered. Nice!
http://www.isaserver.org/img/upl/image0361291404902614.jpg
Figure 18
When you click on a log file entry, you can see more details in the details section under the list of the log file entries. In Figure 19 below you can see detailed information about the entry, including valuable HTTP and proxy related information in the Additional information section.
http://www.isaserver.org/img/upl/image0381291404902614.jpg
Figure 19

[alika]

Part 3: Protocol Definitions

This week we continue our TMG Back to Basics series with a simple, but very important basic TMG concept that you might not even be aware of: Protocol Definitions. The reason why you might not be aware of Protocol Definitions is that Microsoft has done a great job of including a number of Protocol Definitions in TMG right out of the box so that you don’t even need to know about them. But there are times when it is useful to be aware of this feature.
Protocol Definitions are a key feature of every firewall rule you create on the TMG firewall. The Protocol Definition defines the protocol that’s used to allow inbound or outbound access to or through the TMG firewall. For example, if you create a rule that allows outbound access to the HTTP and HTTPS protocols, that rule will include the Protocol Definitions for the HTTP and HTTPS protocols. A Protocol Definition is required for all firewall rules, which includes Access Rules and Web Publishing Rules and Server Publishing Rules.
Let’s delve a little deeper into this. To view information about your Protocol Definitions, click the Firewall Policy node in the left pane of the TMG firewall console. Click the Toolbox tab in the Tasks Tab, then click the Protocols entry on the Toolbox tab. There you will see a number of groups of Protocol Definitions, as shown in the figure below.
http://www.isaserver.org/img/upl/image0021293097198652.jpg
Figure 1
Click on the Common Protocols group. Here, as shown in Figure 2, you will see a list of Protocol Definitions for the protocols that are most commonly used when configuring firewall rules on the TMG firewall.
http://www.isaserver.org/img/upl/image0041293097198668.jpg
Figure 2
Scroll down the list of Protocol Groups. Click on the All Protocols group, as shown in Figure 3. Here you will see a list of all the Protocol Definitions that are included in the TMG firewall right out of the box. There are well over a hundred Protocol Definitions included and that selection should support just about any protocol to which you would want to allow inbound or outbound to or through the TMG firewall in typical scenarios. But there are special circumstances when you’ll need to create your own definitions. Scroll through the list of Protocol Definitions to get an idea of what’s available. Being aware of what’s available out of the box can save you time when you are considering creating your own custom Protocol Definition. After all, why go to the trouble of creating a new Protocol Definition if there’s already one there that will serve your purpose?
http://www.isaserver.org/img/upl/image0061293097198668.jpg
Figure 3
Now let’s look at a specific definition. Double click the HTTPS Protocol Definition. This brings up the HTTPS Properties dialog box that’s shown in Figure 4. On the General tab, you’ll see the name of the Protocol Definition and a short description of the protocol. You’ll also see the Associated Standard Protocol section, but it will be grayed out in most cases; we’ll talk about this feature later.
http://www.isaserver.org/img/upl/image0081293097198668.jpg
Figure 4
Now click on the Parameters tab. On the Parameters tab, shown in Figure 5, you can see the Primary Connections, the Secondary Connections and the Application Filters sections. We’ll talk about these sections in more detail later, too – but you can see here which protocols, ports and direction is associated with the protocol.
http://www.isaserver.org/img/upl/image0101293097240199.jpg
Figure 5
Speaking of directions for Protocol Definitions, check out Figure 6 below. Notice that there is an SMTP Protocol Definition and a SMTP Server Protocol Definition. You might be wondering: What is the difference?
http://www.isaserver.org/img/upl/image0121293097240199.jpg
Figure 6
It’s all about direction. If you look at the Parameters of the SMTP Protocol Definition, shown in Figure 7, you’ll see that the Direction is Outbound. When you create Access Rules, you will always use a Protocol Definition that supports outbound protocols.
http://www.isaserver.org/img/upl/image0141293097240215.jpg
Figure 7
Now if you look at the SMTP Server Parameters, shown in Figure 8, you’ll see that the direction there is Inbound. When you create Server Publishing Rules, you will always use a Protocol Definition that has the Inbound direction. In addition, notice that there is an Application Filter associated with the SMTP Server Protocol Definition. In this case, the SMTP Filter is associated with the SMTP Server Protocol Definition. This means that some level of application layer inspection will be applied to connections that match firewall rules that use the SMTP Server Protocol Definition.
http://www.isaserver.org/img/upl/image0161293097240215.jpg
Figure 8
How to Create New Protocol Definitions

Now that you’ve seen some examples of existing Protocol Definitions, let’s find out how you can create your own custom Protocol Definitions. Why would you ever want to do this? Well, you might need to create a custom definition if you have a new application that requires a protocol that isn’t included with the out of the box Protocol Definitions.
Luckily, it’s pretty simple. You start creating a new Protocol Definition by clicking the Toolbox tab in the Task Pane and then clicking the Protocols section. Then click the New menu and click Protocol, as shown in Figure 9 (the RPC Protocol is an advanced option that we won’t cover in this article).
http://www.isaserver.org/img/upl/image0181293097277387.jpg
Figure 9
This will bring up the Welcome to the New Protocol Definition Wizard page that’s shown in Figure 10. Enter a name for the new Protocol Definition in the Protocol Definition name text box. In this example, we’ll name the Protocol Definition Disambigulator Protocol and then click Next.
http://www.isaserver.org/img/upl/image0201293097277402.jpg
Figure 10
On the Primary Connection Information page, as seen in Figure 11, you enter the protocol and the port or ports required for the primary connection. The primary connection is the first connection(s) made by the system initiating the connection to another host. Click the New button.
http://www.isaserver.org/img/upl/image0221293097277402.jpg
Figure 11
This brings up the New/Edit Protocol Connection dialog box that you can see in Figure 12. Here you must select the following:

Protocol type. You select from a list that includes TCP, UDP, ICMP and IP-Level. If you select IP-Level you will need to enter the IP Protocol Number in the Protocol Number text box. If you select the ICMP option, you will need to enter an ICMP Code and an ICMP Type. For TCP and UDP protocols, you will need to enter a port or port range. For all protocols, you will need to enter a direction.
Direction. Here you enter the direction. For all protocols except UDP, you need to select either inbound or outbound. For UDP, you have more choices, as you’ll see in the next step.
Port Range. If you select TCP or UDP, you need to enter a port range here. If there is only a single port, then enter the same port number in the From and To boxes.
ICMP Properties. If you are creating a new ICMP protocol, then you will need to enter an ICMP type and code in the text boxes.
http://www.isaserver.org/img/upl/image0241293097277402.jpg
Figure 12
If you select a UDP protocol, then your choices for selecting a direction are different. As you can see in Figure 13, our choices are Receive, Receive Send, Send and Send Receive. It can be hard to know in advance which direction will work. In general, I will start with Receive or Send (depending on the direction – receive is equivalent to inbound and send is similar to outbound). If that doesn’t work, I’ll use Receive Send or Send Receive. It’s tricky in some cases, and you might need to experiment with the direction for UDP protocols.
http://www.isaserver.org/img/upl/image0261293097323902.jpg
Figure 13
In this example, our protocol is a UDP protocol and it’s used for outbound connections – so we will select UDP and Send, as shown in Figure 14. This protocol uses a single port, which is 9966, so we enter that number in the From and To boxes in the Port Range section and then click OK.
http://www.isaserver.org/img/upl/image0281293097323902.jpg
Figure 14
The Secondary Connections page, which you can see in Figure 14, is used for what we call “complex protocols”. A complex protocol is one that requires new connections after the initial connection. For example, the client might require a secondary inbound connection from the server after it establishes its connection to the server using the primary connection protocol/port. If that’s the case, you will need to configure a secondary connection. It’s important to note that if you have a protocol that requires a secondary connection, the client type you’re using is going to matter. SecureNAT clients require an Application Filter to support complex protocols. However, if you’ve deployed the Firewall Client (TMG client), then you don’t need an application filter. Application Filters are complex to develop, so it’s highly recommended that you deploy the TMG client if you need support for secondary connections.
http://www.isaserver.org/img/upl/image0301293097323902.jpg
Figure 15
Okay, we’re at the end of the wizard. Let’s review the settings on the Complete the New Protocol Definition Wizard page that’s shown in Figure 16 and click Finish.
http://www.isaserver.org/img/upl/image0321293097323918.jpg
Figure 16
You’re finished with the wizard, but you’re not done yet. Go back to the Toolbox tab and click the User-Defined group. Here you see a list of Protocol Definitions that you created. Double click on the Protocol Definition you just created, as shown in Figure 17.
http://www.isaserver.org/img/upl/image0341293097356277.jpg
Figure 17
Notice on the General tab, shown in Figure 18, that you have the option to Associate this protocol definition with this standard protocol. You would choose this option if you wanted the TMG NIS to inspect this connection with signatures written for the protocol you select here. In general, you wouldn’t want to do this, but there might be situations where you’d want to take advantage of this option. One example might be when you want to support an alternate port for HTTP or HTTPS connections that are being established outside of the web proxy filter.
http://www.isaserver.org/img/upl/image0361293097356293.jpg
Figure 18
On the Parameters tab that’s shown in Figure 19, you can also associate an Application Filter with the protocol. You need to be careful about doing this, though, since the filters are designed for specific protocols and won’t work if you assign them to Protocol Definition that doesn’t match the requirements of the filters. In general, you would not assign an application filter to a custom Protocol Definition.
http://www.isaserver.org/img/upl/image0381293097356293.jpg
Figure 19
Summary

In this article, we covered Protocol Definitions. All firewall rules require a Protocol Definition as part of the rule configuration. Protocol Definitions are generally designed to be either inbound or outbound. Outbound Protocol Definitions are used for Access Rules and inbound Protocol Definitions are used for Web and Server Publishing Rules. There are also complex Protocol Definitions, where more than one connection is required to support the application. When using complex protocols remember that SecureNAT clients require an application filter to support the complex protocol, whereas Firewall clients do not require an application filter. You likely won’t often need to create new Protocol Definitions, but there might be times when you need to create a custom Protocol Definition to support a new application or product. Let me know if you have questions about Protocol Definitions and I’ll get back to you as soon as possible. Thanks! –Deb.

[alika]

Continuing our TMG “Back to Basics” series, this time we’re going to take a close look at Network Objects. This is one TMG concept that doesn’t get much attention. Although Network Objects aren’t particularly exciting, they are critical to configuring all firewall rules on the TMG firewall. If you don’t have a Network Object to support the source or destination in a firewall rule, then you won’t be able to create the rule that you intend to create.
Network Objects allow you to configure source and destination settings for all firewall rules, including publishing rules, on the TMG firewall. Network Objects are reusable software pieces settings that allow you to define source and destination in a variety of ways. Those of you who have been working with Microsoft firewall products for a while may remember that Network Objects were first introduced with ISA Server 2004. The TMG firewall builds on the Network Objects used in previous versions of the ISA firewall and significantly improves on them.
Working with Network Objects

To find the Network Objects, click the Firewall Policy node in the left pane of the TMG firewall console, and then click the Toolbox tab in the Task Pane. Click the Network Objects section header. Here you will see a list of the types of Network Objects available to you, as shown in Figure 1. Each folder actually contains a number of Network Objects you can use to construct TMG firewall rules.

http://www.isaserver.org/img/upl/image0011295557078384.png
Figure 1
Click the Networks folder. Here you’ll see a list of TMG Firewall Networks that are configured on this machine, as shown in Figure 2. Remember that a TMG Firewall Network is required for each NIC on your TMG computer. In addition, there are some default TMG Firewall Networks, such as the VPN Clients network, which is dynamically constructed to include the IP addresses used by remote access VPN client computers.
For more information on TMG Firewall Networks, check out my article here (http://www.isaserver.org/tutorials/More-Basics-Inside-Look-TMG-Firewall-Networks.html).

http://www.isaserver.org/img/upl/image0021295557078400.png
Figure 2
Now click on the Network Sets folder. This exposes the Network Sets that are currently configured on this computer, as shown in Figure 3. A Network Set is a collection of Networks that you can use when setting a source or destination on an Access Rule or Publishing Rule. The default Network Sets include:

All Networks (and Local Host). This Network Set includes all IPv4 addresses. While this Network Set can be useful for some troubleshooting scenarios, it’s a fairly dangerous Network Set to use because if you create a rule that uses this Network Set as a destination, it includes the Local Host Network, which is the TMG firewall itself and this could potentially open the firewall up to unintended compromise.
All Protected Networks. This Network Set includes all TMG Firewall Networks except for the default External Network. Essentially, this Network Set is defined by all TMG Firewall Network that are behind the TMG firewall.
Forefront Protection Manager. This is not used, as Forefront Protection Manager was cancelled.

http://www.isaserver.org/img/upl/image0031295557078447.png
Figure 3
If you double click on All Protected Networks you will see the Properties dialog box for that Network Set. Click the Networks tab, shown in Figure 4. Note that all Networks that do not have a checkmark in the checkbox are included in the Network Set. This can be a little confusing at first glance since the logical assumption would be that checked items are included.

http://www.isaserver.org/img/upl/image0041295557078447.png
Figure 4
Click the Computers folder. Here you see the Computer objects configured on the TMG firewall, as shown in Figure 5. There are no default Computer objects. All computer objects are custom objects and you need to create them yourself.

http://www.isaserver.org/img/upl/image0051295557182025.png
Figure 5
If you double click on one of the Computer objects, you’ll see that it consists of a name and an IPv4 address, as shown in Figure 6.

http://www.isaserver.org/img/upl/image0061295557182025.png
Figure 6
Click on the Computer Sets folder. Here you see the Computer Sets that are currently configured on the TMG firewall. There are a number of default Computer Sets, and the default Computer Sets will vary based on which edition of the TMG firewall you’re using. In other words, the Standard Edition of the TMG firewall will have different default Computer Sets than the Enterprise Edition of the TMG firewall. In Figure 7 below, you’ll notice that there are a number of Forefront Protection Manager Computer Sets. These are not used because the Forefront Protection Manager project was cancelled.
Some important Computer Sets that you should know about include:

Anywhere. This means, literally, anywhere – which is the same as all IPv4 IP addresses.
Array Servers. This is automatically configured for you to include the IP addresses of all servers that are part of the same array.
Enterprise Remote Management. This Computer Set includes the IP addresses of machines that are allowed to remotely manage the array. This is not automatically populated except in the situation where you use an EMS. In all other cases, you will need to enter the addresses yourself.
Managed Server Computers. This is a predefined list of computers that are allowed to connect to the EMS server.
You can double click on the other Computer Sets to see their intended purposes.

http://www.isaserver.org/img/upl/image0071295557182025.png
Figure 7
When you double click on one of the Computer Sets, you can see the details of the set, as shown in Figure 8. A Computer Set can contain multiple entries, and each entry can be an IPv4 address, a range of IPv4 addresses or even a subnet.

http://www.isaserver.org/img/upl/image0081295557182056.png
Figure 8
Click the Address Ranges folder. In the TMG firewall, there is a single default Address Range, which is Anywhere (IPv6), as shown in Figure 9. Since TMG has very limited support for IPv6, this Address Range is mostly often used to support DirectAccess on UAG DirectAccess servers.

http://www.isaserver.org/img/upl/image0091295557277369.png
Figure 9
When you double click on the Address Range, you can see that it includes the name of the Address Range, the Start Address and the End Address, as shown in Figure 10.

http://www.isaserver.org/img/upl/image0101295557277384.png
Figure 10
Click the URL Sets folder next. There is a single default URL Set, shown in Figure 11, which is not used as it was intended to be used to support Forefront Protection Manager scenarios because – yep, you remembered – FPM was cancelled. All URL Sets now are custom URL Sets that you need to create yourself. URL Sets are used in rules that use the HTTP or HTTPS protocols and are applied only to Web proxy clients. If you want to set a source or destination in a firewall rule that will not have Web proxy clients, then you should use Domain Name Sets instead of URL Sets. In the past, URL Sets were useful for URL Filtering – but with the new TMG Firewall URL Filtering feature, URL Sets are typically used for highly customized access control settings on firewall rules.

http://www.isaserver.org/img/upl/image0111295557277400.png
Figure 11
Now click the URL Categories folder. Here, as shown in Figure 12, you see a large number of URL Categories that are used by the URL Filtering feature included with the TMG firewall. These URL Categories are dynamically updated by the Microsoft Reputation Services servers on the Internet and are not populated on the TMG firewall – so you will not see the URLs in a particular set when you look at the Properties dialog box of specific URL Category.

http://www.isaserver.org/img/upl/image0121295557277400.png
Figure 12
Click the URL Category Sets folder. Here you see a list of the default URL Category Sets, shown in Figure 13. Each Category Set is a collection of other URL Categories. URL Category Sets are intended to simplify the task of URL filtering for you, so that you don’t have to pick and choose multiple URL Categories yourself to get your desired result for web filtering.

http://www.isaserver.org/img/upl/image0131295557371072.png
Figure 13
Double click on one of the URL Categories and click the URL Categories tab in the Properties dialog box. Here, as shown in Figure 14, you will see a list of all the URL Categories. The URL Categories that belong to the set will have a checkmark in the checkbox next to the category.

http://www.isaserver.org/img/upl/image0141295557371072.png
Figure 14
Click the Domain Name Sets folder. Here you see a list of Domain Name Sets configured on this computer, as shown in Figure 15. Domain Name Sets include domain names, which can also include a wildcard on the high-order label in a domain name. Domain Name Sets are used by all TMG client types: SecureNAT, web proxy and Firewall client (TMG client). There are also a number of built-in domain name sets, which vary depending on whether you’re using the Standard or Enterprise Edition of the TMG firewall. Some of the Domain Name Sets are pre-populated for you, such as the Sites Example from HTTPS Inspection.

http://www.isaserver.org/img/upl/image0151295557371072.png
Figure 15
You can see the details of a Domain Name Set when you double click on it, as shown in Figure 16. You can add more domain names to the list by clicking the Add button.

http://www.isaserver.org/img/upl/image0161295557371088.png
Figure 16
Click on the Web Listeners folder, as you can see in Figure 17. Note that there are no default Web Listeners – all Web Listeners are custom and you need to create the ones you need.

http://www.isaserver.org/img/upl/image0171295557476056.png
Figure 17
So far you’ve seen the Network Objects and the default objects that are included with the TMG firewall. But you can also create your own custom Network Objects, and in some cases, you will have to create custom objects since there are no default objects for a particular group.
To create a new Network Object, click on the New menu. From there you see a list of Network Object types as shown in Figure 18.

http://www.isaserver.org/img/upl/image0181295557476056.png
Figure 18
If you choose the Computer Network Object, the New Computer Rule Element dialog box appears, as shown in Figure 19. Here you enter a name for the computer, the IPv4 address of the computer, and an optional description.

http://www.isaserver.org/img/upl/image0191295557476056.png
Figure 19
If you choose the Address Range option, you’ll see the New Address Range Rule Element dialog box that’s shown in Figure 20. Here you enter a Name for the Address Range, then the Start Address and the End Address. There is also an optional description.

http://www.isaserver.org/img/upl/image0201295557476056.png
Figure 20
If you select the Subnet option, you’ll see the New Subnet Rule Element dialog box that’s shown in Figure 21. Here you enter a name for the subnet, the Network Address, which includes the network ID and the mask, and an optional description.

http://www.isaserver.org/img/upl/image0211295557585963.png
Figure 21
If you click Computer Set, you will see the New Computer Set Rule Element dialog box that’s shown in Figure 22. Here you click the Add button and then enter an IPv4 address, an IPv4 address range, or an IPv4 subnet with network ID and subnet mask.

http://www.isaserver.org/img/upl/image0221295557585963.png
Figure 22
If you select URL Set, you’ll see the New URL Set Rule Element dialog box that’s shown in Figure 23. Here you enter a name for the URL, and then click the Add button to add URLs to the set. Note that you can use wildcards when defining a URL in the set.

http://www.isaserver.org/img/upl/image0231295557585963.png
Figure 23
If you click Domain Name Set, you’ll see the New Domain Name Set Policy Element dialog box that’s shown in Figure 24. Here enter a name for the set and then click the Add button to add domain names. Once again, you can use wildcards for the high-level name in the domain.

http://www.isaserver.org/img/upl/image0241295557585978.png
Figure 24
Summary

In this article, we walked through a high level overview of Network Objects and how they are defined in the TMG firewall console. Some of the Network Objects have default values that are included right out of the box, while others require that you configure existing objects or create your own. We finished up by showing how you create a subset of Network Objects. In the second part of this article, we’ll go over how you create some of the more complex Network Objects and how to run the wizards to create these more complex network objects.

[alika]

In the first part of this two part series on TMG Firewall Network Objects, we went over the different Network Objects and what they represent. We also saw how you can create simple new Network Objects.
Don’t let that word scare you. Here’s the good news: Each of the “complex” Network Objects can be created by using a wizard. Wizards are available to create the following types of Network Objects:

Network
Network Sets
URL Category Sets
Web Listener
Server Farm
Let’s take a look at the information that you’ll need to know in order to create each of these.
The New Network Wizard

You can begin the process of creating a new Network by clicking on the Network entry in the New menu. Remember that in TMG Firewall nomenclature, a Network represents a collection of IP addresses that are directly reachable from a particular interface on the TMG firewall.
The first thing you’ll see is the Welcome to the New Network Wizard page. On this page, you enter a name for the Network in the Network name text box. In this example, we’ll name the Network DMZ 2, as shown in Figure 1.

http://www.isaserver.org/img/upl/image0011296504839734.png
Figure 1
On the Network Type page, which you can see in Figure 2, you are given several different Network types to choose from:

Internal Network. This is typically a Network that contains servers or clients that you want to be protected by the TMG firewall. When you create an Internal Network, the Properties dialog box of the Network will have all the options you see in the default Internal Network.
Perimeter Network. A Perimeter Network is similar to an Internal Network. In fact, there is no practical difference between a Perimeter Network and an Internal Network – both provide the same options in their Properties dialog boxes. However, for accounting purposes, you will want to choose the Perimeter Network option to make it clear that this is a DMZ network, and not an Internal Network. The key difference here is that DMZ Networks typically will include Internet facing devices.
VPN Site-To-Site Network. This is a special Network type that is used when you want to create a site to site VPN connection between your TMG firewall and another firewall. Note that while you can create the remote site Network from this wizard, you would more typically do it from within the wizard that is used to create the site to site VPN.
External Network. An External Network is considered an unprotected Network and represents a collection of IP addresses that reside outside of any of the TMG Firewall Protected Networks. You would create an External Network if you want to add additional external interfaces on the TMG firewall and then create routing table entries for specific destinations that can be reached through the NIC that form the root of the External Network you created.
In this example, we’ll select the Perimeter Network option.

http://www.isaserver.org/img/upl/image0021296504839750.png
Figure 2
On the Network Addresses page, which is shown in Figure 3, you configure the addresses that define the Network. You can add the addresses in three different ways: by adding an adapter, by adding a private address range, or by adding a custom address range. We’ve found that in most cases, the best way to create a new Network is to base it on a specific NIC. In this example, we’ll click the Add Adapter button. That brings up the Select Network Adapters dialog box. In this dialog box, you need to put a checkmark in the checkbox next to the NIC that is the root of your new Network.

http://www.isaserver.org/img/upl/image0031296504839750.png
Figure 3
Once you’ve done all this, you can then review the settings of the new TMG Firewall Network on the Completing the New Network Wizard page, which you see in Figure 4. (Note that the IP addresses are different because I already used the Guest Network for another TMG Firewall Network).

http://www.isaserver.org/img/upl/image0041296504839750.png
Figure 4
You can then go to the Networking node in the left pane of the console and double click the new Network. There you’ll see the Properties dialog box that’s shown in Figure 5. Notice that this Perimeter Network’s Properties dialog box is the same as what you would find if you had created an Internal Network.

http://www.isaserver.org/img/upl/image0051296504988421.png
Figure 5
The New Network Set Wizard

advertisement


Next, we’re going to find out how to create a new Network Set. A Network Set is just a collection of TMG Firewall Networks that you can use in your Access Rules and Publishing Rules. When you click Network Set from the New menu, you’ll see the Welcome to the New Network Set Wizard that’s shown in Figure 6. On this page, enter a name for the new Network Set. In this example, we’ll name the new Network Set Secure Networks.

http://www.isaserver.org/img/upl/image0061296504988421.png
Figure 6
On the Network Selection page, which is shown in Figure 7, you have two options: Includes all selected networks and Includes all networks except the selected networks. After making the selection that works best for your purposes, depending on the number of networks you have and the number you want to include in the set, put a checkmark in the checkboxes that are next to the Networks that you want to participate in your Network Set (or not participate, depending on the option you selected above the list of Networks).

http://www.isaserver.org/img/upl/image0071296504988421.png
Figure 7
Okay, we’re all done! Click Finish on the Completing the New Network Set Wizard page that’s shown in Figure 8.

http://www.isaserver.org/img/upl/image0081296504988421.png
Figure 8
Success! You should now be able to see the new Network Set in the Network Sets section of the Network Objects, as shown in Figure 9.

http://www.isaserver.org/img/upl/image0091296505138375.png
Figure 9
The URL Category Set

A URL Category Set is a collection of URL categories that are used for filtering (examples of URL categories include alcohol, gambling, and pornography). There are a number of built-in URL Category Sets (for example, the Liability Category Set includes the above categories, among others). However, the built in Sets may not precisely fit your needs. That’s okay, because the URL Category Set Wizard also enables you to create your own custom URL Category Sets. From the New menu, click URL Category Set. This brings up the Welcome to the New URL Category Set Wizard page that’s shown in Figure 10. Enter a name for the new URL Category Set on this page. In this example, we’ll name the new URL Category Set Temp Employees, with the intended purpose being to use this Category Set to define a rule later which will control which sites temporary employees can visit.

http://www.isaserver.org/img/upl/image0101296505138375.png
Figure 10
On the URL Category Selection page, shown in Figure 11, you have two options similar to what we saw with Network Sets: Includes all selected URL categories and Includes all URL categories except the selected URL categories. After making the selection that best fits your purposes, put a checkmark in the checkbox next to the categories you want to include (or exclude, depending on the option you’ve selected).

http://www.isaserver.org/img/upl/image0111296505138375.png
Figure 11
Review your selections on the Completing the New URL Category Set Wizard page that you see in Figure 12. Note that you can scroll to the right to see the full list of the URL Categories you included in the URL Category Set. Then click Finish.

http://www.isaserver.org/img/upl/image0121296505138375.png
Figure 12
Now the new URL Category Set appears in the list of URL Category Sets and can be used in an Access Rule to control which sites temporary employees are allowed to access.

http://www.isaserver.org/img/upl/image0131296505292421.png
Figure 13
The New Web Listener Wizard

As you probably already know, a Web Listener is a software component that is used by Web Publishing Rules. The Web Listener accepts incoming connection requests for published Web servers. Web Listeners define the authentication methods that can be used by the TMG firewall to authenticate users before the connections are allowed to the published Web server. This is often referred to as “pre-authentication”. There are many security advantages to pre-authentication and if your site requires authentication, you should always take advantage of this option.
Typically, you will create new Web Listeners when you’re publishing a web site, using the Web Publishing Wizard. However, if you want to create a Web Listener outside of the Web Publishing Wizard, you can do it here. On the New menu, click the Web Listener option. This brings up the Welcome to the New Web Listener Wizard page that’s shown in Figure 14. Enter a name for the Web Listener here. In this example, we’ll name the Web Listener HTTP Listener, with the intent that this Web Listener will be used for accepting incoming connections to unencrypted web content that will not require authentication.

http://www.isaserver.org/img/upl/image0141296505292421.png
Figure 14
On the Client Connection Security page, shown in Figure 15, you will need to define whether or not the external client will be required to establish an SSL connection with the TMG firewall before the firewall forwards connections to the published Web server. You have two options, and they’re pretty self-explanatory:

Require SSL secured connections with clients
Do not require SSL secured connection with clients
Note the warning message; if you used HTTP, you should not require authentication to the TMG firewall, since the credentials will move over the Internet in the clear and could easily be picked up by intruders.

http://www.isaserver.org/img/upl/image0151296505292421.png
Figure 15
On the Web Listener IP Addresses page that you can see in Figure 16, you select the Network on which the Web Listener should be listening for incoming connections. In most cases, you’ll want the Web Listener to listen for incoming connections from the default External Network, so we’ll select External in this example. If you select this option, the Web Listener will listen for incoming connections on all IP addresses that are bound to the external interface of the TMG firewall. In general, you don’t want to do that; instead, you want the Web Listener to accept connections on specific IP addresses so that you can create multiple Web Listeners with different characteristics that support different authentication and encryption scenarios. To select a specific IP address, click the Select IP Addresses button. That brings up the External Network Listener IP Selection dialog box. From there, you can select the Specified IP addresses on the Forefront TMG computer in the selected network option and then choose the IP address on which you want the Web Listener to listen.

http://www.isaserver.org/img/upl/image0161296505292437.png
Figure 16
On the Authentication Settings page, which is shown in Figure 17, you set the type of authentication you want this Web Listener to support. You have three options:

HTTP Authentication
HTML Form Authentication
No Authentication
Depending on the selection you make from the drop down box, you will have different authentication methods available to you. For example, if you select Network Object Authentication, then no authentication methods will be available to you. If you select HTML Form Authentication you’ll have all the authentication methods available to you. However, you should never enable authentication at the TMG firewall if you’re not using SSL, and that is especially the case with HTML Form Authentication, since the credentials are based in clear text and not even encoded as they are with Basic authentication (not that it makes much practical difference, since most network analyzers are going to automatically do the decode). The point is this: if authentication at the TMG firewall is required, the connections to the firewall should be an SSL connection. In fact, if you try to enable unencrypted connections to the TMG firewall, you’ll receive a warning.
All of this reminds me that I should emphasize to you that these authentication methods are for the external user to authenticate to the TMG firewall itself, as part of the pre-authentication process. The TMG firewall can also perform authentication delegation, where the credentials the firewall received can be forwarded to the published server after the TMG firewall has successfully authenticated the user. This prevents the user from having to present credentials a second time (to the published server itself).

http://www.isaserver.org/img/upl/image0171296505446453.png
Figure 17
In this example, we’ll select No Authentication. Notice in Figure 18 how all the options become grayed out when we select this option.

http://www.isaserver.org/img/upl/image0181296505446468.png
Figure 18
On the Single Sign On Settings page, which is shown in Figure 19, you can configure the Web Listener to support Single Sign On. Since the user isn’t going to authenticate with the TMG firewall when using this Web Listener that we’ve created in this example, there is no reason to enable SSO because there is no sign on in the first place :)

http://www.isaserver.org/img/upl/image0191296505446468.png
Figure 19
On the RADIUS Servers page, shown in Figure 20, you add the RADIUS servers you want to use if you choose to use RADIUS based authentication for the Web Listener. However, since we chose to not support authentication with this Web Listener, there’s no reason that we should even see this page. I suspect this might be a minor bug in the Web Listener wizard – but not enough of a bug to fix since you can just click past it. In this case, we’ll do just that: click past this page since there’s no reason to define a RADIUS server if you’re not using authentication for the Web Listener.

http://www.isaserver.org/img/upl/image0201296505446468.png
Figure 20
On the Completing the New Web Listener Wizard page, shown in Figure 21, you can review your settings and then click Finish.

http://www.isaserver.org/img/upl/image0211296505586187.png
Figure 21
When you’re done, you’ll see the new Web Listener in the Web Listeners list, as shown in Figure 22.

http://www.isaserver.org/img/upl/image0221296505586187.png
Figure 22
The New Server Farm Wizard

You can use the TMG firewall to publish a web farm. A Web Farm is typically a collection of Web servers that host the same content or services and the farm is used for high availability and fault tolerance. When you publish a Web Farm using the TMG firewall, you don’t need to use NLB or an external hardware load balancer to publish the Web Farm. The TMG firewall will handle connection assessment and automatically load balance connections to the published Web servers, and it will also remove downed Web servers when the TMG firewall determines that a member of the Web Farm is offline.
On the Welcome to the New Server Farm Wizard page, shown in Figure 23, you enter a name for the Web Farm. In this example, we have named the Web Farm CAS TAC.

http://www.isaserver.org/img/upl/image0231296505586203.png
Figure 23
On the Servers page, which is shown in Figure 24, you can click the Add button and enter the name or IP address of a member of the Web Farm in the Server Details dialog box. You can add as many servers to the farm as you like; there are no hard coded limits.

http://www.isaserver.org/img/upl/image0241296505586203.png
Figure 24
You can see the list of IP address or names of the servers in the Web Farm in the list of Servers included in this farm on the page shown in Figure 25.

http://www.isaserver.org/img/upl/image0251296505788843.png
Figure 25
The TMG firewall needs to test all members of the farm to make sure they’re online. If it detects that a member of the farm is offline, it will remove that server from the list of servers among which it will load balance connections. On the Server Farm Connectivity Monitoring page, which is shown in Figure 26, you can choose the method used to confirm connectivity. Your three options are: Send an HTTP/HTTPS GET request, Send a PING request and Establish a TCP connection. If you choose the Establish a TCP connection, you need to enter a TCP port number for the port on which you want to establish the socket.
Note that if you choose PING or TCP connections, this only tells the TMG firewall that the server can respond to a PING request or establish a TCP socket with the TMG firewall. However, it doesn’t really tell the TMG firewall anything about the viability of the published service. If you want to know more about service viability, you should select the Send HTTP/HTTPS Get request option. If the servers in the farm need a specific host header, you can click the Configure button to set that header.

http://www.isaserver.org/img/upl/image0261296505788859.png
Figure 26
You can review the settings on the Completing the New Server Farm Wizard page, as shown in Figure 27, and then click Finish.

http://www.isaserver.org/img/upl/image0271296505788859.png
Figure 27
After you click Finish, you’ll see an informational dialog box like the one shown in Figure 28, which informs you about connectivity verifiers and asks if you want to automatically configure System Policy to support the connectivity verifiers. You should click Yes so that the connectivity verifiers will work correctly.

http://www.isaserver.org/img/upl/image0281296505841781.png
Figure 28
The new Server Farm now appears in the Server Farms list, as shown in Figure 29.
http://www.isaserver.org/img/upl/image0291296505841781.png
Figure 29

Summary

In this article, which is part 2 in of our two-part discussion of Network Objects, we went over the more complex Network Objects and the Wizards that are used to create these Network Objects. As with the simple Network Objects, these complex Network Objects can be used in Access Rules and Publishing Rules to define sources or destinations. I hope you learned something useful from this article, and if you have any question about Network Objects and how to use or create them, let me know! Thanks! -Deb.