At this point we finally move on to the more realistic or at least more common setups, where the machine with a firewall configured also acts as a gateway for at least one other machine.
The other machines on the inside may of course also run firewall software, but even if they do, it does not affect what we are interested in here to any significant degree.
In the single machine setup, life is relatively simple. Traffic you create should either pass or not out to the rest of the world, and you decide what you let in from elsewhere.
When you set up a gateway, your perspective changes. You go from the "me versus the network out there" setting to "I am the one who decides what to pass to or from all the networks I am connected to". The machine has several, or at least two, network interfaces, each connected to a separate net.
Now it's very reasonable to think that if you want traffic to pass from the network connected to xl1 to hosts on the network connected to xl0, you will need a rule like
pass in on xl1 from xl1:network to xl0:network \
port $ports keep statewhich keeps track of states as well.
However, one of the most common and most complained-about mistakes in firewall configuration is not realizing that the "to" keyword does not in itself guarantee passage all the way there. The rule we just wrote only lets the traffic pass in to the gateway on the internal interface. To let the packets get a bit further you would need a matching rule which says
pass out on xl0 from xl1:network to xl0:network \
port $ports keep stateThese rules will work, but they will not necessarily achieve what you want.
If there are good reasons why you need to have rules which are this specific in your rule set, you know you need them and why. For the basic gateway configurations I'll be dealing with here, what you really want to use is probably a rule which says
pass from xl1:network to any port $ports keep state
to let your local net access the Internet and leave the detective work to the antispoof and scrub code. They are both pretty good these days, and we will get back to them later. For now we just accept the fact that for simple setups, interface bound rules with in/out rules tend to add more clutter than they are worth to your rule sets.
For a busy network admin, a readable rule set is a safer rule set.
For the remainder of this tutorial, with some exceptions, we will keep the rules as simple as possible for readability.