The SecureNAT (SecureNET) Client Guide to the Universe

A SecureNAT client is any device configured with a default gateway address that can route Internet-bound connections through the ISA 2004 firewall. That is, the ISA firewall’s role is closely related to the role of a router for outbound access. The SecureNAT client does not have a traditional client/server relationship with the ISA Server. There are three network scenarios in which the SecureNAT client is most commonly found:    



  • Simple
  • Complex
  • VPN client






Discuss this article



A simple network scenario is one that has only a single subnet located behind the ISA firewall. For example, you have an ISA firewall sitting at the edge of the network with an interface directly connected to the Internet and a second interface connected to the Internal network. All the machines behind the ISA firewall are on a single subnet (for example, 10.0.0.0/8). There are no routers on the Internal network. Figure 1 depicts a typical simple network scenario.



Figure 1: SecureNAT Simple Network Scenario


In the simple network scenario, the default gateway of the SecureNAT client is configured as the IP address of the internal interface of the ISA firewall. You can manually configure the default gateway address, or you can use DHCP to automatically assign addresses to the SecureNAT clients. The DHCP server can be on the ISA 2004 firewall itself, or it can be located on a separate machine on the Internal network.


In the complex network scenario, the default Internal network consists of multiple network IDs that are managed by a LAN router or series of routers or layer 3 switch(es). In the case of the complex network, the default gateway address assigned to each SecureNAT client depends on the location of the SecureNAT client computer. The gateway address for the SecureNAT client will be a router that allows the SecureNAT client access to other networks within the organization, as well as the Internet. The routing infrastructure must be configured to support the SecureNAT client so that Internet-bound requests are forwarded to the internal interface of the ISA firewall. Figure 2 depicts the SecureNAT complex network scenario.



Figure 2: SecureNAT Complex Network Scenario


The VPN client scenario applies to machines that have created a VPN connection with the ISA firewall.


With ISA 2000, when a VPN client computer established a connection with the VPN server, the VPN client’s routing table is changed so that the default gateway is an address on the VPN server.  Unless changes are made to the default client configuration, the client will not be able to connect to resources on the Internet while connected to the ISA 2000 VPN server. 


It was possible to configure the ISA 2000 VPN client as a Firewall or Web Proxy client and allow the VPN client access to the Internet through the ISA 2000 firewall. Alternatively, the ISA 2000 VPN client could be configured to allow split tunneling. However, given the profoundly negative results of allowing split tunneling, not allowing it is always the recommended configuration.


In contrast to ISA 2000, the ISA 2004/06 VPN server does not require you to configure the VPN clients to be Firewall or Web Proxy clients in order to access the Internet through the same ISA VPN server to which they connect. Because the VPN clients are not configured as Web Proxy or Firewall clients, they are de facto SecureNAT clients. This allows VPN users to access the corporate network via the VPN connection, while at the same time allowing them to access the Internet via their connection to the ISA firewall. This removes the risks inherent in split tunneling.


Note that you do not need to have a deep understanding of VPN client routing table configuration or how different versions of the Windows VPN client handle default route assignments. Just remember that when a VPN client creates a VPN connection with the ISA 2004 firewall/VPN server, that client will be able to connect to the Internet via the ISA 2004 firewall based on access rules that you configure.


WARNING:
Split tunneling represents a significant security risk and should never be enabled on your VPN clients. ISA 2004/06 supports VPN client SecureNAT connections to the Internet through the same ISA 2004/06 firewall to which they connect. This obviates the need for split tunneling. In addition, the ISA 2004/06 firewall enhances the SecureNAT client support for VPN clients by enabling user/group-based access controls for VPN clients.


SecureNAT Client Disadvantages


While the SecureNAT client is the simplest ISA 2004/06 client type to configure, they are also the least capable and the least secure of the three ISA 2004/06 client types. Limitations of the SecureNAT client include:



  • Inability to authenticate with the firewall for strong user/group-based access control
  • Inability to take advantage of complex protocols without the aid of an application filter (NAT editor)
  • Dependency on the routing infrastructure to access the Internet
  • Requirement for a Protocol Definition to be configured on the ISA firewall to support connections made through the ISA firewall

SecureNAT clients do not send credentials to the ISA firewall because, in order for credentials to be sent to the firewall, there must be a client software component configured to send them. The basic TCP/IP protocol stack up to layer 3 (DoD model) does not provide for user authentication and requires an application component to send user credentials.


The Firewall and Web Proxy clients can send user credentials, but the SecureNAT client cannot. The Firewall client uses the Firewall client software to send user credentials, and Web browsers configured to use the ISA firewall as a Web Proxy have the built-in capability to send user credentials. You cannot use strong user/group-based outbound access controls for machines configured only as SecureNAT clients.


SecureNAT clients cannot connect to the Internet (or any other location through the ISA firewall) using complex protocols without the aid of an application filter installed on the ISA firewall. A complex protocol is one that requires multiple primary or secondary connections. A classic case of a complex protocol would be FTP standard (Port) mode connections.


When the standard (or Port) mode FTP client establishes a connection to the FTP server, the initial connection (the control channel) is established on TCP port 21. The FTP client and server then negotiate a port number on which the FTP client can receive the data (the file to download), and the FTP server returns the data from its own TCP port 20 to the negotiated port. This inbound connection is a new primary connection request and does not represent a response to the primary outbound connection made by the FTP client when it established the control channel session.


The firewall must be aware of the communications going on between the FTP standard mode client and the FTP server so that the correct ports are available for the new inbound connection request to the ISA firewall. This is accomplished on ISA firewalls via the intelligent FTP Access Application Filter. Figure 3 depicts the FTP standard mode client and server communications.



Figure 3: FTP Standard Mode Client/Server Communciations


This SecureNAT limitation regarding complex protocols is especially problematic when it comes to Internet games and voice/video applications. These applications typically require multiple inbound and outbound primary connections. The SecureNAT client will not be able to use these applications unless there are specific application filters on the firewall to support them. In contrast, the Firewall client is easily able to handle applications requiring multiple inbound and outbound primary connections without installing anything extra on the firewall.


Of course, there’s an exception to every rule, and here’s the exception to the statement above: Complex protocol support for SecureNAT clients is possible if the application installed on the SecureNAT client is designed to work with a SOCKS proxy. In this case, the application is explicitly configured to communicate with the ISA firewall’s SOCKS 4 application filter. The SOCKS 4 application filter can manage the connections on behalf of the SecureNAT client machine’s application.


WARNING:
Although SecureNAT clients running SOCKS 4 applications might be able to support complex protocols for the application configured to use the SOCKS proxy, the SOCKS proxy will not enable the client to benefit from user/group authentication. The SOCKS 4 proxy application filter on the ISA 2004 firewall does not accept user credentials that would enable user/group-based access control. However, if you require user authentication for SOCKS clients, you might want to consider Cornerpost Software’s Surrogate Socket 5.0 application.


The SecureNAT client is dependent on the organization’s routing infrastructure. Unlike the Firewall and Web Proxy clients, which send their Internet connection requests directly to the ISA 2004 firewall (and thus, only need to know the route to the Internal interface of the ISA 2004 firewall machine), the SecureNAT client depends on the routing infrastructure to forward Internet-bound requests to the Internal interface of the ISA 2004 firewall. If the connection encounters a router in the path that does not route Internet-bound connections through the ISA 2004 firewall, the connection attempt will fail.


TIP:
There must be a Protocol Definition created on the ISA firewall for each protocol you want the SecureNAT client to access. This is true even when you configure an Access Rule allowing the SecureNAT client access to all protocols. For the SecureNAT client, “all protocols” means all protocols for which there is a Protocol Definition. This is in contrast to the Firewall client, where an Access Rule specifying all protocols means all TCP and UDP protocols, regardless of whether or not there is a Protocol Definition for a particular protocol.


Because of the limitations of SecureNAT, a computer should only be configured as a SecureNAT client when at least one of the following conditions exists:



  • The machine does not support Firewall client software (non-Windows clients) and requires protocol support outside of what the Web Proxy client can provide (protocols other than HTTP/HTTPS and FTP upload).
  • The machine requires outbound access to the ICMP and PPTP.
  • For administrative or political reasons, you cannot install the Firewall client on machines requiring protocol access outside of that provided by the Web Proxy client configuration.

Disadvantages of the SecureNAT configuration are summarized in Table 1.




















Disadvantage


Implication


Inability to authenticate with the ISA 2004 firewall


The SecureNAT client is unable to send user credentials (user name and password) to the ISA 2004 firewall. This prevents the use of strong user/group-based outbound access control over Internet access. The only outbound access control available for SecureNAT clients is based on a client source IP address.


Inability to use complex protocols


Complex protocols require multiple primary and/or secondary connections. Internet games, voice/video applications, and instant messaging applications often require complex protocol support. The SecureNAT client cannot access Internet applications using complex protocols without the assistance of an application filter installed on the ISA 2004 firewall machine. The only exception to this is when the application installed on the SecureNAT client is configured to support SOCKS proxies. The ISA 2004 firewall includes a built-in SOCKS 4 filter.


Dependency on the existing network routing infrastructure


The SecureNAT client does not forward connections directly to the ISA 2004 firewall. Instead, it depends on the organization’s routing infrastructure. Each router along the path from the SecureNAT client to the ISA 2004 firewall must be aware that the path to the Internet is through the ISA 2004 firewall. This may require reconfiguring network routers with new gateways of last resort (default gateways).


User information is not included in the Firewall and Web Proxy logs


The user name is only included in Firewall and Web Proxy logs when a client sends that information to the ISA firewall. A client piece is always required to send user information to the firewall since there are no provisions in the layer 1 through 6 headers to provide this information. Only the Firewall client and Web Proxy client configurations can send user information to the ISA firewall and have this information included in the log files. SecureNAT client connections allow for logging of the source IP address, but user information is never recorded for machines configured as only SecureNAT clients


Table 1: Disadvantages of the SecureNAT Client Configuration







Discuss this article



SecureNAT Client Advantages


Despite the limitations discussed in the foregoing section, you should not conclude that the SecureNAT client is all bad. In fact, some of the SecureNAT client’s weaknesses also represent the SecureNAT client’s strengths. Advantages of the SecureNAT client configuration include:



  • Support for non-Windows client operating systems
  • Support for non-TCP/UDP protocols (for example, PPTP [GRE] and ICMP)
  • No requirement for client software installation or configuration

The primary purpose of the SecureNAT client configuration is to enable non-Microsoft operating systems access to a broader range of protocols than is supported by the Web Proxy client configuration. The Firewall client works only with Windows operating systems. Without the SecureNAT client configuration, the only protocols available to non-Microsoft operating systems are those provided by the Web Proxy client configuration (HTTP/HTTPS and FTP download).


The SecureNAT client has an important use for Microsoft operating systems, as well. The Firewall client software intercepts outbound TCP and UDP connections established by Winsock applications and forwards them to the ISA 2004 firewall. However, the Firewall client software does not intercept non-TCP/UDP communications. Networking protocols such as ICMP (used by ping and other network diagnostic utilities) and GRE (used in the PPTP VPN protocol) do not use UDP or TCP as a transport protocol. You must configure client computers as SecureNAT clients to support outbound access through the ISA firewall using these protocols.


One significant downside of this situation is that you cannot use user/group-based access controls over which hosts can create outbound connections using non-TCP/UDP protocols.


For example, you might want to allow outbound PPTP VPN connections for a specific group of users. This is not possible because PPTP requires GRE; this bypasses the Firewall client software, and therefore, no user information is passed to the ISA firewall. If you create an outbound PPTP Access Rule that requires user authentication, the connection attempt will fail. The only method available to control an outbound PPTP connection is by source IP address.


TIP:
There must be a Protocol Definition created on the ISA firewall for each protocol you want the SecureNAT client to access. This is true even when you configure an Access Rule allowing the SecureNAT client access to all protocols. For the SecureNAT client, “all protocols” means all protocols for which there is a Protocol Definition. This is in contrast to the Firewall client, where an Access Rule specifying all protocols means all TCP and UDP protocols, regardless of whether or not there is a Protocol Definition for a particular protocol.


NOTE:
ICMP is most commonly used by the ping utility, although other utilities such as tracert also use ICMP. GRE is required if you wish to allow clients outbound access to external VPN servers using the PPTP VPN protocols. In contrast, outbound VPN clients that use the L2TP/IPSec NAT Traversal (NAT-T) protocol do not have to be configured as SecureNAT clients. L2TP/IPSec NAT-T uses only UDP ports 500 and 4500 for outbound access to L2TP/IPSec NAT-T VPN servers. Because of this, you can use the Firewall client configuration to force strong user/group-based access controls over L2TP/IPSec VPN connections.


Probably the most common reason for implementing the SecureNAT client configuration is to avoid installing or configuring client software. Firewall and network administrators are loath to install software on client computers that imposes itself on the network stack. In addition, there is a perception that significant administrative overhead is involved with installing the ISA Firewall client and configuring the Web Proxy client, although in reality, there is not except in the most unusual situations.


In fact, there is an extremely low likelihood that the Firewall client software will interfere with networking components of any client software, and the administrative overhead is very small when you automate the Firewall client and Web Proxy client installation and configuration.


Table 2 details the advantages of the SecureNAT client configuration.




















Advantage


Implication


Provides additional protocol support for non-Windows operating systems


Non-Windows operating systems do not support the Firewall client software. If you wish to provide support for protocols other than those allowed via the Web Proxy client configuration (that is, HTTP/HTTPS/FTP download), the SecureNAT configuration is your only option for non-Windows operating system clients such as Linux, UNIX, and Macintosh.


Support for non-TCP/UDP Protocols


The SecureNAT client is the only ISA 2004 client configuration that supports non-TCP/UDP protocols. Ping, tracert, and PPTP are some of the non-TCP/UDP protocols that require the SecureNAT client configuration. Note that you cannot exert strong user/group-based access controls for non-TCP/UDP protocols because the SecureNAT client configuration does not support user authentication.


Does not require client software installation or configuration


The SecureNAT client does not require any specific software be installed or configured on the client computers. The only requirement is that the default gateway address on the client machine be configured so that Internet-bound requests are forwarded through the ISA 2004 firewall.


Best configuration for published servers


When publishing a server to the Internet, the server often needs to not only accept connections from Internet-based hosts, but also needs to initiate new connections. The best example is an SMTP relay configured for both inbound and outbound relay. The SMTP relay does not need to be configured as a SecureNAT client to receive inbound connections from remote SMTP servers (because you have the option to replace the original source IP address of the Internet host with the IP address of the ISA 2004 firewall). However, the SMTP relay does need to be configured as a SecureNAT client to send outbound mail to Internet SMTP servers. We will cover this issue in more detail in Chapter 10.

Table 2: Advantages of the SecureNAT Client Configuration


Name Resolution for SecureNAT Clients


Name resolution is a critical issue not only when installing the ISA firewall software on the server, but for all types of ISA clients. Each ISA client resolves names in its own way. The SecureNAT client resolves names for hosts on the Internal and External networks using the DNS server address configured on the SecureNAT client’s own network interface.


The fact that the SecureNAT client must be able to resolve names based on its own TCP/IP configuration can pose challenges for Internet-connected organizations requiring access to resources when connected to the corporate network and when those same hosts must leave the corporate network and connect to corporate resources from remote locations. In addition, there are significant challenges when SecureNAT clients attempt to “loop back” through the ISA firewall to access resources on the Internal or other ISA Firewall Protected Networks.


SecureNAT clients must be configured to use a DNS server that can resolve both Internal network names and Internet host names. Most organizations host their own DNS servers within the confines of the corporate network. In this case, the SecureNAT client should be configured to use the Internal DNS server that can resolve Internal and Internet host names,


Name Resolution and “Looping Back” Through the ISA 2004 Firewall


Consider the example of an organization that uses the domain name internal.net for resources located on the Internal network behind the ISA firewall. The organization uses the same domain name to host resources for remote users and publishes those resources on the Internal network. For example, the company hosts its own Web server on the Internal network, and the IP address of that Web server on the Internal network is 192.168.1.10.


The organization also hosts its own public DNS servers and has entered the IP address 222.222.222.1 into the DNS database for the host name www.internal.net. External users use this name, www.internal.net, to access the company’s Web server. The Web server is published using ISA Web Publishing Rules and external users have no problem accessing the published Web server.


Problems arise when SecureNAT clients on the Internal network try to reach the same Web server; the connection attempts always fail. The reason for this is that the SecureNAT clients are configured to use the same DNS server that is used by the external clients to resolve the name www.internal.net. This name resolves to the public address on the external interface of the ISA firewall that is used in the Web Publishing Rule. The SecureNAT client resolves the name www.internal.net to this address and forwards the connection to the external interface of the ISA firewall. The ISA firewall then forwards the request to the Web server on the Internal network.


The Web server then responds directly to the SecureNAT client computer. The reason for this is that the source IP address in the request forwarded by the ISA firewall to the Web Server on the Internal network is the IP address of the SecureNAT client. This causes the Web server on the Internal network to recognize the IP address as one on its local networks and respond directly to the SecureNAT client. The SecureNAT client computer drops the response from the Web server because it sent the request to the public IP address of the ISA firewall, not to the IP address of the Web server on the Internal network. The response is dropped because the SecureNAT client sees this as a response to a connection it did not request.


Figure 4 depicts the SecureNAT client looping back through the ISA 2004 firewall.



Figure 4:
SecureNAT “Loop Back”


The solution to this problem is the split DNS infrastructure. In almost all cases in which the organization requires remote access to resources located on the Internal network, the split DNS infrastructure provides the solution to name resolution problems for SecureNAT and roaming clients (hosts that move between the Internal network and locations outside the corporate network).


In a split DNS infrastructure, the SecureNAT client is configured to use an Internal DNS server that resolves names for resources based on the resource’s Internal network address. Remote hosts can resolve the same names, but the external hosts resolve the same names to the IP address on the external interface of the ISA firewall that publishes the resource. This prevents the SecureNAT client from looping back through the ISA firewall, and connection attempts to published servers succeed for the SecureNAT clients.


Figure 5 demonstrates how the split DNS infrastructure solves the “looping back” issue for SecureNAT clients. Table 3 summarizes important DNS considerations for SecureNAT clients.


NOTE:
For this reason, Web developers should never “hard code” IP addresses or names in links returned to Web users. For example, a Web developer might code a link that points to http://192.168.1.1/info into a Web page response to a user. Internal network clients can access this link because the IP address is that of the Web server on the Internal network, but remote access users will not be able to connect to this resource because the address is not accessible from the Internet. Many Java applications suffer from this type of poor coding, and even some Microsoft applications, such as SharePoint Portal Server (although some of these problems can be solved using the ISA firewall’s Link Translator feature).



Figure 5: A Split DNS Solves the SecureNAT Paradox





























SecureNAT DNS Consideration


Implications


Internal and external host name resolution


The SecureNAT client must be able to resolve all host names via its locally-configured DNS server address. The DNS server must be able to resolve Internal network names, as well as external Internet host names. If the DNS server the SecureNAT client is configured to use is not able to resolve local names or Internet names, the name resolution request may fail and the connection attempt will be aborted.


Looping back through the ISA 2004 firewall


SecureNAT clients must not loop back through the ISA 2004 firewall to access Internal network resources. The most common situation where this occurs is when a server on the Internal network has been published to the Internet. The SecureNAT client is configured with a DNS server that resolves the name of the server to the IP address on the external interface of the ISA 2004 firewall. The SecureNAT client sends a connection request to that IP address and the connection request fails. The solution is to design and configure a split DNS infrastructure.


Organizations with Internal DNS servers


Organizations with Internal DNS servers should configure those servers to resolve both internal and external host names. The Internal DNS servers are authoritative for the Internal network names. The DNS servers should be configured to either perform recursion against Internet DNS servers or use a forwarder to resolve Internet host names. Note that an organization may elect to use different servers for local and external name resolution, but the SecureNAT clients DNS point of contact must have a mechanism in place to resolve both internal and external names.


Organizations without Internal DNS servers


Smaller organizations may not have a DNS server on the Internal network. In this case, alternate methods are used for local name resolution, such as WINS, NetBIOS broadcast name resolution, or local HOSTS files. The SecureNAT clients should be configured to use a DNS server located on the Internet (such as their ISP’s DNS server) or configure a caching-only DNS server on the ISA 2004 firewall computer.


SecureNAT client cannot connect to the Internet


The most common reason for SecureNAT clients failing to connect to Internet resources is a name resolution failure. Check that the SecureNAT client is configured to use a DNS server that can resolve Internet host names. You can use the nslookup utility to test name resolution on the SecureNAT client computer.


SecureNAT client cannot connect to servers on the Internal network


The most common reason for SecureNAT clients failing to connect to local resources using DNS host names is name resolution failure. Check that the DNS server configured on the SecureNAT client is able to resolve names on the Internal network. Note that if the SecureNAT client is configured to use an Internet-based DNS server (such as your ISP’s DNS server), the SecureNAT client will not be able to resolve local DNS host names. This can be solved by configuring the SecureNAT client to use an Internal DNS server that can resolve local and Internet host names, or by using an alternate method of Internal network host name resolution, such as a local HOSTS file.


SecureNAT clients should be configured to use an Internal network DNS Server


Although small organizations may not have a DNS server responsible for name resolution on the Internal network, you should avoid using public DNS servers for your SecureNAT clients. Instead, configure the ISA 2004 firewall as a caching-only DNS server, and configure the SecureNAT clients to use the caching-only DNS server on the ISA 2004 firewall. Configure the caching-only DNS server on the ISA 2004 firewall to use a trusted DNS server, such as your ISP’s DNS server, as a forwarder. This reduces the risks inherent from allowing SecureNAT clients to communicate directly with Internet DNS servers. The caching-only DNS server on the ISA 2004 firewall can be configured to prevent common DNS exploits, such as cache poisoning.

Table 3: DNS Considerations for SecureNAT Clients







Discuss this article



Summary


In this article we reviewed the SecureNAT client and how the SecureNET client can be used in an ISA Firewall environment. We covered the definition of the SecureNAT client, the advantages and disadvantages of the SecureNAT client, and the DNS implications of SecureNAT client use. In general, the SecureNAT client should only be used by non-Microsoft operating systems and those machines that require using non-TCP/UDP protocols, such as ICMP and GRE (PPTP). In a Windows environment, the more secure options are the Firewall and Web Proxy clients.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top