Translated IP addresses are used in routing, in VPN site definitions, and system
communications. After adding or modifying NAT rules, you must consider how these areas of communications are affected and what changes are needed. If you are using Multi-Link, Outbound Multi-Links have their own NAT configurations that must not overlap with the NAT rules you define.
Particularly, check that:
•Access rules and Inspection rules use the addresses that are seen in the packets as they arrive on the firewall (as they are before any NAT operation is done).
•Routing decisions are made after NAT, so the routing decision is made using the translated address. Make sure the translated address is included in the Routing view under the correct
•If you translate addresses of communications going through VPN tunnels, the translated addresses must be included in the VPN site definitions.
Using NAT and NAT Rules
The general configuration of NAT and NAT rules is explained above. The sections below provide further information on configuring NAT:
•NAT and System Communications
•Outbound Load Balancing NAT (page 122)
•Proxy ARP and NAT (page 122)
•Protocols and NAT (page 123)
For general information on using rules, see Using Policy Elements and Rules (page 79).
NAT and System Communications
If NAT is needed between StoneGate components, you must define Contact Addresses for the communications, so that the StoneGate components use the correct (NATed) address for contact when needed.
Contact Addresses are used in a NAT environment for communications of StoneGate
components with each other and with some external components that function as a part of the system (such as a RADIUS server used for authenticating Administrators). Contact Addresses may be needed also for gateway-to-gateway and client-to-gateway VPNs.
The Default template includes NAT rules which define that NAT is not done for communications between the firewall where the policy is installed and the Management Server and Log Server that the firewall uses. If these connections require NAT, the configuration must be done as explained here. Other system communications traversing the firewall can be translated as any other connections (but Location and Contact Address definitions are usually still needed for those components so that they know the correct addresses to use with each other). See Example of a Situation Where a Contact Address is Needed below.
Contact Addresses are defined for Locations, which is an element that represents all devices that are routable behind a particular interface of a NAT device. The components that need Contact Addresses are placed in the Locations according to the Contact Address they use.
Note – By default, NAT is disabled with connections traversing a VPN (NAT rules are completely ignored for VPN traffic). If you want the NAT rules to apply to connections traversing a VPN, enable NAT in the properties of the VPN element.
Example of a Situation Where a Contact Address is Needed
The following illustration demonstrates a scenario in which Contact Addresses are needed.
Illustration 11.5 Contact Address Example
In the illustration above, there are several remote firewalls that are managed through
Management and Log Servers at a central site. NAT is typically applied at the following points:
•The central site firewall or an external router may provide the SMC servers external IP addresses on the Internet. The external addresses must be defined as Contact Addresses so that the remote firewalls can contact the servers across the Internet.
•The central firewall’s IP address may be translated by an external router. The external IP address must be defined as a Contact Address to allow VPN connections from the remote firewalls to the central site using that address.
•NAT may also be applied at the remote sites (by external equipment) to translate the remote firewalls’ IP address. In this case, you must define Contact Addresses for the remote firewalls so that the Management Server can contact them. The communications between the remote firewalls and the Management Server may also be reversed, so that the remote firewalls open the connections to the Management Server and maintain the connections open while waiting for commands.
When Contact Addresses are needed, a single Location to group all remote sites may be enough. The SMC servers’ and the central firewall's definitions must include a Contact Address for the “Remote Firewalls” Location. However, if VPN communications between firewalls from different remote sites are allowed, it is necessary to create a Location for each remote firewall and to add further Contact Addresses for the firewalls.
Contact Addresses and Locations
The Contact Address represents the translated address of a component. Contact Addresses are defined for each Location element. The Location element is a way to group components together, in effect telling them that there is no NAT device between them.
The system components on each side of a NAT device are grouped into two separate Location elements (if necessary, more Location elements can be used). The Contact Address is defined in each element’s properties for the other Location. When contacting some other component in
Headquarters Location Branch Office
uses the Contact Address. If there is no Location-specific Contact Address defined, the contacting component checks if the element has a Default Contact Address that components belonging to any other Location use for contacting the element. If the element does not have a Default Contact Address, the connection is attempted using the element’s untranslated address.
For example, when a Management Server contacts a firewall node through NAT, the
Management Server uses the translated Contact Address instead of the firewall node’s real Control IP address. The NAT device in between translates the NAT address to the firewall’s real IP address as usual.
We recommend dividing elements into different Locations based on NAT and the communications the components have, and not just based on actual physical sites. For example, if there is one central site and several remote sites, and the system communications take place only from each remote site to the central site (not between the remote sites), only two Locations are needed no matter how many of the firewalls use a translated address.
Outbound Load Balancing NAT
In addition to source and destination translation, another main use for NAT is outbound load balancing. It is used in a Multi-Link configuration where StoneGate balances outbound traffic between two or more network connections. To be able to direct traffic to the faster connection, the firewall translates outgoing connections to an address from a pool assigned to each available NetLink. In this case, the IP address(es) used for the NAT are defined in the properties of the Outbound Multi-Link element. Outbound traffic management using NAT with Multi-Link Technology is covered in detail in Outbound Traffic Management (page 205) and Multi-Link Routing for Single and Clustered Firewalls (page 64).
Proxy ARP and NAT
Proxy ARP (Address Resolution Protocol) is a specification that allows a device to respond to ARP requests on behalf of some other device on the network. When network address translation is used on a firewall, the firewall is typically configured to use proxy ARP so that it can accept packets for the translated addresses. The firewall uses proxy ARP instead of requiring the administrator to assign all of the translation addresses to the firewall’s network interface.
In StoneGate, proxy ARP is handled automatically. Proxy ARP is enabled by default in the NAT cell in NAT rules for each translation type, although you have the option to uncheck it, if necessary. Automatic proxy ARP requires that the firewall is configured with an explicit route to the host in question (host/network added in the Routing view).
Note – If NAT is performed between a Log Server and a Management Client, you may need to select the correct Location for the Management Client as well.
Protocols and NAT
Protocols of the Protocol Agent type help with problems related to certain complex protocols and NAT. In some protocols, such as FTP, IP address information is included in the data payload of the packets, which do not normally include information for routing. Protocols of the Protocol Agent can examine the data payload of packets arriving to the firewall and also modify it. For example, when the source address is included in a packet’s data, the firewall can translate the original source address and also the address embedded in the data. Protocols of the Protocol Agent are discussed in more detail in Protocol Agents (page 127).
Examples of NAT
The examples in this section illustrate some common uses for NAT rules in StoneGate and the general steps on how each scenario is configured.
Dynamic Source Address Translation
Company A uses private IP addresses that are not routable on the Internet in their internal network. The administrators need to translate the internal IP addresses to IP addresses that are routable on the Internet to make it possible to use external services. The administrators:
1. Create an Address Range element “External Addresses” for two consecutive IP addresses from the pool of addresses that they have been assigned by their Internet service provider.
2. Add a new NAT rule to their Firewall Policy:
•The administrators use the whole range of high ports (1024-65535) for translating the addresses in this case.
•Return address translation is done automatically, so a single rule suffices to cover all (client) hosts that only open connections themselves, and do not need to accept new connections coming from external networks.
3. Refresh the FIrewall Policy. All internal addresses are now hidden behind two IP addresses and a range of ports.
Table 11.2 Dynamic Translation Rule for Opening Connections to the Internet
Source Destination Service NAT
“$ Local Protected Sites”
Alias
“NOT $ Local Protected Sites”
Expression ANY Source: Dynamic to External
Addresses 1024-65535
Static Address Translation
In the first example, Company A sets up the firewall to translate the IP addresses of all communications between the internal and the external network dynamically. However, the company also has a mail server, which must be able to accept connections from external networks. For this, it must have a fixed translated IP address. The administrators:
1. Create the Host element “Mail Server” to represent the mail server’s private IP address.
2. Create the Host element “Mail Server NAT” to represent the mail server’s public IP address.
3. Add two new NAT rules above the general dynamic translation rule.
•In this case, new connections may be opened both from the mail server and from external hosts, so two rules are necessary.
4. Change the newly added NAT rules as follows:
•The first rule is for connections that the mail server opens to external hosts.
•The second rule is for connections that external hosts open to the mail server.
•Return address translation is done automatically, so if the connection would always be opened from one end, a single rule would suffice.
5. Refresh the Firewall Policy.
NAT with Hosts in the Same Network
Company B has two servers running in the same DMZ network. The servers keep contact with each other to exchange some information. The administrators want to route the traffic through the firewall so that it is logged for reporting purposes instead of letting the servers
communicate with each other directly.
Illustration 11.6 Company B’s Network Setup
Table 11.3 Static Translation Rules for Opening Connections Both Ways
Source Destination Service NAT
Source: Static from Mail Server to Mail Server NAT
“NOT $ Local Protected Sites”
Expression “Mail Server NAT” Host “SMTP” Service
element Destination: Static from Mail Server NAT to Mail Server
The administrators first intend to just configure the servers to use the external (NAT) address of the other server as a destination and configure the related static destination NAT rule. However, they soon realize that the receiver would see the real source address in the communications and the replies would be sent directly, bypassing the firewall for the reply communications. This would obviously prevent the connections. A static source NAT is required in addition to the static destination NAT.
The administrators:
1. Create Host elements to represent the private addresses of the two servers.
2. Create Host elements to represent the public addresses of the two servers.
3. Add two new NAT rules before any other NAT rule that would match these connections:
•When the servers are configured to contact each other using the public IP addresses, the communications are routed through the firewall.
•The Firewall translates the destination to the other server’s private IP address and the private IP address of the source to the public IP address to “hide” the private source address from the receiving host. This way, the replies are sent to the public IP address and routed correctly through the firewall.
Table 11.4 Static Translation Rules for Opening Connections Both Ways
Source Destination Service NAT
“Server A Private”
Host
“Server B Public”
Host ANY
Source: Static from Server A Private to Server A Public
Destination: Static from Server B Public to Server B private.
“Server B Private”
Host
“Server A Public”
Host ANY
Source: Static from Server B Private to Server B Public
Destination: Static from Server A Public to Server A private.
C HA PT E R 12
P ROTOCOL A GENTS
Protocols of the Protocol Agent type are special modules for some protocols and services that require advanced processing. Protocol Agents can enforce policies on the application layer.
The following sections are included:
Overview to Protocol Agents (page 128)
Configuration of Protocol Agents (page 129)
Using Protocol Agents (page 130)
Examples of Protocol Agent Use (page 134)
Overview to Protocol Agents
Protocol Agents are software modules for advanced processing protocols that require special handling on the firewall due to their complexity, address information hidden in the data payload, etc. They can be used to extend the firewall’s Access rules with proxy-like application layer features. Protocol elements also associate the traffic with a certain protocol for inspection against the Inspection rules.
Protocol Agents can:
•Validate application-level protocol use (for example, FTP command syntax).
•Modify application data when required (for example, NAT in H.323 data payload).
•Open related connections when required (for example, FTP data connections).
•Redirect FTP, HTTP, and SMTP connections to content inspection servers.
•Proxy HTTP connections.
Some types of traffic always require the use of the correct Protocol Agent to pass the firewall when the traffic is handled using stateful inspection.
File Transfer Protocol (FTP) is a good example of a protocol that uses two related connections: a control connection and a separately established data connection. If the control connection is allowed without the Protocol Agent, the firewall does not recognize that the data connection is part of an existing connection and handles it like a new connection (which usually leads to failed data transfer).
Connection Handling
When related new connections are opened based on information exchanged in an initial connection, Protocol Agents may be needed. Protocol Agents are provided to handle the following protocols:
•FTP with the related active and passive data connections.
•H.323 conferencing protocol communications.
•Microsoft RPC for Microsoft Exchange and Outlook communications.
•NetBIOS for the Windows NetBIOS datagram services.
•Oracle TNS protocol communications.
•Remote Shell protocol communications.
•SunRPC portmapper communications.
•TFTP file transfers.
Protocol Validation
Protocol Agents can be used to validate communications against standards of specific protocols. Exactly how this works depends on the protocol in question. A few examples:
•The FTP Protocol Agent can be set to strictly limit the allowed commands within the control connection to standard commands as listed in the FTP specifications. If other commands are sent in the control connection, the connection is dropped.
•The Oracle Protocol Agent can control the size of the Oracle TNS packets, or the location of the Listener service with respect to the database services.
•The SSH Protocol Agent can ensure that the SSH handshake is performed at the beginning of an SSH connection.
NAT in Application Data
Protocol Agents can be used to assist with network address translation (NAT) in the application data.
For example, the H.323 conferencing protocol includes the source and destination address information in the data payload of the packets (as opposed to ‘normal’ traffic where all IP address information relevant to the communications is in the spaces reserved for this in the packet headers). The H.323 Protocol Agent can examine the data payload and modify the addresses according to the network address translation as needed. Therefore, when the source address is included in the protocol data, the source address is also translated in the data payload. The receiving machine then responds to the proper address.
Configuration of Protocol Agents
Protocol Agents are represented in the Management Client by Protocol elements that have Protocol Agent as their type. Other Protocol elements are of the type Protocol Tag.
Illustration 12.1 Using Protocol Agents
As seen in Illustration 12.1, Protocol Agents are not included directly in firewall policies. They are used inside custom Service elements that you create, and which can then be used in Access rules. Whenever traffic matches a rule that contains a Service element with an associated Protocol Agent, the Protocol Agent is automatically activated.
All Protocol Agents in the system are default elements, and you cannot change them or add any new ones. There are also default Service elements in the system for most supported protocols that you can use to activate the Protocol Agents. However, some Protocol Agents have
parameters and options you can set by creating customized Services as explained below.
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help or the Administrator’s Guide PDF.