Another Look at Server Publishing in ISA Server 2006

Author:

Thomas Detzner, Escalation Engineer, Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Lior Alon, Senior Development Lead, Microsoft TMG Forefront Security Edge Team

Yuri Diogenes, Security Support Engineer, Microsoft CSS Forefront Edge Team

Jim Harrison, Program Manager, Microsoft CSS Forefront CS Team

In the last few months I encountered several customers who had questions about server publishing using ISA Server and we found out that because there are many myths on this subject that it would be time to shed some light on some behaviors of ISA Server.

Scenario 1 - Simple Publishing Rule

Let’s start with a simple scenario (as shown in Figure 1), ISA Server has two interfaces and publishes an internal DNS Server:

Figure 1 - Simple Scenario

There is already a very good article about troubleshooting such a scenario out there and I just want to briefly highlight some additional tools you can use here. One tool that is a must-have for checking server publishing listeners is FWENGMON. The reason this tool is required is explained in Microsoft knowledgebase article 838127.

All you need to do to make this work is to create a Server Publishing rule for the DNS Server protocol from the External network to the published DNS Server on 192.168.174.253:

Figure 2 - Simple Publishing Rule

With the default network rules as shown in Figure 3:

Figure 3 - Network Rules

After you apply the configuration changes you will see the listener created using the command fwengmon /c as shown in Figure 4:

Figure 4 - Using FWEngmon to review the publishing rule

What fwengmon is telling us is that ISA Server created a UDP and TCP listeners on 84.154.75.57 port 53 which accept traffic from 0.0.0.0. An IP address of 0.0.0.0 means “any possible IP address”. (INADDR_ANY). The output is somewhat similar to what you would see using netstat command as shown in Figure 5:

Figure 5 - Netstat command result

Scenario 2 - Complex Publishing Rule

In the next example we dive into a bit more complex scenario. In this scenario the ISA Server has 4 NIC’s and is connected a number of Networks. In addition to this it hosts a publishing rule for a DNS Server in the DMZ that shall be accessed from internal Clients as you can see in Figure 6:

Figure 6 - Complex network topology

The goal in this scenario is to publish the DNS Server in the Network DMZ at IP Address 10.110.0.253 for the clients on the Network ClientNet2. The clients in this network shall also have no direct connection to the network DMZ and shall use the ISA Servers IP Address 192.168.174.101 instead.

When you look at this you may say – well this is an easy task to do, just configure an Access rule on ISA and you are all set. However the 2nd requirement of this task was that the clients shall always use the IP Address 192.168.174.101. This is not possible with an Access rule since in an access rule scenario the client needs to specify the real destination IP Address which would be in10.110.0.253 in this case. So we need to publish the network DMZ. You may say – easy task as well, but as usually the problems come with the details.

The networks had been created as follows:

The network rule had been defined as shown in Figure 7:

Figure 7 - Network rules for this scenario

The Publishing rule is defined as shown in Figure 8:

Figure 8 - Publishing rule for this scenario

For now I’d say all is properly defined and looks like it should work with no issues. If we check the creation objects with our lovely fwengmon tool, we will see an output similar to Figure 9:

Figure 9 - FWengmon result

As you can see there is no listener on any IP address at all for port 53. What happened? Fortunately ISA Server will give us a hint in the event log as shown in Figure 10:

Figure 10 - Event id 21174

The event complains that there is no network relationship between the networks, but we did create one! Now I changed the source and Destination network in the rule as shown Figure 11:

Figure 11 - New network rules

After applying the changes and again use fwengmon to review the listener creation will show that the result was different as shown in Figure 12:

Figure 12 - New fweng result

In addition to this ISA is also telling us that it likes this configuration a lot better using event 1461 as shown in Figure 13:

Figure 13 - Event that acknowledges that the issue was resolved

From the event you can also see that the mapping between 10.110.0.253 -> 192.168.174.101 exists. The reason for this is we have defined the publishing rule with the Protocol DNS Server as shown in Figure 14:

Figure 14 - DNS Publishing rule

The DNS Server protocol definition defines the parameters showed in Figure 15:

Figure 15 - DNS Server Protocol

So this means that the traffic is supposed originate in the “destination” network of a NAT relationship.

Now there is also an option that you can configure a Publishing rule when the networks have a Route relationship. This works and is fully supported. The only thing you need to know here is that inbound protocols are only supported for publishing rules. For example if you want to take advantage of the SMTP application filter which is attached only to the ‘SMTP Server’ protocol, using an access rule will not work. An SMTP access rule will not use the SMTP application filter.

Clients who want to access the published server when the network relationship is ROUTE need to specify the published Server IP Address as the destination because the rule in this case acts in a similar fashion to an Access rule – with the difference of the Protocols used – outbound for an access rule and inbound for a publishing rule. Let’s see this in detail:

First we changed the network rule to have a ROUTE relationship as shown in Figure 16:

Figure 16 - Network relationship

After applying the configuration, fwengmon was used again to verify the listener creations and the ISA server now listens on the destination IP Address as shown in Figure 17:

Figure 17 - Result of fwengmon

If you think about it, this actually makes sense. In a classical publishing scenario this is how we designed it as well:

• The published server lives on the default internal network

• The listener is on the default external network

• The network rule is defined as source == internal network, destination == external network

So to make this more abstract we can conclude the following:

• Where a NAT network relationship is defined so that A is the source network and B is the destination network:

  • A host in network A can initiate traffic to a host in network B only through an access rule and a host in network B can reach the host in network A in response to the traffic for the matching access rule

  • A host in network B can initiate traffic to a host in network A only through a server publishing rule

• Where a Route network relationship is defined between A →B (source and destination are unimportant for route relationships), A or B can initiate traffic to the opposite network through access or server publishing rules

When ISA creates the publishing listeners determines which listeners need to be created (route listeners or NAT listeners). In order to do this ISA iterates over the addresses in the 'from' tab of the publishing rule and performs the following:

• For each address 'a' in the 'from' tab it checks the network relationship between the published server and address 'a'. It creates listeners accordingly (NAT/route)

• If no network relationship exists ISA doesn't create any listener and indicates an alert (see Event ID 21174)

Conclusion

In this article I walked you through multiple scenarios for server publishing with ISA Server and I hope you have now a better understanding on how ISA server works. The key take away here is that the source and destination network selection for the relevant network rule is critical as ISA will use this information when it decides how to create the listeners. Whenever you are in doubt try to simplify your network as much as possible and make sure you understand where the traffic originates and what direction the rule is supposed to handle.