Firewall Builder NAT Rules

SNAT using address of "wrong" interface

Sometimes we need to translate source address of packets using address of the DMZ interface. This is useful when internet provider allocated really small address range to us, which is too smal to split any further, yet we want to use it for a server behind the firewall.

If the range was larger, we could subnet it and use part of it for the external connection of the firewall and another part for DMZ where the server is located. Since the range is really small, we use the whole of it for DMZ and assign a private addresses for the connection between the firewall and a router. The problem with this configuration is that the outbound packets should be translated using address that belongs to DMZ, while in fact these packets go out through different interface. Firewall Builder supports this configuration (although I admit this is not the most elegant solution.)

First, here are the objects we need to create for this case:

The firewall "firewall-2" has three interfaces: eth0 'internal', eth1 'external' and eth2 'DMZ'. Our routable address is 192.0.2.1, this is the address we need to use for our SNAT rule. The trick here is to create a Host object with that address and use it instead of the firewall object, or one of its interfaces, in the "Translated Source" of the NAT rule. In this example this Host object has a name "like fw2 eth2". When interface object is used in TSrc, the compiler automatically restricts the rule to this interface (in the case of iptables, it adds "-o eth1"), however when the host object is used in TSrc, such restriction is not done and generated rule will translate regardless of the egress interface. This is explained in the Firewall Builder Users Guide, chapter 8.2.2.

Here is how our NAT rule looks like:

Here is the code generated for ipfilter for this rule:

#
# Rule 0(NAT)
#
#
map eth2 from 10.1.1.0/24 to 0.0.0.0/0 -> 192.0.2.1/32 portmap tcp/udp auto
map eth0 from 10.1.1.0/24 to 0.0.0.0/0 -> 192.0.2.1/32 portmap tcp/udp auto
map eth1 from 10.1.1.0/24 to 0.0.0.0/0 -> 192.0.2.1/32 portmap tcp/udp auto
map eth2 from 10.1.1.0/24 to 0.0.0.0/0 -> 192.0.2.1/32
map eth0 from 10.1.1.0/24 to 0.0.0.0/0 -> 192.0.2.1/32
map eth1 from 10.1.1.0/24 to 0.0.0.0/0 -> 192.0.2.1/32

The same rule compiled for iptables:

$IPTABLES -t nat -A POSTROUTING -o eth+ -s 10.1.1.0/24 -j SNAT --to-source 192.0.2.1

NAT rules for two servers behind a firewall

Suppose we have two servers behind the firewall and need to provide access to them from outside on different protocols using NAT. In this example we pick two additional IP addresses on the external subnet and map them to servers inside, but do not add these addresses to external interface of the firewall object.

Suppose our two servers are hostA (10.1.1.100) and hostB (10.1.1.111). External addresses we will use to access them are 192.0.2.10 and 192.0.2.11 respectively. To represent these external addresses we create regular host objects hostA-NAT and hostB-NAT. Each host object is going to have an interface (its name can be anything) with an IP address. Here is the configuration of all objects:

Here is how NAT rules look like:

We just put objects hostA-NAT and hostB-NAT in Original Destination element of the NAT rule and put object representing a server in the Translated Destination rule element. These two rules also illustrate how translation can be made narrow so that only packets of certain protocols will match the rule. In this example firewall will translate only packets of protocols http and ftp for server hostA and dns for hostB.

As usual, for this to work we need to add policy rules. We just put them in the global policy, here is how they look like:

Note that we use real server objects in the policy rules rather than objects representing translated addresses. This is because in Firewall Builder NAT happens before policy rules inspect the packet.

Since we did not add addresses hostA-NAT and hostB-NAT to the external interface, the checkbox "Add virtual addressess for NAT" in the Firewall tab of the firewall object dialog must be checked. This checkbox makes policy compiler generate commands that create virtual IP addresses on the external interface of the firewall. This is needed because firewall must answer to ARP requests for these addresses for packets to hit it at all.

NAT rules like these work for all supported firewall platforms.

NAT rules for two servers behind the firewall, using virtual addresses on external interface

We need to provide access to two servers located behind the firewall using NAT. In this example we pick two additional addresses that belong to the external subnet and assign them to the external interface of the firewall in addition to its "normal" address.

These manipulations with IP addresses are necessary because firewall must "own" an address in order to answer to ARP query for it. Without this the packet headed for the address would never reach firewall and all our NAT and policy rules would just sit idle.

Our two servers are hostA (10.1.1.100) and hostB (10.1.1.111). External addresses we will use to access them are 192.0.2.10 and 192.0.2.11 respectively. We just add virtual addresses to the external interface of the firewall eth1 (right mouse click on the interface object in the tree brings up a pop-up menu, use menu item "Add address" from it). Here are all objects used in this example:

The NAT rules:

And the policy rules:

The firewall "owns" translated addresses 192.0.2.10 and 192.0.2.11 because they belong to its external interface eth1. The checkbox "Add virtual addressess for NAT" can be left unckecked in the "Firewall" tab of the firewall object dialog.

NAT rules for two servers behind the firewall, using a single address of external interface

In this example we need to provide access to two servers behind the firewall via NAT using single outside IP address.

We are not going to create virtual addresses because we only have a single address on the outside and it already belongs to the firewall. Here is how objects used in this example look like:

NAT rules:

Policy rules:

Even though connections to two different servers should be accepted on the same IP address outside, the firewall can distinguish them by using protocol and port number information. In this example http and ftp connections are translated and sent to the server hostA, while DNs queries go to the server hostB.

NAT rules for two servers behind the firewall, using an address of dynamic external interface

As in previous examples, we need to provide access to two servers behind the firewall. In this example our firewall not only has a single outside address, this address is dynamic (such as on ADSL or PPPoE connection).

Configuration of objects used in this example:

The only difference is that interface eth1 of the firewall is dynamic and has no IP address. In order to build NAT rules we use object representing this interface in "Original Destination":

Firewall Builder uses method specific to the target firewall platform that allows it to use interface with dynamic address in policy and NAT rules. For example, iptables script generated by fwbuilder runs commands that retrieve 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.

Policy rules are the same as before:

Server behind the firewall, using NAT

In this example we permit access to the server behind the firewall on protocols smtp and ftp. The same rule could be used for the web server if service object 'http' was added to the 'Service' rule element. The server is located on the subnet protected by the firewall, using provate address space as defined in RFC1918, that is one of the following address blocks:

  • 10.0.0.0/255.0.0.0
  • 172.16.0.0/255.240.0.0
  • 192.168.0.0/255.255.0.0

Private addresses are not routable on the Internet, this means the clients out on the Net can not connect to the server using its address if it belongs to one of these address ranges. In order to permit access to the server we need to configure the firewall to convert its private address into publicly routable one, or in other words do Network Address Translation (NAT). In Firewall Builder NAT rules are added in the NAT ruleset which is represented by the object located under the firewall object in the tree:

Doing NAT for the server using dedicated public IP address

The following NAT rule provides translation for the server hostA in case when we own several public IP addresses and can use one exclusively for this server.

This rule says that in all packets coming from any source (OSrc equals Any) headed for the address defined by the Host object hostA-NAT the firewall should translate destination address and make it that of the host hostA. Object hostA-NAT is just a regular host object defined as follows:

We use Host object just as a convenient way to represent an address. The IP address assigned to the interface of this host is 192.0.2.10, which is different from the address of external interface of the firewall (it is 192.0.2.1, see screenshot above showing how firewall object looks like in the tree).

Doing NAT for the server using 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 interface. Here is once again a screenshot showing the firewall object, its interfaces and an address object that blongs to the external interface:

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

Using interface object:

Using an address object:

All 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.

Server behind the firewall, not using NAT

In this example we permit access to the server behind the firewall on protocols smtp and ftp. The same rule could be used for the web server if service object 'http' was added to the 'Service' rule element. The rule #1 is "catch-all", it should always be at the very bottom of the policy to block and log all packets that are not explicitly permitted by the rules above.

 

Copyright © 2000-2008 NetCitadel, LLC. All rights reserved.
  Free CSS Templates.