8.3.2.1.1. Basic Source Address Translation Rule

Source address translation is useful when you need to let machines using private address space (e.g., as defined in RFC1918) access the Internet. The firewall manipulates the source address of IP packets to make them appear to come from one of the public addresses assigned to the firewall instead of coming from the actual, private address on the internal network.

In the following examples we will use a firewall object configured as follows:

The external interface of the firewall is eth0, it has a static IP address 192.0.2.1 (this is an example address, normally external interface would have a publicly routable address).

The simplest source address translation rule looks like this:

We put the interface of the firewall into Translated Src and an object representing the internal network in the Original Src element of the rule. This tells the firewall to replace the source address of packets that match the "Original" side of the rule with the address of the interface eth0.

This rule translates into the following simple iptables command:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A POSTROUTING -o eth0  -s 172.16.22.0/24  \
    -j SNAT --to-source 192.0.2.1 

  

Note that Firewall Builder uses the chain POSTROUTING for the source address translation rules. It will use PREROUTING for the destination translation rules.

For PF, Firewall Builder uses nat rule:

# Rule  0 (NAT)
# 
nat on en0 proto {tcp udp icmp} from 172.16.22.0/24 to any -> 192.0.2.1 

  

Finally, for PIX, Firewall Builder knows to use global pool in combination with "nat" command and automatically determines which interfaces to associate global and nat commands with:

! Rule  0 (NAT)
! 
global (outside) 1 interface
access-list id43442X30286.0 permit ip 172.16.22.0 255.255.255.0  any 
nat (inside) 1 access-list id43442X30286.0 tcp 0 0

  

Note that the generated PIX configuration has been optimized and the "global" command takes address from the interface "outside" regardless of how this address is assigned, statically or dynamically.

8.3.2.1.2. Source Address Translation Using Interface with Dynamic Address

The generated configurations in the previous examples used the IP address of the external interface for translation. Let's see what configuration Firewall Builder will produce if the external interface has a dynamic address that is not known at the time when configuration is generated.

The NAT rule looks exactly the same as in examples above: we still put interface eth0 in Translated Src even though its address is unknown.

Iptables uses target MASQUERADE when the source NAT is requested with a dynamic interface. Firewall Builder generates the following command:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A POSTROUTING -o eth0  -s 172.16.22.0/24 -j MASQUERADE  

  

PF supports special syntax for the dynamic interface, (en0), which makes it take the address of the interface automatically:

# Rule  0 (NAT)
# 
nat on en0 proto {tcp udp icmp} from 172.16.22.0/24 to any -> (en0) 

                

There is no difference in the generated PIX configuration because fwbuilder optimizes it and uses the "global (outside) 1 interface" command which takes the address from the outside interface regardless of whether the address is assigned statically or dynamically.

8.3.2.1.3. Port Translation

Firewall Builder can generate configurations for the NAT rules that manipulate not only addresses, but also ports and port ranges. Consider this hypothetical example where we want to squeeze source port range from the whole unprivileged range 1024 - 65535 to rather limited range 10000 - 20000 on all connections from internal network to the server on DMZ:

TCP Service object "sport range 10000-20000" is defined as follows:

For iptables fwbuilder generates the following command for this rule:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A POSTROUTING -o eth+ -p tcp -m tcp  -s 172.16.22.0/24 \
    --sport 1024:65535  -d 192.168.2.10 -j SNAT --to-source :10000-20000 

  

This rule matches source port range "1024-65535" and original destination address 192.168.2.10 and only translates source ports to the range 10000-20000. Firewall Builder generated SNAT rule because the object in the Translated Source requested a change in the source port range. If this object had zeros in the source port range but defined some non-zero destination port range, the program would have generated DNAT rule to translate destination ports.

8.3.2.1.4. Load Balancing NAT Rules

Many firewall platforms can use NAT to perform simple load balancing of outgoing sessions across a pool of IP addresses. To set this up in fwbuilder, we start with an address range object:

We then use it in the "Translated Source" of the NAT rule:

Here is what we get for the iptables firewall:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A POSTROUTING -o eth+  -s 172.16.22.0/24 \
    -j SNAT --to-source 192.0.2.10-192.0.2.20 

                

In case of PIX, fwbuilder builds complex global pool to reflect requested address range:

! Rule  0 (NAT)
! 
global (outside) 1 192.0.2.10-192.0.2.20 netmask 255.255.255.0
access-list id54756X30286.0 permit ip 172.16.22.0 255.255.255.0  any 
nat (inside) 1 access-list id54756X30286.0 tcp 0 0

                

For PF, compiler converted range 192.0.2.10-192.0.2.20 to the minimal set of subnets and produced the following configuration line:

# Rule  0 (NAT)
# 
nat proto {tcp udp icmp} from 172.16.22.0/24 to any -> \
    { 192.0.2.10/31 , 192.0.2.12/30 , 192.0.2.16/30 , 192.0.2.20 } 

                

It is possible to use network object of smaller size in Translated Source which is equivalent to using a small address range:

We can use it in the rule just like the range object:

This yields for PF:

# Rule  0 (NAT)
# 
nat proto {tcp udp icmp} from 172.16.22.0/24 to any -> 192.0.2.0/27

                

Unfortunately, the smaller network object in Translated Source is not supported for iptables because in iptables, SNAT target can only accept a single IP address or a range of addresses, but not a subnet specification.

PF supports different modes of load balancing for rules like this. To add configuration parameters that control this, open the NAT rule options dialog by double-clicking in the column "Options" of the NAT rule:

When option "source-hash" is checked, the generated command becomes

# Rule  0 (NAT)
# 
nat proto {tcp udp icmp} from 172.16.22.0/24 to any -> 192.0.2.0/27 source-hash 

                

8.3.3.1.1. Configuring NAT for the server using an IP address that belongs to the firewall

In case when we have no public IP addresses to spare, we can still use NAT to permit access to the server. In this case we will use address that belongs to the firewall's external interface. Here is a screenshot showing the firewall object, its interfaces and an address object that belongs to the external interface:

We can either use an interface object or a corresponding address object in the rule. The following two examples of rules are equivalent:

Using interface object:

Using an address object:

External interface eth0 of the firewall has just one IP address, therefore these two variants of the NAT rule are equivalent.

If the firewall has multiple public IP addresses, then you can add them as additional Address objects to the external interface object and then use them in the NAT rules. All Address objects attached to an interface are equivalent from a NAT rule standpoint.

Both NAT rules demonstrated in this example provide translation for the destination address of the packet so it can reach the server behind the firewall. We still need a policy rule to actually permit this kind of connection. This rule can be added to the global policy as follows:

You always need a combination of the NAT rule and a policy rule to do both address translation and then permit translated packet.

Here is what Firewall Builder generates for iptables using these NAT and policy rules:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A PREROUTING  -p tcp -m tcp -m multiport   -d 192.0.2.1 \
    --dports 21,25 -j DNAT --to-destination 172.16.22.100 

# Rule 0 (global)
# 
$IPTABLES -A FORWARD  -i + -p tcp -m tcp  -m multiport  -d 172.16.22.100 \
    --dports 21,25  -m state --state NEW  -j ACCEPT 

              

For PF:

# Rule  0 (NAT)
# 
# 
rdr on eth0 proto tcp from any to 192.0.2.1 port 21 -> 172.16.22.100 port 21 
rdr on eth0 proto tcp from any to 192.0.2.1 port 25 -> 172.16.22.100 port 25 

# Rule  0 (global)
# 
# 
pass in quick inet proto tcp  from any  to 172.16.22.100 port { 21, 25 }

              

These are rather standard destination translation rules. Let's look what Firewall Builder generates for the same rules in the GUI when target firewall platform is set to "PIX":

class-map inspection_default
  match default-inspection-traffic

policy-map global_policy
  class inspection_default
    inspect ftp
    inspect esmtp

service-policy global_policy global

clear config access-list
clear config object-group
clear config icmp
clear config telnet
clear config ssh

object-group service outside.id13228X30286.srv.tcp.0 tcp
 port-object eq 21
 port-object eq 25
 exit

! Rule  0 (global)
! 
! 
access-list outside_acl_in  remark 0 (global)
access-list outside_acl_in permit tcp any host 172.16.22.100 object-group 
      outside.id13228X30286.srv.tcp.0 
access-list inside_acl_in  remark 0 (global)
access-list inside_acl_in permit tcp any host 172.16.22.100 object-group 
      outside.id13228X30286.srv.tcp.0 
access-list dmz50_acl_in  remark 0 (global)
access-list dmz50_acl_in permit tcp any host 172.16.22.100 object-group 
      outside.id13228X30286.srv.tcp.0 


access-group dmz50_acl_in in interface dmz50
access-group inside_acl_in in interface inside
access-group outside_acl_in in interface outside

! NAT compiler errors and warnings:
! 

clear xlate
clear config static
clear config global
clear config nat
! 
! Rule  0 (NAT)
! 
! 
access-list id13242X30286.0 permit tcp host 172.16.22.100  eq 21 any 
static (inside,outside) tcp interface 21  access-list id13242X30286.0 tcp 0 0
access-list id13242X30286.1 permit tcp host 172.16.22.100  eq 25 any 
static (inside,outside) tcp interface 25  access-list id13242X30286.1 tcp 0 0

              

PIX configuration is considerably more complex. First, protocol inspectors have been activated to set up protocol support. TCP ports were arranged in an object group that is then used in all rules. Access lists were created and attached to all interfaces with "access-group" commands. Destination address translation in PIX configuration is done using "static" commands, which use small access lists to match packets that should be translated. All of this, however, was generated from exactly the same rules and objects in the GUI. All we did is change the firewall platform in the firewall object dialog and make sure network zones and security levels were configured properly. We did not have to configure two interfaces for each NAT rule for PIX: Firewall Builder figured out which interfaces it should use for the "static" command automatically.

8.3.3.1.2. Configuring NAT for the server using dedicated public IP address

Suppose for some reason you do not want to add an address that should be used for NAT to an interface of the firewall. You can use any Address object in the "Original Destination" even if this Address object is not attached to the interface of the firewall. The problem with this is that the firewall must "own" public address used for NAT in order for it to answer ARP requests for this address from the upstream routers. If the firewall does not "own" the address and does not answer ARP requests, the router will not know where to send packets with this address in destination. To help you solve this problem, Firewall Builder can automatically add virtual address to the firewall's interface when you use an address in a NAT rule. This is controlled by a checkbox Add virtual addresses for NAT in the "Script" tab of the firewall's platform "advanced" settings dialog. If this checkbox is turned on, and you use an address object that does not belong to any interface of the firewall, the program adds a code fragment to the generated script to create virtual address of the interface of the firewall to make sure NAT rule will work. If this is not desired, you can turn this automation off by un-checking this option.

If you use this feature, the NAT rules look exactly the same as shown above, except address objects are taken from the Objects/Addresses branch of the tree instead of the interfaces of the firewall. In case of iptables, generated script adds virtual addresses to the firewall with a label that starts with "FWB:" prefix. This helps the script identify and remove addresses it controls when you remove them in Firewall Builder GUI.

8.3.3.1.3. NAT rules using an address of dynamic external interface

In all previous examples, the external interface of the firewall had a static IP address that was used in the destination address translation rules. But what if the address is dynamic and not known at the time when Firewall Builder processes rules? Let's see what happens.

Configuration of objects used in this example:

The only difference is that interface eth0 of the firewall is dynamic and has no IP address. In order to build NAT rules we use this interface in Original Destination (the rule looks exactly the same as rules in the previous examples):

Firewall Builder uses method specific to the target firewall platform that allows it to use an interface a with dynamic address in policy and NAT rules. For example, iptables script generated by fwbuilder runs commands that retrieve the actual address of the interface and assign it to the shell variable. This variable is then used in iptables commands to build policy and NAT rules. OpenBSD PF permits using of interface name in rules, PIX has special syntax for "nat", "static" and "access-list" commands that also permit using interface in place of the address.

Here is generated iptables script:

getaddr() {
  dev=$1
  name=$2
  L=`$IP -4 addr show dev $dev | grep inet | grep -v :`
  test -z "$L" && { 
    eval "$name=''"
    return
  }
  OIFS=$IFS
  IFS=" /"
  set $L
  eval "$name=$2"
  IFS=$OIFS
}

getaddr eth0  i_eth0

# Rule 0 (NAT)
# 
test -n "$i_eth0" && $IPTABLES -t nat -A PREROUTING   -d $i_eth0 \
     -j DNAT --to-destination 172.16.22.100 

              

It defines function getaddr() that retrieves IP address of a given interface and assigns it to a variable, in this example to i_eth0. The script checks if this variable has a non-empty value and uses it in -d clause of iptables command to match destination address of incoming packet. Generated script checks the value of this variable because, if some interface does not have any address at the moment when script is executed, it should not try to run incorrect iptables command or, worse, install iptables rule matching "any". Either way machine would end up with firewall configuration that would have a meaning different from what was intended.

In PF we can use clause (en0) to make the firewall match address of an interface without having to retrieve the address manually:

# Rule  0 (NAT)
# 
rdr on en0 proto {tcp udp icmp} from any to (en0) -> 172.16.22.100 

              

Generated PIX configuration uses interface clause to match address of the interface:

! Rule  0 (NAT)
! 
access-list id29402X30286.0 permit ip host 172.16.22.100   any 
static (inside,outside) interface  access-list id29402X30286.0 tcp 0 0

              

8.3.3.1.4. Port Translation

Rules shown in examples above only translated the destination address of packets. Sometimes the server uses different ports as well, and the firewall should convert from the standard port numbers to the ones used by the host. For example, the web server might be running on port 8080, but we may want clients to access it using standard port 80. Here is how to do it.

First, we create TCP Service object that defines destination port 8080:

This service object does not have any source port specification. Only the destination port is defined. Now we can use it in the NAT rule as follows:

Firewall Builder generates the following iptables script for this rule:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A PREROUTING  -p tcp -m tcp   -d 192.0.2.1 --dport 80 \
    -j DNAT --to-destination 172.16.22.100:8080 

              

It uses -j DNAT --to-destination <address>:<port> to translate both destination address and destination port.

Here is how this looks for PF:

# Rule  0 (NAT)
# 
rdr on en0 proto tcp from any to 192.0.2.1 port 80 -> 172.16.22.100 port 8080 

              

PIX rules look like this:

! Rule  0 (NAT)
! 
! 
access-list id37125X30286.0 permit tcp host 172.16.22.100  eq 8080 any 
static (inside,outside) tcp interface 80  access-list id37125X30286.0 tcp 0 0