|
A lot of questions we answer on these boards pertain to issues related to the configuring or troubleshooting the SecureNAT client. However, we often take it for granted that the poster understands what the SecureNAT is, what it does, and how it works. While the SecureNAT client seems relatively simple in concept, it does have some “gotcha’s” and limitations of which everyone here should be aware. The SecureNAT client is one of the three ISA Server client types. The three ISA Server client types include:
|
Configuring ISA Server 2000 : Building Firewalls for Windows 2000
By Deb and Tom Shinder |
|
Keep in mind that a single computer can be configured as all three types of client. Each client type provides a level of functionality that other client types do not. Therefore, if you want to take advantage of all Internet access features provided by ISA Server, you might want to configure a machine as all three client types. The ISA Server NAT Protocol Driver The ISA Server Network Address Translation Protocol driver builds on the features provided with the Windows 2000 RRAS NAT driver. However, these services are not complementary! If you are currently running the Windows 2000 NAT Routing Protocol, you should delete the NAT Routing Protocol, using the RRAS console. If you attempt to run both the ISA Server NAT and the RRAS NAT you may still have connectivity, but you will run into interruptions and “unusual” behavior for clients attempting to access the Internet. ISA Server NAT provides transparent proxy services for your network clients. SecureNAT clients do not require you to install extra software on the SecureNAT client. Only a functional TCP/IP protocol stack is required. All operating systems connecting to the network via TCP/IP can be configured as SecureNAT clients. Therefore, if you have a mix of UNIX, Macs, Windows and other operating systems that need access to the Internet, then the SecureNAT client may be your best solution. Creating A SecureNAT Client You make a machine a SecureNAT client when you point its default gateway to an interface that routes Internet bound requests to the internal interface of the ISA Server. The default gateway is the IP address of the internal interface of the ISA Server if the client is on the same network ID as the internal interface of the ISA Server. If you have a routed network, and the SecureNAT client is remote from the internal interface of the ISA Server, then you make the default gateway a router interface that provides the shortest route to the internal interface of the ISA Server. After changing the default gateway settings, you may or may not need to restart the computer. This depends on the operating system used by the SecureNAT client. For example, if the client is a Windows 2000 machine, you do not need to restart the computer. Any other Windows-based client needs to be restarted. SecureNAT Network Configurations There are two types of networks on which you’ll deploy a SecureNAT client:
SecureNAT Clients on Simple Networks A “Simple Network” is one that has a single internal network segment and logical network ID. The SecureNAT clients are all located on the same network ID as the internal interface of the ISA Server. You configure the SecureNAT client to use the internal interface of the ISA Server as its default gateway. The figure below shows my poor attempt at depicting this type of setup J.
Configuring the SecureNAT Client on a Simple Network You can configure the SecureNAT client the easy way or the hard way. The hard way is to go to each machine and manually configure the TCP/IP settings. The easy way is to configure a DHCP Server to deliver the Default Gateway address to the client automatically. Watch Out for Other NAT Solutions! If you’re installing ISA Server on a simple network, watch out for the presence of other Internet connection sharing methods that might have already been deployed. These include applications or services like Internet Connection Services (ICS), Sygate, and the RRAS NAT. These applications may have provided IP addressing to their clients via their own DHCP Allocator or allocation mechanism. When ISA Server is installed on the same computer, it will disable ICS and the RRAS NAT. This includes the DHCP Allocator functionality. If the network needs DHCP functionality, then you need to install a separate DHCP server. Host Name Resolution and DNS One of the more problematic issues on these small networks is host name resolution for SecureNAT clients. The ISA Server will not resolve host names on the behalf of SecureNAT clients. Unlike Web Proxy and Firewall Clients, you must configure the SecureNAT client with the address of a DNS server. Typically, Simple Networks will not have a dedicated DNS Server and in most cases you will not need one. If the Simple Network is running a Windows 2000 domain, then you will need to have a DNS server in place to support domain activity. The Windows 2000 Domain Controller can host a DNS Server that is configured to use a Forwarder. The Forwarder is a public DNS server located on the Internet (typically your ISPs DNS Server). After the internal DNS server is configured to use a Forwarder, the SecureNAT clients can be configured to query the internal DNS Server to resolve Internet names. An even better solution is to configure the internal DNS Server to use a caching-only forwarder that is also located on a DMZ segment. You would then configure the Caching-only DNS Server to use a Forwarder on the Internet (such as your ISPs DNS server). In this way, you can quickly build up the DNS cache and speed up DNS lookups on your network. If you do not have an internal DNS server, then you need to configure the SecureNAT clients to use an external DNS Server. This will likely be your ISPs DNS Server. The DNS server address can be configured on the SecureNAT clients manually, or you can have a DHCP server assign DNS server address(es). Whether you install a DNS Server on your internal network, or configure your SecureNAT clients to use a DNS Server on the Internet, there must be a Protocol Rule allowing SecureNAT clients to make DNS queries to external DNS servers. To do this, you can use the DNS Query Protocol Definition in the Protocol Rule. This will work with most of your SecureNAT clients. The exception is when you have an internal IIS SMTP server (such as Exchange 2000). In this case, you must create a Protocol Definition for TCP 53 Outbound and add that Protocol Definition to our DNS Access Protocol Rule. What About SecureNAT Clients on “Not Simple” Networks? I considered calling the “Not Simple” network a “Complex” network. However, an internal network with just two or three network IDs really isn’t that complex. These are routed networks. Therefore, at least some of the SecureNAT clients are going to be separated from the internal interface of the ISA Server by a router. The figure below shows my second dismal attempt at artwork, which depicts a routed network J.
Make sure the routers which separate SecureNAT clients from the ISA Server’s internal interface are configured to route Internet bound packets to the internal interface of the ISA Server. Using DHCP in a Routed Network If you assign addressing information to your SecureNAT clients via DHCP, the routed environment will present special challenges. If you plan to use DHCP to assign addressing information to the SecureNAT clients, here are some options:
If you implement a single DHCP Server, you will have to configure multiple scopes to service all network IDs that have DHCP clients. You can place multiple network cards on the DHCP Server, each with an IP address bound to it that can listen for DHCP requests from each network ID. This isn’t the best solution, because it requires you to add unnecessary hardware. A better solution is to configure a superscope that includes all the scopes configured on the DHCP Server. Check out TechNet on how to configure DHCP superscopes if you haven’t already done this before. If you have problems with this, please ask us on the message boards! DNS server placement is less problematic because DNS messages are not broadcasts. However, you need to take into account zone transfer traffic. If you use Active Directory integrated DNS zones, you will have to take into account the Active Directory replication topology. Limitations of the SecureNAT Client The SecureNAT client is your only solution for non-Windows clients that need access to protocols other than “Web Protocols” (HTTP, HTTPS, FTP and Gopher). However, there are some issues with the SecureNAT client that can bite you if you’re not aware of them:
Access Limited to Protocol included in the ISA Server’s Protocol Definitions The SecureNAT client depends on existing protocol definitions to access Internet applications on remote hosts. This creates a problem if you would like to have wide open outbound Internet access for your internal clients. For example, many of you have implemented the “all open” configuration recommended in the “Getting Started Guide” on this site. After opening all the Protocols and Ports, you may still find that your SecureNAT clients can’t access everything you want them to on the Internet. The problem is that SecureNAT clients treat “all IP traffic” as “all IP traffic as defined in the Protocol Definitions”. SecureNAT Clients require Application Filters for Complex Protocols If you are working with complex protocols that require opening “back channels” or contained directives in the data portion of the packet, you will need Application Filters to help support SecureNAT clients. A good example of this is Napster. Although Napster is on the way out, it provides an example of a application that requires the SOCKS application filter if you wish to use it with the SecureNAT client. SecureNAT Clients do not Support User Based Authentication The SecureNAT client is not able to send user credentials to the ISA Server. If you need secure outbound access control, and if you require username information in your ISA Server logs, you will not get that information from SecureNAT clients. For example, you might want to prevent Internet access to a Windows 2000 or Windows NT 4.0 group called “Temps”. The SecureNAT client cannot support access control based on group membership because it does not send credentials to the ISA Server. This includes SecureNAT client requests for HTTP and FTP resources that go through the HTTP Redirector Filter. Note that if your machine is configured as both a SecureNAT and Web Proxy client, or a SecureNAT and Firewall client, the Web Proxy and Firewall client components are able to send credentials to the ISA Server. The SecureNAT client configuration does not prevent the other components from sending credentials. Outbound PPTP Access Something worth mentioning at this point, since I was just talking about security problems, is an issue with outbound PPTP. A machine must be configured as a SecureNAT client in order to make outbound PPTP calls. Why? Because the Firewall Clients only support TCP and UDP based protocols. PPTP also requires Protocol ID 47 (Generic Routing Encapsulation or GRE). Note: This also explains why a machine must be a SecureNAT client in order to use ICMP to ping machines on the external network. Because PPTP depends on the SecureNAT configuration, you cannot control outbound access for PPTP clients on the internal network. Outbound PPTP is allowed by a packet filter and packet filters do not support client address sets or user credentials. Neither packet filters or SecureNAT clients support authentication. When you think about this, you’ll realize that allowing outbound PPTP can present a tremendous security risk to your network. Have you security team chew on the possibe repercussions of allowing outbound PPTP connections before allowing them. Note: ISA Server does not support outbound calls using IPSec. The Authentication Header Protocol (AH) does not support changes to the packet headers made by network address translation. Outbound Access Control for SecureNAT Clients So how do you control outbound access for SecureNAT clients? It’s a bit like how you did it with your SOCKS clients in Proxy Server 2.0. You control access based on client IP address. To make things a little easier, you can create Client Address Sets and put your IP addresses into administrative groups. If you plan on using Client Address Sets to control access, you should consider how IP addresses are assigned on your internal network and plan accordingly to support your use of Client Address Sets. Manual Configuration of the SecureNAT Client Configuring the SecureNAT client is easy. Just configure the appropriate Default Gateway. On a Windows 2000 client, you perform the following steps:
That’s it! You may need to restart the computer depending on the client operating system. To test the configuration, open your browser and type in an URL. Or can ping your least favorite Internet host J If you entered the correct IP address for your default gateway, you will be able to retrieve your web page and receive echo replies. Be aware that if you want to ping an external client the ISA Server must be configured to allow IP Routing. If IP Routing is not enabled, ping requests fail. While the SecureNAT client does support pinging external web sites, the client must be able to resolve host names if you ping by name. Configuring the SecureNAT Client via DHCP To configure a SecureNAT client via DHCP, perform these steps: 1. Install a DHCP Server on your network that is accessible to your SecureNAT client computer either through broadcast or relay
4. Restart the DHCP Server service, and either restart the DHCP/SecureNAT client, or issue the ipconfig /renew command, depending on the client operating system. Summary The SecureNAT client is ideal for operating systems that do not support the Firewall client. SecureNAT clients are able to transparently access resources on the Internet without the need for additional software installation or configuration. The only requirement is that the SecureNAT client be configured with a default gateway that routes Internet bound requests to the internal interface of the ISA Server. While the SecureNAT client configuration is easy to set up, it does have some disadvantages. These include its inability to send credentials to the ISA Server and the requirement that you configure the machine with a DNS server address that can resolve Internet host names. We discussed some of the ways you can work with or get around these issues. I hope you enjoyed this article and that you learned something helpful. If you have specific questions about what was discussed here, please take a moment and post to the message boards on this site, or send me an email with the title of the article in the subject line at [email protected]. –Tom. |
|
