6.7.5. NAT policies

Network Address Translation (NAT) is a technology that can be used to change source or destination addresses in a connection from one IP address to another one.

Today, most corporate networks work with private, non-Internet-routable IP addresses from the 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 ranges. These IP addresses are suitable for intranet communication (they can even be routed internally) but cannot be used on the Internet. Therefore a mechanism, NAT, is in place, that, whenever an internal client wants to access Internet resources, uses a public IP address for this purpose.

Another use for NAT is address hiding. Towards the Internet only a limited number of public IP addresses are visible, while you may have thousands of internal clients and servers all “translated” to those few addresses.

Tip

Address hiding with the help of NAT is especially useful for published servers (usually located in a DMZ). The potential attackers can see only a few public IP addresses (or even a single one) but from this information the actual location and the number of the servers, or even their configuration details remain hidden.

Note

Although address hiding can be considered as a security feature, NAT alone is not enough to protect a network from malicious intruders. Never use NAT in itself as a security solution.

Based on whether source or destination IP addresses are transformed, two kinds of NAT can be differentiated.

  • Source NAT (SNAT) - if source IP addresses are transformed

  • Destination NAT (DNAT) - if address transformation is performed on destination IP addresses

Basically, NAT in Zorp provides a possibility to modify the source and destination IP address at the server side before the connection is established. The source and destination IP address values are defined previously by the router on the basis of the router type, its settings and the client request. In some cases, Proxy settings can also be involved, for example when the Target address overrideable by the proxy router option is enabled. NAT is responsible for changing IP addresses to some other addresses depending on the configuration of the NAT policy.

Note

This NAT is performed by the Zorp component and is totally different from the NAT offered by IPTables in the Packet Filter component.

By default, when no NAT policy is set up, Zorp uses its own IP address configured for the corresponding network interface when sending out traffic in any direction. Although this results in many clients “using” the same (single) IP address, it is not considered as SNAT technically.

In Zorp, NAT is performed on the application proxy level. In this case it is not strictly IP address replacement, since original packets do not appear in the traffic leaving the firewall. It is an IP address modification rule rather. If application proxying is used — meaning there is no traffic that is forwarded on the packet filter level — packet filter level NAT is neither required nor recommended.

Service definitions contain NAT policy settings to configure application proxy-level NAT.

Note

If some traffic is managed at the packet filter level, NAT must be performed at the packet filter level, too. In this case, NAT is actually an IP address replacement, since the packet filter – rules permitting – forwards the original packets it receives. You are not recommended to use NAT at the packet filter level.

For more details on packet filter-level NAT solutions, see Appendix A, Packet Filtering.

Originally, NAT meant only address translation, leaving port information travelling in TCP or UDP packets unmodified. This can lead to errors especially in large networks where thousands of clients are NATed by a single machine, therefore NAT technologies were modified to do port translation as well, guaranteeing that even if two internal clients try to use the same source port number in session establishments, the packets leaving the NAT server always have unique source IP address/port pairs.

Note

Port translating NAT devices are incompatible with IPSec encryption (which is a major drawback as IPSec is becoming increasingly popular) and may be incompatible with proprietary, two-channel protocols as well.

Previous Up Next
 Home