Next
Previous
Contents
Until recently, our local network was hooked into the global net
via PPP over a modem. I had installed a firewall using IPChains
(
http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.php)
with this setup and it worked nicely. We recently upgraded to a DSL connection.
I thought it would be trivial to simply switch my firewall to insulate me
from the larger net coming in via the DSL connection. I was wrong.
It took three days of work to finally get it up and running. I found a lot
of suspect information on the net that caused a good deal of confusion.
This mini-HOWTO was written because I suspected that our setup will be a quite
common configuration in the future when DSL becomes more widespread and I wanted to
help people avoid massive frustration.
I guess this is applicable to a cable modem setup, but YMMV as I know nothing
about cable modem hookups.
The problem I am trying to solve is to configure the system such
that the firewall code in the kernel (that is manipulated with
ipchains) can be used to filter the packets that travel back and
forth between the outside world and the local network. I also needed
some of the local machines to be "seen" on the global net (though always
filtered through the firewall). This ruled out IP masquerading (see
IP Masquerade HOWTO) which would otherwise probably be
a simpler solution. This is not as simple as it seems.
To accomplish our goal of insulating a local net from the global
net (over DSL) by using our Linux box, we will use two ethernet (NIC) cards.
One card is hooked up to the local net and one to the global net. The only
machine that can directly talk to the outside world is the Linux box. All
other machines in our local net must go through the Linux box (firewall).
Configuring the software really consists of two problems:
- Route packets between the local and global net (bridging)
- Filter the packets to stop some from traversing the firewall
The
Bridging mini-Howto
gives detailed instructions that solves the first problem by routing packets
between the two sides of the network (local and global). This works by putting
both NIC's into "promiscuous" mode such that they sniff all the packets on
each NIC and transfer packets over when they belong on the other side.
This is done transparently; the other computers on the net do not even see
the bridge, because it does not even have an IP address. But this does not
totally solve the problem. I wanted the firewall to have an IP address
(for administration via the network, if nothing else) and more importantly,
the bridge code in the kernel intercepts and bridges packets BEFORE they get
to the firewall code, so the firewall will have no effect.
It turns out you can assign your NIC's IP addresses and still use them as a
bridge. Although the
Bridging mini-Howto
does not do this (well actually, it uses loopback addresses), it works fine.
That solves one problem. For the firewall problem, we turn to a fine kernel patch
at
http://ac2i.tzo.com/bridge_filter/
that causes the firewall rules to be invoked for packets that are being
bridged with a special new rule "bridgein".
This mini-HOWTO is meant to handle the situation where you have a Linux
box configured as a gateway/firewall. The system has 2 NIC cards installed.
One of the NIC cards is connected to the outside world (in our case a DSL
modem) and nothing else. The other NIC is connected to our local network.
Note that I have only had one experience with this and it was on my
i386 (ABIT BP6 MOBO, w/2 celery) box with RedHat 6.0 with the 2.2.13
kernel, and a DSL modem going to a router, and two Netgear FA310TX
NIC cards. Your mileage may vary.
Also note that the steps here will leave your network open to potential
attack during setup (before the firewall is turned on). If you are very
paranoid you will want to take extra steps to avoid this.
I found a good deal of information on the net that I used to finally
get things working. Some of the information was useful, but inaccurate.
The
Bridging mini-Howto
was instrumental in getting things up. Unfortunately using it alone does not
implement a firewall.
The
Linux Bridge+Firewall mini-HOWTO
at first looked like just what I needed. However, it turns out that I think
it is inaccurate. I got things sort-of working with it, but in the end I
realized that it was not necessary to split your sub-net in two like it
directs and did not use that method. If you look at this document, take
it with a grain of salt.
The
Bridge Filter Patch is
the key to getting the whole thing to work. Oddly enough, the information on
the web page directs you to the Bridge+Firewall mini-HOWTO. You do not need
to use the information in Bridge+Firewall mini-HOWTO to get things to work.
You will need this patch.
The
IPCHAINS HOWTO
is invaluable in setting up the firewall itself. I do not attempt to cover the details
of firewall setup in this document; only issues which are different because
of the bridging setup are mentioned here.
Next
Previous
Contents
|