Home  Prev  cOS Core 14.00.15 Administration Guide  Next

8.4. SAT

8.4.1. Introduction

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.

[Note] Note: cOS Core SAT is the same as "port forwarding"

Some network equipment vendors use the term "port forwarding" when referring to SAT. Both terms refer to the same functionality.

Methods of Configuring SAT in cOS Core

There are two ways of configuring NAT in the cOS Core IP rule set:

  • Using IP Policies

    An IP Policy object can be added to the IP rule set with its Destination Address Translation property set to SAT. This is the recommended method since everything can be done with a single rule set entry and it is simpler to add other security mechanisms on the same IP rule set entry.

  • Using IP Rules

    An IP Rule object can be added to the IP rule set with its Action property set to SAT. A second corresponding IP rule must always also be added with its Action property set to Allow. This method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy.

Most of the discussion and examples in this section will assume that IP policies are being used to set up SAT. A discussion of setting up SAT using IP rules can be found towards the end in Section 8.4.9, SAT Setup Using IP Rules.

Types of SAT Translation

SAT translation in cOS Core can be divided into three types:

  • One-to-One - A single IP address is translated to a new single address.

  • Many-to-Many - Multiple IP addresses are transposed to multiple new addresses.

  • Many-to-One - Multiple IP addresses are translated to a new single address.

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.

Specifying the Type of IP Address Mapping

cOS Core recognizes the type of SAT IP address mapping using the following rules:

  • One-to-One

    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 and is described further in Section 8.4.2, One-to-One IP Translation.

  • Many-to-Many

    If the original address is an IP range or network then a many-to-many mapping is always performed provided that transposition is selected.

    With a many-to-many mapping, a single new IP address is specified and the mappings are performed incrementally starting from that address. If an entire network is being transposed to another network then the new IP address should be the first address in the new network. For example, 192.168.1.0.

    This translation type is described further in Section 8.4.3, Many-to-Many IP Translation.

  • Many-to-One

    When a many-to-one mapping is performed, the original source address should be a range or network and the new destination address should be a single IP address. Transposition should not be enabled.

    When the source address is all-nets, a many-to-one SAT mapping is always used.

    This translation type is described further in Section 8.4.4, Many-to-One IP Translation.

Configuring SAT Using an IP Policy

When creating a SAT IP policy, translation can be specified for source or destination translation, or both. The way the translation functions for the source and/or destination address is determined by specifying one or both of the following actions:

  • Address Action

    This determines how the IP address is translated and can be one of the following:

    1. Single IP - Either a single original IP or a range/network will be translated to the single new IP address specified. This yields both a one-to-one or a many-to-one IP address translation.

    2. Transposed - This yields a many-to-many translation where each address in the original range/network is transposed to a new range/network, using the specified new IP address as the base address for the transposition.

  • Port Action

    This determines how the IP address is translated and can be one of the following:

    1. None - No port translation takes place.

    2. Single Port - This is used for a one-to-one translation to the new port number specified.

    3. Transposed - This transposes a range of port numbers to a new range using the new port number as a base for the transposition. This is for a many-to-many port translation.

    Port translation is described further in Section 8.4.7, Port Translation.

The sections that follow show how the different kinds of SAT translation can be configured.

Using the Auto Setting for Source Translation

An IP Policy has a default value of Auto for its Source Translation property. In the examples in this section, the Source Translation will be set to None or Transpose so it is clear what action is being performed.

The behavior of the Auto setting for source translation is discussed in Section 8.5, Automatic Translation.

8.4.2. 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. This is also sometimes referred to as implementing a Virtual IP or a Virtual Server and is often used in conjunction with a DMZ.

The Role of a DMZ

At this point, it is relevant to discuss the role of the network known as the Demilitarized Zone (DMZ) since SAT rules are often used for allowing DMZ access.

The DMZ's purpose is to have a network where the administrator can place those resources which will be accessed by external, untrusted clients and where this access typically takes place across the public Internet. The servers in the DMZ will have the maximum exposure to external threats and are therefore at most risk of being compromised.

By isolating these servers in a DMZ, the object is to create a distinct network, separated from much more sensitive local, internal networks. This allows cOS Core to have control over what traffic flows between the DMZ and internal networks and to better isolate any security breaches that might occur in DMZ servers.

Example 8.4. One-to-One IP Translation Using an IP Policy

In this example, SAT will be set up to translate and allow HTTP and HTTPS connections from the Internet to a web server located in a DMZ. The scenario is illustrated in the diagram below.

The firewall is connected to the Internet via the wan interface with address object wan_ip as its public IPv4 address. The web server has the private IPv4 address 10.0.0.5 and is reachable through the dmz interface. The port number will not be translated.

Command-Line Interface

Create a SAT IP Policy: 

Device:/> add IPPolicy Name=sat_http_to_dmz
			SourceInterface=wan
			SourceNetwork=all-nets
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=http-all
			Action=Allow
			SourceAddressTranslation=None
			DestinationAddressTranslation=SAT
			DestinationAddressAction=SingleIP
			DestNewIP=10.0.0.5

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create a SAT IP policy:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
  2. Now enter:
    • Name: sat_http_to_dmz
    • Action: Allow
  3. Under Filter enter:
    • Source Interface: wan
    • Source Network: all-nets
    • Destination Interface: core
    • Destination Network: wan_ip
    • Service: http-all
  4. Under Source Translation enter:
    • Address Translation: None
  5. Under Destination Translation enter:
    • Address Translation: SAT
    • Address Action: Single IP
    • New IP Address: 10.0.0.5
  6. Click OK

Applying the SAT IP Policy to Internal Clients

The preceding example results in the following being added to the main IP rule set:

# Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
1 Allow/SAT wan all-nets core wan_ip http-all Destination IP: 10.0.0.5

The SAT rule destination interface must be core (in other words, cOS Core itself) because interface IPs are always routed on core.

Now, consider the scenario illustrated below, where there are internal clients on the lan_net network which also want to access the web server in the DMZ.

SAT Translation with Internal Clients

Figure 8.4. SAT Translation with Internal Clients

If the internal clients require access to the Internet, a NAT IP rule set entry is also needed. However, this will not provide access to the web server because the source interface of the SAT IP policy does not include the lan interface. This problem can be solved in one of the following two ways:

  • Change the Source Interface Value

    Give the Source Interface of the SAT IP policy the value all. The resulting IP rule set would then contain the following entries:

    # Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
    1 Allow/SAT any all-nets core wan_ip http-all Destination IP: 10.0.0.5
    2 Allow/NAT lan lan_net any all-nets http-all  

  • Use an Interface Group

    Create an Interface Group object which consists of the wan and lan interfaces and assign it to the Source Interface property. This is a more restrictive solution and is therefore better from a security perspective.

  • Use the IP Policy Automatic Translation Feature

    Using the automatic translation feature of an IP policy is the simplest solution and is described in Section 8.5, Automatic Translation. A single IP policy can be created which both performs the SAT translation and the NAT translation required by internal clients, as illustrated in Example 8.14, “Automatic SAT/NAT Translation with an IP Policy”.

However, if the web server is on the same network as the client, a different approach is required and this is described in Section 8.4.6, Combining SAT with NAT.

8.4.3. Many-to-Many IP Translation

A single SAT IP rule set entry 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.

To tell cOS Core to perform this type of translation, the original IP address must be a range or network and the IP policy's Address Action property must be set to the value Transposed. The new range or network is specified using a single IP address which is the starting address for the transposition. For example, 192.168.1.0 would be specified as the new address if the transposition is to the network 192.168.1.0/24 and starting from the first address in the network.

As another example, a SAT IP rule set entry might specify that connections to the 194.1.2.16/29 network should be translated to 192.168.0.50. The IP policy for this would be:

# Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
1 Allow/SAT any all-nets core 194.1.2.16/29 all_services Destination IP: 192.168.0.50

This IP policy would result in the following translations:

Original Destination Address Translated Destination Address
194.1.2.16 192.168.0.50
194.1.2.17 192.168.0.51
194.1.2.18 192.168.0.52
194.1.2.19 192.168.0.53
194.1.2.20 192.168.0.54
194.1.2.21 192.168.0.55
194.1.2.22 192.168.0.56
194.1.2.23 192.168.0.57

These translations will mean:

  • Attempts to communicate with 194.1.2.16 will result in a connection to 192.168.0.50.

  • Attempts to communicate with 194.1.2.22 will result in a connection to 192.168.0.56.

An example of an application for this feature is when there are several protected servers in a DMZ, and each server is to be accessible using a unique public IPv4 address.

Setting Up Many-to-Many SAT Translation

The following steps are needed for setting up many-to-many SAT translation:

  1. Define an address object containing the range of public IPv4 addresses.

  2. Define another address object for the base address of the web server IP addresses.

  3. ARP publish the public IPv4 addresses on the interface connected to the Internet.

  4. Create an IP Policy object that will perform the SAT translation.

Example 8.5. Many-to-Many SAT Translation Using an IP Policy

In this example, an IP policy will translate from five public IPv4 addresses to five web servers located in a DMZ. The firewall is connected to the Internet via the wan interface and the public IPv4 addresses have the range 203.0.113.1-205.0.113.5. The web servers have the private IPv4 address range 10.0.0.5-10.0.0.9 and are on the network connected to the dmz interface.

Note that since the public IPv4 addresses will be manually ARP published, these addresses are not routed on core so the SAT destination interface is wan and not core.

Command-Line Interface

Create an address object for the public IPv4 addresses: 

Device:/> add Address IP4Address wwwsrv_pub
			Address=203.0.113.1-205.0.113.5

Now, create another object for the base of the web server IP addresses: 

Device:/> add Address IP4Address wwwsrv_priv_base Address=10.0.0.5

Publish the public IPv4 addresses on the wan interface using ARP publish. One ARP object is needed for every public IP address: 

Device:/> add ARP Interface=wan IP=203.0.113.1 Mode=Publish

Repeat this for all the remaining public IPv4 addresses.

Create an IP policy for the translation: 

Device:/> add IPPolicy Name=sat_http_to_dmz
			SourceInterface=any	
			SourceNetwork=all-nets
			DestinationInterface=wan
			DestinationNetwork=wwwsrv_pub
			Service=http-all
			Action=Allow
			SourceAddressTranslation=None
			DestinationAddressTranslation=SAT
			DestinationAddressAction=Transposed
			DestBaseIP=wwwsrv_priv_base

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create an address object for the public IPv4 address range:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_pub
    • IP Address: 203.0.113.1-205.0.113.5
  3. Click OK

Now, create another address object for the base of the web server IP addresses:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_priv_base
    • IP Address: 10.0.0.5
  3. Click OK

Publish the public addresses on the wan interface using ARP publish. One ARP item is needed for every IP address:

  1. Go to: Network > Interfaces and VPN > ARP/Neighbor Discovery > Add > ARP/Neighbor Discovery
  2. Now enter:
    • Mode: Publish
    • Interface: wan
    • IP Address: 203.0.113.1
  3. Click OK and repeat the other public IPv4 addresses

Create a SAT rule for the translation:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
  2. Now enter:
    • Name: sat_http_to_dmz
    • Action: SAT
  3. Under Filter enter:
    • Source Interface:any
    • Source Network: all-nets
    • Destination Interface: wan
    • Destination Network: wwwsrv_pub
    • Service: http-all
  4. Under Source Translation enter:
    • Address Translation: None
  5. Under Destination Translation enter:
    • Address Translation: SAT
    • Address Action: Transposed
    • Base IP Address: wwwsrv_priv
  6. Click OK

8.4.4. Many-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 194.1.2.16 to 194.1.2.20 plus 194.1.2.30 to the single IPv4 address 102.168.0.50. The port number will remain unchanged.

The IP rule set entry to perform the translation would be:

# Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
1 Allow/SAT any all-nets wan 194.1.2.16-
194.1.2.20,
194.1.2.30 		http-all Destination IP: 192.168.0.50

The following are some examples of how this rule rule set entry would perform translations:

  • Attempts to communicate with IPv4 address 194.1.2.16, will result in a connection to 192.168.0.50.

  • Attempts to communicate with IPv4 address 194.1.2.30, will result in a connection to 192.168.0.50.

Example 8.6. Many-to-One SAT Translation Using an IP Policy

In this example, the firewall is connected to the Internet via the wan interface and the public IPv4 addresses have the range of 203.0.113.6-203.0.113.9. The server has the private IPv4 address 10.0.0.5 and is on the network connected to the dmz interface.

The steps used to set this up will be the following:

  1. Define an address object containing all the public IPv4 addresses.

  2. Define another address object set to be the private IPv4 address of the web server.

  3. ARP publish the public IPv4 addresses on the interface connected to the Internet.

  4. Create an IP policy that will perform the SAT translation.

Note that since the public IPv4 addresses will be manually ARP published, these addresses are not routed on core so the SAT destination interface is wan and not core.

Command-Line Interface

Create an address object for the public IPv4 addresses: 

Device:/> add Address IP4Address wwwsrv_pub
			Address=203.0.113.6-203.0.113.9

Now, create another object for the web server's private IP addresses: 

Device:/> add Address IP4Address wwwsrv_priv Address=10.0.0.5

Publish the public IPv4 addresses on the wan interface using ARP publish. A command like the following is needed for each public IP address: 

Device:/> add ARP Interface=wan IP=203.0.113.6 mode=Publish

Repeat this command for the other public IP addresses.

Create a SAT IP rule for the translation: 

Device:/> add IPPolicy Name=sat_all_to_one
			SourceInterface=any	
			SourceNetwork=all-nets
			DestinationInterface=wan
			DestinationNetwork=wwwsrv_pub
			Service=http-all
			Action=Allow
			SourceAddressTranslation=None
			DestinationAddressTranslation=SAT
			DestinationAddressAction=SingleIP
			DestNewIP=wwwsrv_priv

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create an address object for the public IPv4 address range:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_pub
    • IP Address: 203.0.113.6-205.0.113.9
  3. Click OK

Now, create another address object for the web server's private IP address:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_priv
    • IP Address: 10.0.0.5
  3. Click OK

Publish the public addresses on the wan interface using ARP publish. One ARP item is needed for every IP address:

  1. Go to: Network > Interfaces and VPN > ARP/Neighbor Discovery > Add > ARP/Neighbor Discovery
  2. Now enter:
    • Mode: Publish
    • Interface: wan
    • IP Address: 203.0.113.6
  3. Click OK and repeat the other public IPv4 addresses

Create a SAT IP rule for the translation:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
  2. Now enter:
    • Name: sat_all_to_one
    • Action: Allow
  3. Under Filter enter:
    • Source Interface: any
    • Source Network: all-nets
    • Destination Interface: wan
    • Destination Network: wwwsrv_pub
    • Service: http-all
  4. Under Source Translation enter:
    • Address Translation: None
  5. Under Destination Translation enter:
    • Address Translation: SAT
    • Address Action: Single IP
    • New IP Address: wwwsrv_priv
  6. Click OK

8.4.5. SAT with Stateless IP Rule Set Entries

It is possible to configure SAT with IP rule set entries that are "stateless". In other words, entries which do not track the packets flowing between source and destination as part of a single connection. This means that two rule set entries will be needed, one for each direction of traffic flow. Returning traffic must be also explicitly translated by the second entry.

Instead of using IP Policy objects to set this up, a Stateless Policy should be used instead.

The following table shows the correct configuration of SAT Stateless Policy objects added to the IP rule set for connections to a web server with the private IP address wwwsrv located on a dmz interface.

# Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
1 Allow/SAT any all-nets core wan_ip http-all Destination IP: wwwsrv
2 Allow/SAT dmz wwwsrv any all-nets http-all Source IP: wan_ip

Notice that in the second entry, the source IP is being translated instead of the destination IP since this is the returning traffic.

Example 8.7. Stateless One-to-One SAT Translation Using Stateless Policies

This example repeats Example 8.4, “One-to-One IP Translation Using an IP Policy” but uses stateless policies instead of IP policies. Two policies are needed, one for each direction of traffic flow.

Command-Line Interface

Create a SAT Stateless Policy for inbound traffic: 

Device:/> add IPPolicy Name=stateless_sat_inbound_to_dmz
			SourceInterface=wan
			SourceNetwork=all-nets
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=http-all
			Action=Allow
			SourceAddressTranslation=None
			DestinationAddressTranslation=SAT
			DestinationAddressAction=SingleIP
			DestNewIP=10.0.0.5

Create a SAT Stateless Policy for outbound traffic: 

Device:/> add IPPolicy Name=stateless_sat_outbound_from_dmz
			SourceInterface=dmz
			SourceNetwork=10.0.0.5
			DestinationInterface=any
			DestinationNetwork=all-nets
			Service=http-all
			Action=Allow
			SourceAddressTranslation=SAT
			SourceAddressAction=SingleIP
			SourceNewIP=wan_ip

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create a SAT Stateless Policy for inbound traffic:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > Stateless Policy
  2. Now enter:
    • Name: stateless_sat_inbound_to_dmz
    • Action: Allow
  3. Under Filter enter:
    • Source Interface: wan
    • Source Network: all-nets
    • Destination Interface: core
    • Destination Network: wan_ip
    • Service: http-all
  4. Under Source Translation enter:
    • Address Translation: None
  5. Under Destination Translation enter:
    • Address Translation: SAT
    • Address Action: Single IP
    • New IP Address: 10.0.0.5
  6. Click OK

Create a SAT Stateless Policy for outbound traffic:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > Stateless Policy
  2. Now enter:
    • Name: stateless_sat_http_outbound_from_dmz
    • Action: Allow
  3. Under Filter enter:
    • Source Interface: dmz
    • Source Network: 10.0.0.5
    • Destination Interface: wan
    • Destination Network: all-nets
    • Service: http-all
  4. Under Source Translation enter:
    • Address Translation: None
  5. Under Source Translation enter:
    • Address Translation: SAT
    • Address Action: Single IP
    • New IP Address: wan_ip
  6. Click OK

8.4.6. Combining SAT with NAT

Sometimes SAT must be combined with NAT in a single IP policy where not only the destination IP address must be changed with SAT but also the source IP address must be changed with NAT so the destination of the traffic can send its reply back to the sender.

This issue was mentioned at the end of Section 8.4.2, One-to-One IP Translation where clients sending HTTP/HTTP requests to a web server are on the same internal network as the server. It is never recommended to have clients and server on the same network but it could arise.

Note that the issue of clients accessing a public server on the same protected network is also discussed in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324736394

An Example Scenario

The following IPv4 addresses will be assumed to explain the problem:

  • wan_ip (203.0.113.10): the firewall's public IPv4 address
  • lan_ip (10.0.0.1): the local network's private IPv4 address
  • wwwsrv_ip (10.0.0.2): the web server's private IPv4 address
  • client_ip (10.0.0.3): the local client's private IPv4 address

The diagram below illustrates the topology of the network which uses these IP addresses.

Combining SAT with NAT in an IP Policy

Figure 8.5. Combining SAT with NAT in an IP Policy

Also assume that the following single IP policy exists to SAT traffic arriving at public wan_ip address to the private wwwsrv_ip address of the web server.

# Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
1 Allow/SAT any all-nets core wan_ip http-all Destination IP: wwwsrv_ip

This IP policy will not work for traffic coming from clients on the same network as the web server. The reason is that when such a client receives the reply, the source address will not match the IP address to which the request was sent. This results in the client ignoring the reply. The following sequence of events explains why this occurs:

  1. The local client performs a public DNS lookup for the web server IP and then sends an HTTP request to wan_ip to reach the web server.

    10.0.0.3:1038 => 203.0.113.10:80

  2. The SAT IP policy 1 allows the traffic and translates the destination address to wwwsrv_ip:

    10.0.0.3:1038 => 10.0.0.2:80

  3. The server at wwwsrv_ip processes the request and replies to the original client address:

    10.0.0.2:80 => 10.0.0.3:1038

    However, the reply will travel to the client across the local network, bypassing the firewall.

  4. The client expects a reply from 203.0.113.10:80 and not 10.0.0.2:80 so the response is discarded by the client and it will continue to wait for a response from 203.0.113.10:80, which will never arrive.

One possible solution to the problem is for the client to communicate directly to the web server since they are on the same network. However, this would require an internal DNS server so that the client could discover the private address of the web server.

A better solution is to add a second IP policy which applies NAT to the client traffic so the source becomes wan_ip and also applies SAT so the destination becomes wwwsrv_ip. This new IP policy is shown in the table below:

# Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
1 Allow/SAT any all-nets core wan_ip http-all Destination IP: wwwsrv_ip
2 Allow
NAT/SAT 		lan lan_net core wan_ip http-all Destination IP: wwwsrv_ip (SAT)
Source IP: wan_ip (NAT)

The sequence of events would now become the following:

  1. The client sends traffic to wan_ip in order to reach the webserver:

    10.0.0.3:1038 => 203.0.113.10:80

  2. cOS Core translates the connection in accordance with rule 2

    10.0.0.1:32789 => 10.0.0.2:80

  3. The server at wwwsrv_ip processes the traffic and replies:

    10.0.0.2:80 => 10.0.0.1:32789

  4. The reply is processed by cOS Core so that the translation rules are applied in the reverse order and it arrives at the client with the expected source address:

    203.0.113.10:80 => 10.0.0.3:1038

    The client now has the reply it was expecting from the correct source IP address.

The example below shows exactly how this new NAT/SAT IP policy would be created.

Example 8.8. Combining SAT with NAT in an IP Policy

This example shows how the combined SAT/NAT IP policy is created to solve the problem of HTTP clients needing to access a web server which is located on the same network. The network setup shown in Figure 8.5, “Combining SAT with NAT in an IP Policy” will be assumed, where both clients and the server are on the lan_net network.

Command-Line Interface

Create a SAT IP Policy:

Device:/> add IPPolicy Name=sat_nat_http
			SourceInterface=lan
			SourceNetwork=lan_net
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=http-all
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP
			DestinationAddressTranslation=SAT
			DestinationAddressAction=SingleIP
			DestNewIP=wwwsrv_ip

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create a SAT IP policy:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
  2. Now enter:
    • Name: sat_nat_http
    • Action: Allow
  3. Under Filter enter:
    • Source Interface: lan
    • Source Network: lan_net
    • Destination Interface: core
    • Destination Network: wan_ip
    • Service: http-all
  4. Under Source Translation enter:
    • Address Translation: NAT
    • Address Action: Outgoing Interface IP
  5. Under Destination Translation enter:
    • Address Translation: SAT
    • Address Action: Single IP
    • New IP Address: wwwsrv_ip
  6. Click OK

Configuring NAT/SAT Using the Automatic Translation Option

It is also possible to configure NAT and SAT together in a single IP Policy to solve the internal clients problem. This is done by using the Auto option for the IP policy's source translation. This is explained further in Section 8.5, Automatic Translation and can be used to allow protected clients access to a protected webserver, whether they are on the same network as the server or not.

8.4.7. 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 specified and the original port number was used by default. If the port number is specified, both the IP address and the port number can be translated.

Only one-to-one and many-to-many port translation can be performed with port translation. It is not possible to perform many-to-one port translation.

Enabling Port Mapping

To enable port mapping, the Port Action property of the SAT IP policy must be specified as either Single Port or Transposed. Both of these values require a port number to be specified for either the new single port number for one-to-one translation or a base port number for many-to-many translation.

Port Mapping Rules for the Service Used

The following rules should be noted for how port mapping functions with the Service object assigned to an IP policy that will perform SAT translation:

  • If the Service object used with the IP rule set entry does not have a single value or simple range specified for its port property, port translation will never be performed.

    The term simple range means a range with only a lower and upper value or a single value. For example, 50-60 is a simple range.

  • If the Port Action is specified as Single Port with a value for New Port, and the Service object used has a single number for its port property, then all connections will be translated to the new port number.

  • If the Port Action is specified as Transposed with a Base Port value, and the Service object has a simple number range for its port property, then all connections will be transposed to a new range which begins with the base port number.

An Example of Port Translation

Consider the following SAT IP policy that has a Service object associated with it which has the simple port range 80-85. The entry specifies that the destination address wwwsrv_pub will be translated to wwwsrv_priv. In addition, the port action is set to Transposed with the Base Port set to 1080 so only the ports will be subject to a many-to-many translation.

# Action Src Iface Src Net Dest Iface Dest Net Service SAT Action
1 Allow/SAT any all-nets wan wwwsrv_pub TCP 80-85 Destination IP: wwwsrv_priv
Action: Transposed
Base Port:1080

This rule set entry produces a many-to-many translation of all ports in the range 80-85 to the range 1080-1085. For example, the following would happen:

  • Attempts to communicate with the web server's public address - port 80, will result in a connection to the web server's private address - port 1080.

  • Attempts to communicate with the web server's public address - port 84, will result in a connection to the web server's private address - port 1084.

If the Service was changed so that only the single port value 80 was specified for its Port property then the IP rule set entry would only trigger for port 80 and it would always be translated to the new port 1080 (a one-to-one relationship)

Example 8.9. Port Translation Using an IP Policy

This example repeats Example 8.4, “One-to-One IP Translation Using an IP Policy” but uses a custom service that allows protocols connecting on ports 80 to 85. It also performs a many-to-many port mapping so the destination port range 80-85 becomes the range 1080-1085.

Note that a protocol would also need to be assigned to the service object created if any ALGs were going to be used with the IP policy.

Command-Line Interface

Create a custom service:

Device:/> add Service ServiceTCPUDP my_sat_service
			Type=TCP
			DestinationPorts=80-85

Create a SAT IP policy:

Device:/> add IPPolicy Name=sat_port_translate
			SourceInterface=wan
			SourceNetwork=all-nets
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=my_sat_service
			Action=Allow
			SourceAddressTranslation=None
			DestinationAddressTranslation=SAT
			DestinationAddressAction=SingleIP
			DestNewIP=10.0.0.5
			DestPortAction=Transpose
			DestBasePort=1080

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create a custom service:

  1. Go to: Local Objects > Services > Add > TCP/UDP service
  2. Now enter:
    • Name: my_sat_service
    • Type: TCP
    • Destination port: 80-85
  3. Click OK

Create a SAT IP policy:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
  2. Now enter:
    • Name: sat_port_translate
    • Action: Allow
  3. Under Filter enter:
    • Source Interface: wan
    • Source Network: all-nets
    • Destination Interface: core
    • Destination Network: wan_ip
    • Service: my_sat_service
  4. Under Source Translation enter:
    • Address Translation: None
  5. Under Destination Translation enter:
    • Address Translation: SAT
    • Address Action: Single IP
    • New IP Address: 10.0.0.5
    • Port Action: Transposed
    • Base Port: 1080
  6. Click OK

Changing the Destination Port but not the Destination Network

An article in the Clavister Knowledge Base discusses the issue of just changing the destination port of a new connection but not the destination network. It can be found at the following link:

https://kb.clavister.com/324736069

8.4.8. Protocols Handled by SAT

Generally, SAT can handle all protocols that allow address translation to take place. However, there are protocols that can only be translated in special cases, and other protocols that cannot be translated at all.

Protocols that are impossible to translate using SAT are most likely also impossible to translate using NAT. The reasons for this include the following:

  • The protocol cryptographically requires that the addresses are unaltered. This applies to many VPN protocols.

  • The protocol embeds its IP addresses inside the TCP or UDP data level and requires that the addresses visible on the IP level are the same as those embedded in the data. Examples of this include FTP.

  • Either party is attempting to open new dynamic connections to the addresses visible to that party. In some cases, this can be resolved by modifying the application or the cOS Core configuration.

There is no definitive list of what protocols can or cannot be address translated. A general rule is that VPN protocols cannot usually be translated. In addition, protocols that open secondary connections in addition to the initial connection can be difficult to translate.

Some protocols that are difficult to address translate may be handled by specially written algorithms designed to read and/or alter application data. These are commonly referred to as Application Layer Gateways or Application Layer Filters. cOS Core supports a number of such Application Layer Gateways and for more information please see Section 6.1, ALGs.

8.4.9. SAT Setup Using IP Rules

SAT Requires Multiple IP Rules

SAT translation with IP rules 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 IP rule set search continues for a matching Allow, NAT or FwdFast IP rule. Only when cOS Core finds such a second matching rule is the SAT IP rule applied to the traffic. Contrast this with using IP policies where only a single IP Policy object is needed.

The SAT rule only defines the translation that is to take place. The second, associated IP rule, will actually allow the traffic to flow.

The Second Rule Triggers on the Untranslated IP Address

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.

For example, if a SAT rule translates the destination IPv4 address from 192.168.0.1 to 172.16.0.1 then the second associated rule should allow traffic to pass to the destination 192.168.0.1 and not 172.16.0.1.

Only after the second rule triggers to allow the traffic, is the route lookup then done by cOS Core on the translated destination address to work out which interface the traffic should be sent from.

SAT IP Rule Properties

A SAT IP rule is similar to other types of IP rules in that it triggers on a combination of source network/interface plus destination network/interface plus service. A SAT IP rule has the following additional properties:

  • SAT Translate

    This specifies the address that will be changed and can be one of:

    1. Destination IP - The original destination IP will be translated.

    2. 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-One Mapping

    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.

Example 8.10. One-to-One IP Translation Using IP Rules

This example repeats Example 8.4, “One-to-One IP Translation Using an IP Policy” but uses IP rules instead of IP policies.

Command-Line Interface

Create a SAT IP rule:

Device:/> add IPRule Action=SAT
			SourceInterface=wan
			SourceNetwork=all-nets
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=http-all
			SATTranslate=DestinationIP
			SATTranslateToIP=10.0.0.5
			Name=SAT_HTTP_To_DMZ

Then create a corresponding Allow rule: 

Device:/> add IPRule Action=Allow
			SourceInterface=wan
			SourceNetwork=all-nets
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=http-all
			Name=Allow_HTTP_To_DMZ

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

First create a SAT rule:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Rule
  2. Specify a suitable name for the rule, for example SAT_HTTP_To_DMZ
  3. Now enter:
    • Action: SAT
    • Service: http-all
    • Source Interface: wan
    • Source Network: all-nets
    • Destination Interface: core
    • Destination Network: wan_ip
    • SAT Translate: Destination IP
    • New IP Address: 10.0.0.5
  4. Click OK

Then create a corresponding Allow rule:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Rule
  2. Specify a suitable name for the rule, for example Allow_HTTP_To_DMZ
  3. Now enter:
    • Action: Allow
    • Service: http-all
    • Source Interface: wan
    • Source Network: all-nets
    • Destination Interface: core
    • Destination Network: wan_ip
  4. Click OK

Example 8.11. Many-to-Many SAT Translation Using IP Rules

This example repeats Example 8.5, “Many-to-Many SAT Translation Using an IP Policy” but uses IP rules instead of IP policies.

Command-Line Interface

Create an address object for the public IPv4 addresses: 

Device:/> add Address IP4Address wwwsrv_pub
			Address=203.0.113.1-205.0.113.5

Now, create another object for the base of the web server IP addresses: 

Device:/> add Address IP4Address wwwsrv_priv_base Address=10.0.0.5

Publish the public IPv4 addresses on the wan interface using ARP publish. One ARP object is needed for every public IP address: 

Device:/> add ARP Interface=wan IP=203.0.113.1 mode=Publish

Repeat this for all the remaining public IPv4 addresses.

Create a SAT rule for the translation: 

Device:/> add IPRule Action=SAT
			SourceInterface=any	
			SourceNetwork=all-nets
			DestinationInterface=wan
			DestinationNetwork=wwwsrv_pub
			Service=http-all
			SATTranslateToIP=wwwsrv_priv_base
			SATTranslate=DestinationIP

Finally, create an associated Allow Rule: 

Device:/main> add IPRule Action=Allow
			SourceInterface=any
			SourceNetwork=all-nets
			DestinationInterface=wan
			DestinationNetwork=wwwsrv_pub
			Service=http-all

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create an address object for the public IPv4 address range:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_pub
    • IP Address: 203.0.113.1-205.0.113.5
  3. Click OK

Now, create another address object for the base of the web server IP addresses:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_priv_base
    • IP Address: 10.0.0.5
  3. Click OK

Publish the public addresses on the wan interface using ARP publish. One ARP item is needed for every IP address:

  1. Go to: Network > Interfaces and VPN > ARP/Neighbor Discovery > Add > ARP/Neighbor Discovery
  2. Now enter:
    • Mode: Publish
    • Interface: wan
    • IP Address: 203.0.113.1
  3. Click OK and repeat the other public IPv4 addresses

Create a SAT rule for the translation:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Rule
  2. Specify a suitable name for the rule, for example SAT_HTTP_To_DMZ
  3. Now enter:
    • Action: SAT
    • Service: http-all
    • Source Interface:any
    • Source Network: all-nets
    • Destination Interface: wan
    • Destination Network: wwwsrv_pub
    • SAT Translate: Destination IP
    • New IP Address: wwwsrv_priv
  4. Click OK

Finally, create a corresponding Allow rule:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Rule
  2. Specify a suitable name for the rule, for example Allow_HTTP_To_DMZ
  3. Now enter:
    • Action: Allow
    • Service: http-all
    • Source Interface:any
    • Source Network: all-nets
    • Destination Interface: wan
    • Destination Network: wwwsrv_pub
  4. Click OK

Example 8.12. All-to-One SAT Translation Using IP Rules

This example repeats Example 8.6, “Many-to-One SAT Translation Using an IP Policy” but uses IP rules instead of IP policies.

Command-Line Interface

Create an address object for the public IPv4 addresses: 

Device:/> add Address IP4Address wwwsrv_pub
			Address=203.0.113.6-203.0.113.9

Now, create another object for the web server's private IP addresses: 

Device:/> add Address IP4Address wwwsrv_priv Address=10.0.0.5

Publish the public IPv4 addresses on the wan interface using ARP publish. A CLI command like the following is needed for each public IP address: 

Device:/> add ARP Interface=wan IP=203.0.113.6 mode=Publish

Repeat this command for the other public IP addresses.

Create a SAT IP rule for the translation: 

Device:/> add IPRule Action=SAT
			SourceInterface=any	
			SourceNetwork=all-nets
			DestinationInterface=wan
			DestinationNetwork=wwwsrv_pub
			Service=http-all
			SATTranslateToIP=wwwsrv_priv
			SATTranslate=DestinationIP
			SATAllToOne=Yes

Finally, create an associated Allow rule: 

Device:/> add IPRule Action=Allow
			SourceInterface=any
			SourceNetwork=all-nets
			DestinationInterface=wan
			DestinationNetwork=wwwsrv_pub
			Service=http-all

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Create an address object for the public IPv4 address range:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_pub
    • IP Address: 203.0.113.6-205.0.113.9
  3. Click OK

Now, create another address object for the web server's private IP address:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: wwwsrv_priv
    • IP Address: 10.0.0.5
  3. Click OK

Publish the public addresses on the wan interface using ARP publish. One ARP item is needed for every IP address:

  1. Go to: Network > Interfaces and VPN > ARP/Neighbor Discovery > Add > ARP/Neighbor Discovery
  2. Now enter:
    • Mode: Publish
    • Interface: wan
    • IP Address: 203.0.113.6
  3. Click OK and repeat the other public IPv4 addresses

Create a SAT IP rule for the translation:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Rule
  2. Specify a suitable name for the rule, for example SAT_HTTP_To_DMZ
  3. Now enter:
    • Action: SAT
    • Service: http-all
    • Source Interface: any
    • Source Network: all-nets
    • Destination Interface: wan
    • Destination Network: wwwsrv_pub
    • SAT Translate: Destination IP
    • New IP Address: wwwsrv_priv
    • Enable the option: All-to-One
  4. Click OK

Finally, create an associated Allow rule:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Rule
  2. Specify a suitable name for the rule, for example Allow_HTTP_To_DMZ
  3. Now enter:
    • Action: Allow
    • Service: http-all
    • Source Interface: any
    • Source Network: all-nets
    • Destination Interface: wan
    • Destination Network: wwwsrv_pub
  4. Click OK
Home  Prev   Next