Address Translation

cOS Core supports two types of translation:

  • Dynamic Network Address Translation (NAT)
  • Static Address Translation (SAT)

Two types of cOS Core IP rules, NAT rules and SAT rules are used to configure address translation.


Dynamic Network Address Translation (NAT) provides a mechanism for translating original source IP addresses to a different address. Outgoing packets then appear to come from a different IP address and incoming packets back to that address have their IP address translated back to the original IP address. NAT has two important benefits:

  • The IP addresses of individual clients and hosts can be „hidden“ behind the security gateway’s IP address.
  • Only the security gateway needs a public IPv4 address for public Internet access. Hosts and networks behind the security gateway can be allocated private IPv4 addresses but can still have access to the public Internet through the public IPv4 address.

NAT provides many-to-one translation. This means that each NAT rule in the IP rule set will translate between several source IP addresses and a single source IP address. To maintain session state information, each connection from dynamically translated addresses uses a unique port number and IP address combination as its sender. cOS Core performs automatic translation of the source port number as well as the IP address. In other words, the source IP addresses for connections are all translated to the same IP address and the connections are distinguished from one another by the allocation of a unique port number to each connection.

IP address used for translation can be Interface address, Specific address or NAT Pool of addresses. Beware for specific IP addresses you need to have a matching ARP Publish Entry configured for the outbound interface!!! Otherwise return traffic will not work (Clavister will not reply for ARP request, even it has the route to destination)

NAT Pools

NAT Pools are usually employed when there is a requirement for huge numbers of unique port connections. By using NAT Pools we can translate private address to more than one public IP address. There are 3 types of NAT pools:

  • Stateful – When the Stateful option is selected, cOS Core allocates a new connection to the external IPaddress that currently has the least number of connections routed through it with the  assumption that it is the least loaded.
  • Stateless – No state table is maintan and external IP address is chosen for each new connection that has the least connections already allocated to it  (I dont understand but nevermind)
  • Fixed – The Fixed option means that each internal client or host is allocated one of the external IP addresses through a hashing algorithm. Although the administrator has no control over which of the external connections will be used, this scheme ensures that a particular internal client or host will always communicate through the same external IP address.

In NAT pool configuration you have to specify which interfaces will be used by NAT pools. These interfaces then do Proxy ARP and replies to ARP requests.


cOS Core Static Address Translation (SAT) functionality can translate ranges of IP addresses and/or port numbers to other, predefined static values. The translation can be to a single address and/or port but can also be a transposition where each address and/or port in a range or network is mapped to a corresponding value in a new range or network.

SAT translation can be generally divided into three types:

  • One-to-one translation – A single value is translated to another single value.
  • Many-to-one translation – Multiple values are translated to one single value.
  • Many-to-many translation – Multiple values are transposed to different multiple values.

The values being translated may be the IP address and/or the port number for either the source or destination of new connections set up by cOS Core. As discussed later, the many-to-one translation is not available for port numbers.


Unlike NAT, SAT requires more than a single IP rule when it is configured. A SAT rule that triggers for the target traffic must first be created to specify the translation required. However, cOS Core does not terminate rule set lookups after finding a matching SAT rule. Instead, the rule set search continues for a matching Allow, NAT or FwdFast rule. Only when cOS Core finds such a second matching rule is the SAT rule applied to the traffic.

An important principle to keep in mind when creating IP rules for SAT is that the second rule, for example an Allow rule, must trigger on the old, untranslated IP address (either source or destination IP depending on the type of SAT rule). A common mistake is to create a second IP rule expecting that it should trigger on the new, translated IP address. This is same like in Cisco ASA 8.3 and higher.

If you want to translate source and destination address in the same connection you have to create two SAT rules.

SAT IP rule properties are similar to other types of IP rules:

  • SAT Translate – This specifies the address that will be changed and can be one of:
    • Destination IP – The original destination IP will be translated.
    • Source IP – The original source IP will be translated.
  • New IP Address – The new address for the translation.
  • New Port – The new port number used for translation. As explained below, port translation happens independently of address translation and follows slightly different rules.
  • All-to-OneMapping – This is enabled if the mapping is to be many IP addresses to a single IP address. It is not used for port translation as all-to-one port translation is not possible.

SAT rules

  • If the original address is a single IP address then a one-to-one mapping is always performed. The new IP address should also be a single address. This is the most common usage of SAT.
  • If the original address is an IP range or network then a many-to-many mapping is always performed unless the All to One property is enabled in which case an all-to-one mapping is always performed.
  • An all-to-one mapping is performed if the All to One property is enabled for the SAT IP rule. For this, the original address should be a range or network and the new address should be a single IP address.

One-to-One IP Translation

The simplest form of SAT usage is the translation of a single IP address to another single, static address. A very common scenario for this usage is to enable external users to access a protected server in a DMZ that has a private address. If you use in SAT destination rule interface IP, you have to specify in SAT rule the core interface as destination interface.

Many-to-Many IP Translation

A single SAT rule can be used to transpose an entire range or network of IP addresses to another range or network. The result is a many-to-many translation where the first original IP address is translated to the first IP address in the new range or network, then the second to the second, and so on.


All-to-One IP Translation

cOS Core can be used to translate a range or a network to a single IP address. Suppose that the requirement is to translate a range of destination IPv4 addresses which includes to plus to the single IPv4 address The port number will remain unchanged (this is the difference from NAT I  guess).


Port Translation

Port Address Translation (PAT) can be used to modify the source or destination port of a connection. In previous SAT examples, a new port number was not been specified and the original port number was used by default. If the port number is specified, both the IP address and the port number are translated. Port translation is performed by the same SAT IP rule used for IP address translation but follows slightly different processing rules to IP address translation. Only one-to-one and many-to-many port translation can be performed. All-to-one port translation is not possible.

SAT with FwdFast Rules

It is possible to SAT IP rules in conjunction with FwdFast IP rules. In other words, to use SAT with stateless connections. The difference in this case is that the return traffic must be explicitly translated and allowed by separate FwdFast IP rules.