Useful Tricks

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

How to generate firewall policy for many hosts

Suppose you use fwbuilder to generate policy for the firewall running on a server. How can fwbuilder help you generate a policy for it and how can you do it if you have a hundred of servers like that ?

For example, you could run a firewall locally on the web server that should be accessible to anyone on protocol HTTP, but other protocols used to publish content and manage the machine should be open only to a limited number of IP addreses. To configure such firewall running on a host in fwbuilder, create a firewall object and configure it with interfaces as usual. You will need to create a loopback interface and ethernet (if that's Linux machine, then it will be “eth0”). This firewall object now represents your server with firewall running on it. You can either add rules manually, or use the Druid to build the basic policy. Most likely you won't need NAT rules there, although there are some cases where NAT rules may be useful too. Compile the policy and transfer it to the server using fwbinstaller as usual. That's it.

This procedure gets really tiresome if you need to repeat it many times. This is so if you have a whole farm of servers and need to generate and install firewall policy on each one of them. The following trick helps simplify the process if the servers are very similar (like a web servers farm) and use identical firewall policy.

You need to create a firewall obejct as described above, except its interface “eth0” should be marked as “dynamic”. Do not add an address object with IP address to it, just make it look like it gets IP address dynamically. Even if in reality it is configured statically, you make fwbuilder believe it is dynamic. In this case generated firewall script will determine actual address of the interface and then use it in the policy rules, which allows you to run the same script on many servers with different addresses. You will need to copy firewall script from the management workstation to the servers by hand or using some custom script. This should not be difficult though if you use ssh and RSA nr DSA keys.

Using Empty Groups

This example shows how option “Ignore empty groups” can be used to build a rule controlling access to or from an often changing group of computers. Suppose we need to set up a rule to control access to or from group of computers. In principle this should be easy: we create Host object for each computer, then create a group and put all these Host objects in it. We can use this group in Source or Destination of the policy rule to achieve our goal. If we ever need to add new machine to the control list, we create a new Host object and add it to the group; if we need to remove the machine from the list, we just remove it from the group. But what should happen if after the last machine has been removed the group becomes empty? If the empty group is in the Source of the rule, shouldn't the compiler treat it as “Any”? I admit this is confusing to say the least.

Here is how it works in Firewall Builder. The behavior of the compiler is controlled by the checkbox “Ignore empty groups in rules” in the “Firewall“ tab of the firewall object dialog. If this checkbox is off, then compiler treats empty groups as an error and stops processing of the ruleset as soon as it encounters such group. This is the default setting. However, if this checkbox is on, then compiler simply removes empty group from the rule and continues processing. This makes sense, since an empty group defines no objects and if the rule element has some other objects in it, removing an empty group does not change its meaning. It becomes tricky when the empty group is the only object in the rule element though. In this case removing the group from the rule element makes it empty, which is equivalent to “any”. All of the sudden, instead of controlling access to or from a group of hosts the rule expands its action to any host! To avoid this unexpected side effect, compiler drops a rule if rule element becomes empty after the last empty group has been removed. Again, it works this way only if the checkbox “Ignore empty groups” is on.

For example this feature can be used to set up a rule to control Internet access from a bunch of a studen't computers. Suppose some studends may be denied access once in a while, in which case their machine is removed from the group. If at some point of time all machines were removed from the group, the compiler would simply ignore this rule instead of inadvertently creating a hole in the policy.

How to use fwbuilder to configure the firewall using PPPoE

If your Internet connection uses PPPoE protocol, then your firewall should be configured with interface ppp0.

With PPPoE the connection is established using PPP protocol that works on top of the usual ethernet. As the result, the firewall gets interface ppp0 besides interface eth0 and eth1 that correspond to its "normal" physical network adapters. Hereis how you can use Firewall Builder to configure such firewall (assuming interface eth0 is connected to the DSL link and eth1 is connected to internal LAN):

  • create firewall object in the GUI
  • add interfaces ppp0 and eth1. You can simply skip eth0 as it does not have an IP address and never sees IP packets
  • If you have a static IP address with your Internet connection, mark ppp0 as “static” and add an address object to it, configure the address object with the IP address
  • If your Internet connection uses dynamic IP address, mark ppp0 as “dynamic” and do not add an address object to it. Create script /etc/ppp/ip-up to restart the firewall every time IP address of ppp0 changes (see here for details).
 

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