That will tell you where to get ipfwadm if you don't already have it. There are other tools you can get but I made no progress until I tried ipfwadm. It is nice and low level! You can see exactly what it is doing.

I want to cut the world off from my internal net and do nothing else, so I will want to give as a last (default) rule that the firewall should ignore any packets coming in from the internal net and directed to outside. I put all the rules (in this order) into /etc/rc.d/rc.firewall and execute it from /etc/rc.d/rc.local at bootup.

Before that default rule, I have to place some rules that serve as exceptions to this general denial of external services to internal clients.

I want to treat the firewall machines address on the internal net specially. I will stop people logging in to the firewall machine unless they have special permission, but once they are there they should be allowed to talk to the world.

Check at this point that you can get in to the clients from outside the firewall via telnet, but that you cannot get out. That should mean that you can just about make first contact, but the clients cannot send you any prompts. You should be able to get all the way in if you use the firewall machine as a staging post. Try rlogin and ping too, with tcpdump running on one card or the other. You should be able to make sense of what you see.

I could not make sendmail between the local clients work without a nameserver. Rather than set up a nameserver right then on the firewall, I just lifted the firewall for tcp domain service queries precisely aimed at the nearest existing nameserver and put its address in the clients /etc/resolv.conf ("nameserver 123.456.789.31" on a separate line).

You can find which port number and protocol a service requires with tcpdump. Trigger the service with a an ftp or a telnet or whatever to or from the internal machine and then watch for it on the input and output ports of the firewall with tcpdump:

tcpdump -i eth1 -e host client04

for example. The /etc/services file is another important source of clues. To let telnet and ftp IN to the firewall from outside, you have to allow the local clients to call OUT on a specific port. I understand why this is necessary for ftp - it's the server that establishes the data stream in the end - but I am not sure why telnet also needs this.

There is a particular problem with some daemons that look up the hostname of the firewalling machine in order to decide what is their networking address. Rpc.yppasswdd is the one I had trouble with. It insists on broadcasting information that says it is outside the firewall (on the second card). That means the clients inside can't contact it.

Rather than start IP aliasing or change the daemon code, I mapped the name to the inside card address on the clients in their /etc/hosts.

You want to test that you can still telnet, rlogin and ping from the outside. From the inside you should be able to ping out. You should also be able to telnet to the firewall machine from the inside and the latter should be able to do anything.

That is it. At this point you probably want to learn about rpc/Yellow Pages and the interaction with the password file. The firewalled network wants to run without its unprivileged users being able to log on to the firewall - and thus get out. Some other HOWTO!