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 only see a few public IP addresses (or even a single one) but from this information they have no way of knowing where your servers are actually located, how many of them there are and in what configuration. |
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 Application-level Gateway 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 router type, its settings and the client request. In some cases, Proxy settings can also be involved, for example when the 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 component and is totally different from the NAT offered by IPTables in the component. |
By default, when no NAT policy is set up, Application-level Gateway 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 Application-level Gateway 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 really 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. |
Published on June 04, 2020
© 2007-2019 BalaSys
Send your comments to support@balasys.hu