Setting up Static Conduits Through the Firewall

1. Add an IP alias on the appropriate external interface with the public address you wish to use for STATIC_INSIDE_OUTSIDE. [e.g. ifconfig eth0:0 <2nd public address> netmask <mask>].
2. Add entry in STATIC_INSIDE_OUTSIDE.
3. Run the firewall.

Public addresses for static conduits must be a part of the same network as the address configured on the original interface.

When mapping a network of external addresses onto a network of internal addresses, it is important to note the following:

• This case requires that both network definitions are the same size and have the same fourth octet.
• This case does not support mapping an address pool larger than a class C network (255 hosts).
• This case is the equivalent of entering each address in a separate STATIC_INSIDE_OUTSIDE definition, therefor:
• Each address in the external network must be configured on an IP alias.

Note: If you are using FIREWALL_IP, then these IP Aliases should be created on the DMZ interface (or internal interface if you have NAT_EXTERNAL disabled). This will allow the STATIC_INSIDE_OUTSIDE definitions to be available from the DMZ and special routes in your next-hop router, required for FIREWALL_IP, will allow traffic to flow through the Linux firewall correctly.

Using Command Line Arguments

Version 2.0rc11 and later

For command line argument help use:

./rc.firewall help

For firewall status use:

./rc.firewall status

All versions

Use the 'clear' argument to completely unload all firewall rules from the system.

./rc.firewall clear

The following arguments deal with saving/loading a configuration to/from a separate file. The 'save' argument intelligently saves critical configuration information to /etc/firewall.conf. If you append an optional filename, it will write to that file. This file is relative to your current working directory, not the location of rc.firewall, so you might want to pass it a fully qualified path.

./rc.firewall save [filename]
./rc.firewall load [filename]

Configuration files written by older versions of rc.firewall (versions 2.0rc4 and up) can be updated to the latest external configuration format with the 'update' command line argument and can also be passed an optional filename if you wish to update a file other than the default /etc/firewall.conf.

./rc.firewall update [filename]

The script does support SysV style initialization. The 'start' and 'restart' arguments are equivalent to using no arguments at all and 'stop' has the same effect as 'clear'.

./rc.firewall start
./rc.firewall stop
./rc.firewall restart

If you only wish to do sanity checking without actually enabling the firewall you can use the 'check' argument.

./rc.firewall check

"fast mode" allows you to bypass most sanity checking operations and configure your firewall very rapidly in a manner similar to using 'iptables-restore'. This is especially useful for slower computers or complicated firewall configurations that take a long time to configure. Because of the lack of system inspection, this option is only for systems with a static configuration, i.e. no updates to firewall options, and no changes in network configuration. This option requires an external configuration file to work. Therefore you must run './rc.firewall save' to save your firewall configuration before you will be able to use the 'fast' argument. If you edit the firewall.conf file by hand, make sure you run './rc.firewall update' before using fast mode. As with the other options, if you want to use a configuration file saved to a location other than the default /etc/firewall.conf, then you can specify the location the command line.

./rc.firewall fast [filename]

The DUMP_TCP_ON_INIT option leaves extra rules in your firewall configuration which are unnecessary after the offending connections have been dropped. These rules can be expunged from the running firewall configuration using the 'cleanup' command line argument. Running './rc.firewall cleanup' has no other effect on the current firewall configuration.

./rc.firewall cleanup

Access Control

Outbound access control is divided up into five layers. While this method may not be as elegant as a pure access-list, it is simple and covers most applicable scenarios. Here are the layers:

1. Packets inbound internal interfaces are blocked by default.
   
2. Packets are allowed if they have a source address from a routed network. (see below)
   
3. Packets are blocked if they match criteria found in DENY_OUTBOUND.
   
4. Packets are allowed if they are from a host or network listed in PERMIT.
   
5. Packets are blocked if they are to or from an address or network listed in BLACKLIST.

Selecting Packets to Route

Adding an interface to the INTERNAL_INTERFACES directive will permit routing based on the following criteria:

1. The packet is received on an internal interface and its source address is from the network to which that interface is connected. The network is determined by meshing the IP address and netmask of the interface obtained from the output of 'ifconfig' for all IP addresses assigned to the interface.
   -or-
2. The packet is received from a network or host listed in ADDITIONAL_ROUTED_NETWORKS and is received on any internal interfaces.
   -or-
3. The packet is received on an internal interface that is listed as a dynamic interface. In this case, ALL connections received on the interface are permitted, regardless of source address.

A feature of the firewall is the ability to have IP aliases assigned to an external interface (anything not listed as an internal interface) and then list the interface as a dynamic interface. The result is that the firewall consults the kernel routing table to determine what address to use when doing source NAT on the outgoing connections. This is because the 'MASQUERADE' target is used in lieu of the 'SNAT' target. In short, if you have multiple IP addresses, you can change your identity based on where you are connecting.

Port Forwarding

The port forwarding code is designed to handle the issue of how port forwarding normally breaks down when the destination host is on the same network as the originating host. In this case usually you would have to source NAT (in addition to destination NAT) every packet that is forwarded in order to prevent a routing triangle where the destination host replies directly to originating host which then discards the reply because it does not recognize the source address, excepting a reply to come from the same host to which it sent the original data. This occurs because connection tracking on the firewall does not have a chance to demasquerade the response packet as it do not pass through the firewall on its return path. To source NAT all packets would fix the triangular routing problem, but it also would also mask the true source address for ALL port forwarded connections passing through the firewall. For many applications, this behavior is not acceptable, for example for an internal webserver. The obvious solution is to source NAT only packets which go out the same interface they came in on. This would be simple if we could do something like:

iptables -t nat -A POSTROUTING -<stuff_to_match_port_forwards> -i <an interface> \
         -o <the same interface> -j SNAT --to-source <interface_ip_address>

Note that the firewall will only port forward packets destined for addresses which are not in use by STATIC_INSIDE_OUTSIDE and in assigning addresses it recognizes the FIREWALL_IP feature and adjusts its behavior accordingly.