When planning firewall configurations the first thing you want to do is to plan meticulously what you want to achieve. Planning is of the utmost importance here, otherwise you end up with an unmanageable system in very short time.

First: what is a firewall?

A firewall operates similar to a router, though unlike a router not on layer 3 of the OSI reference model but on layer 4. That is: it has (at least) 2 network interfaces, one "inside" and one "outside". They represent 2 different layer-3 areas (like the interfaces of a router represent different layer-2 areas, so-called collision domains), which would be connected via a common layer-4. "Would be", because per default this layer 4 is completely closed by the firewall software. No package coming in on one interface could leave through the other. Firewall rules now define exceptions to this, so that certain appointed packages in fact can go through and this way connections become possible.


What is so special at this layer 4?

At layer 3 we have one protocol, which dominates traffic: IP. There are other protocols (ICMP, which you can see at work if you use "ping", for instance), but the data transfer itself - the part which the user really care for - is done via IP. IP packages now are used to transport mostly 2 protocols: TCP and UDP. Because UDP has no flow control its use has dwindled for a long time and most of the packets (about 90%) are TCP packets. Inside these TCP packets certain services transport their information: telnet, ssh, ftp, NFS, .... See the extempore for more information about what happens to a packet.

Like IP has an addressing schema to know what belongs where (the "IP address"), layer 4 also has its addressing means: the port. Ports are 16-bit numbers and range from 1-65535. Port numbers below 1024 are so-called "well known services" and only processes running under "root"s user-ID can use these ports. So, like "123.123.123.123" denotes a certain host, "123.123.123.123:1234" denotes a certain port on a certain host. This combinaton of IP address and port number is called a "socket".

Why is this relevant? Because behind each port can listen a "daemon" - or not. If not, then a communication simply won't come to pass. If you try to reach a system via telnet which has no "telnetd" running you will get the "connection refused" error - without any firewall or other security. All the usual means of connecting to a system are on such fixed ports with small numbers - hence the name "well-known services". Have a look in /etc/services to see them.

And what does all that have to do with firewalls?

Now, that we have covered the grounds: firewall rules will allow access from a certain (range of) socket(s) to a (certain range of) socket(s). Rules are always one-way: if IP-A:A is allowed to connect to IP-B:B that does not mean that IP-B:B is allowed to connect to IP-A:A.

Notice that a daemon has to be contacted on its original port but usually shifts communication away from this port when establishing the connection, mainly to be able to serve other incoming requests. These other ports are typically outside the WKS-range 0-1024. It is a good idea therefore to allow the ports above 1024 in both directions and make sure no service is open on any system on your network in this range per default.

____________________
A little extempore: what happens in networks:

For example: you use "telnet" to connect to another host:

"telnet" (the software) puts its information into telnet protocol packets
which are then packed into TCP packets for transmission
which are then packed into IP packets for transmission
which are then packed into, say, 802.3-frames and transmitted over Ethernet

now, on the other side:

the 802.3-frames are transmitted to a router
there, the IP packet is reassembled and relayed to another network
repacked in, say, 802.11-frames because this network is a WLAN

received by the host and unpacked, getting IP packets
unpacked these IP packet and store it in the TCP reassemble buffer (no flow control for IP)
reassembled the orderly queue of TCP packets and
unpacked the TCP packets to get telnet messages
pass these to the telnetd-daemon


So far a little introduction to firewall workings. If you need more detail and help on specific topic just ask.

I hope this helps.

bakunin