BEDTIME READING-Routing, Bridges, and Firewalls
May 2000
Best read 1024x768
Author: Mike Andrew

This is a plain-vanilla discussion about connecting computers between networks and is truly bedtime reading. Providing bridges between any computer, and the internet, is easy to achieve. Understanding the concepts can be, and will give you a remarkable insight into how your Linux Kernel operates. I have kept technicalities out of this document because, frankly, they're boring. And, i have minimized the buzzwords. Any buzzwords remaining are deliberate, you must understand the term used to succeed in your netmin career.

Most of you reading this document will be desperate to find the simple enough 1,2,3 steps needed to 'bridge' your workstation (or ppp connection) into the wide blue yonder. For the impatient head for the bottom of this very long page, otherwise, read, enjoy, and learn something.

There are two common scenarios;

This is common. Not so common are x25 radio links, satellites, parallel connections. In all cases simply substitute the word eth0 / ppp0 for the name of the uncommon 'device', and read on.

In all cases while the machine so connected can handle anything coming at it from either network, getting things forwarded between interfaces, is not so obvious, and not a birthright. However, all the tuff stuff has been done for you. A linux kernel automatically routes traffic between devices on a machine, if allowed to. It is generically termed routing, and the connections it makes, by routing, are called, sensibly enough, bridges.

No matter how complex the final mix of ethernets, cards, ppp dialups and networks, they all resolve down to a basic building block.

1)/sbin/route add -host <ip_address> dev eth0 (or ppp0 )

# cause this machine to respond to this ip address by becoming it's host.

2)/sbin/route add -net <net_address> netmask dev eth0

associate network device eth0 with network address

These two statements are inherent for ethernet devices at boot time (part of /etc/rc.d/init.d/network start), and, assigned dynamically by ppp for ppp.

The Internet and the internet.

While the Internet is the flavour of the decade, it is not the bottom line. The internet is a collection of inter networked computers, of which, the Internet is just a component part. Do not confuse terms used later on with the world wide web. Technically, the www is not significant whereas the internet certainly is.

The all important, overiding, unsurpassed, magnificant, default route.

The bottom line question you are possibly asking, right now, is how do i connect a workstation onto the Internet when it is separated by god knows how many layers of ethernet networks?

The short answer is, you don't. What you do do, is provide that machine a default route. Ie, a single point to pass all traffic it can't handle or knows nothing about.

You can be certain, the machine it is connected to, via the default route, has???? a default route of its own.

And, you can be sure, the machine that machine is connected to, via it's default route, has a default route of its own. In this way, it is easy to visualise how traffic can ultimately get out the front door.

error-file:TidyOut.log This simple illustration should show how easy it is, conceptually at least, to establish a connection to the outside world. None of these machines directly know what or where the 'Internet' is. All traffic they can't handle gets shovelled out their default route for someone else to deal with.

If you follow this concept logically, then neither the ISP you are connected to, nor for that matter the hundreds of bridges within the internet know about either. They simply forward the IP address represented by until something responds.

In truth, the 4 byte IP number gets filtered as it begins to reach it's final destination so that some numbers are passed to network 'A', others to network 'B', and surprise, surprise, any other numbers are passed out via the default route of that filtering machine to somewhere else.

It should come as no surprise to you that this topology works just as well in reverse. When you 'ping'' your workstation address is attached to that ping. (or the server it represents) wouldn't have any idea who you are. It passes the response back, via it's default route.


Before we finally get into 'how' to establish routes and bridges, a note about firewalls.

TCP/IP is a component part of what is known as a protocol stack. If you imagine your ethernet card at the bottom of this stack, and your web browser at the top, it is not difficult to imagine that 'other things' exist between your browser, and your ethernet card. These 'other things' are a mix of protocols, drivers and applications that form successive layers of abstraction between you, the browser, and the ethernet card.

By abstraction, I mean that you have probably never in your life known THE address of your ethernet card. It's a rather large number, and if you're really curious try typing ifconfig to find out. Point is, you don't need to, it gets translated in the IP layer of the stack to an IP address. Similarly, within an other layer of abstraction, you probably don't know the IP address of And don't need to. It gets abstracted for you just above the TCP layer. (a slight lie, but let's move on).

boring stuff
more boring stuff
Ethernet (or PPP)
Mike's Own Version of a Protocol Stack

The point to focus on here, as it relates to firewalls is the IP layer. IP means Internet Protocol. Specifically, it relates to IP numbers. It is this layer of the protocol stack which determines where to send the message next.

Router Diagram Firewall Image This is where it is worth you paying close attention. In a bridging router the IP layer, already inherent in the linux kernel takes care of all the messy details of passing traffic from one network to another. IP_FORWARD="yes"

In a firewall, this route is intentionally cut. IP_FORWARD = "no"

There are some important and accurate conclusions to draw from this illustration.

A router requires no additional software above the IP layer to do it's thing.You can at least imagine now, why and how a linux 'router' is so damn fast and why, a 486 class machine is all that is required.

Applications above the firewall might well, and intentionally, defeat the firewall and pass traffic. Clearly, a machine 'behind a firewall' that passes no traffic in or out would be a strange animal indeed, so be aware of the real meaning of the terminology. All that a firewall means is passing traffic does not occur at the lower levels of the stack and that is all.

A bridging router.
A firewall


Now that you understand, conceptually, what is occuring in a machine. Here's the good stuff. With one final comment

Bridging is so embarassingly simple, that it is rarely explained properly. There is one rule you must follow, nothing, but nothing will work without the following and I have never found a document anywhere on the Internet that relates this in plain-speak.

FORWARD_IPV4=yes #all your dreams will come true.
FORWARD_IPV4=no # bridging between networks is impossible (in the kernel).

You cannot imagine the number of stations I have 'fixed' with this simple statement (and budding ISP's).

Network Bridge Diagram You are looking at a diagram that says it all, with bells on. As simple as this diagram looks, there are critical concepts here which you need to be aware of.

The 'blue stuff' is a network.

The black stuff is a bridge, a router, or, if you prefer, a gateway.

The 'red stuff' is a different network.

So far, obvious huh? Read on.

What makes the 'blue stuff' and the 'red stuff' different networks are:

They need not be physically isolated, OR, they need not be different network addresses to require a bridge, but taken together, the above diagram is classic of office (and home) installations. If you see yourself as the blue machine, dialling into your black isp, you can rapidly appreciate where the Internet might be (it's somewhere on the red network, and neither you nor the isp care too muchly. (see opening comments about default routes). However, for the moment, ignore the special case of ppp dial up, there are a few technical differences worth commenting on later.


A truly dreadful name, conjuring up all the wrong associations. But, we're stuck with it. A host takes responsibility for, or 'hosts', an ip address. By declaring a machine a host for ip address, you are saying (and all you are saying) is that it will respond to any traffic with that address in the destination header ip packet. What it does with that ip packet can be anyone's guess, but, it will respond. Typically, when you dial up an ISP, you are provided a 'dynamic host ip number', ie one that you are expected to respond to. Ie, you take on the identity of that ip number. In the above diagram, each box of any colour is 'identified' by it's host ip number. Any given box could have multiple host ip numbers, but the ones declared above, declare that machine for the purpose of responding on the ethernet lan cable(s). If any of these machines have other host ip numbers (as they often do), they are of bugger all interest since no other machine on the ethernet knows about them and cannot address 'them'.

A typical hosting statement for one of the above machines would be
/sbin/route add -host dev eth0

Typically, for ethernet, this is done at boot time in /etc/sysconfig/static-routes, and for ppp it is done dynamically as dial in or out occurs.

The essential point to grasp? You are telling a specific interface device (ethernet 0 in this case) to respond to anything with an ip of

The Network Address

Essentially, a host ip number is fully qualified. Meaning the full number, and ergo, it can only possibly be 'hosted' by a single machine.

A network address is a block of ip addresses. The famous 192.168.X.0 network addresses are termed 'CLASS C'. Up to 254 specific hosts can live on any single CLASS C network address. This is not an address that is hosted by anything . 'Things' don't host network addresses and don't respond to network addresses, they are a definition of a channel.

But, almost anything you read about network addresses is nebulous and subject to whim and fluffery. It is not useful to define class A B C networks here, a concept call 'subnetting' breaks down class C's (or anything else) into even smaller chunks. The essential point to grasp is the netmask

The netmask.

It is the netmask that defines a network address (where it's boundaries are). In the above diagram, it should be clear enough that the physical, ethernet, cable, connection between, and are ALL on the network,

Critical to your success in bridging, you want anything and everything associated with 192.168.1. anything to go to (to be on) the network, and to do so, you use a netmask. Specifically

Be ultra aware of the netmask, it is the first and final arbiter of what 'network address' really means.

You should also be aware, that the above diagram declares the red ethernet cable to be network address, BUT, that may not be the ONLY network address it handles. Of a certainty, the one network address it will NOT handle is

Typically, the following statement declares a network address.
/sbin/route add -net netmask dev eth0

the above associates all traffic intended for the 1.0 network with ethernet card 0

Depending on the version of route , the terms -net and -host are superflous for all commands. Specific addresses can never be -net(s) and can only have a netmask of (fully qualified, fully masked). Non-specific ip addresses can never be -host(s). But, route is erratic in its syntax and very annoying in some of its pedantic command sytnax YMMV.

INTRANET routing.

So far, you now know how to identify your machine with an ip number, and, how to tell it what network it has.

By providing a netmask statement (as above), you can now ping any machine on the same network as yourself.

The kernel router knows that

means, send this out on the eth0 device. Your machine doesn't know anything about, it doesn't care, and doesn't need to.

Fully appreciate the above. If you understand what has happened here, you will follow why networking routing is SO EASY in linux.

To fully dot some I's and cross some T's, understand that someway, somehow, at sometime, the machine represented by has had the following statement shovelled into it.
/sbin/route add -host 192,168.16.5

To make it even clearer, that same machine has had the following identical command pumped in
/sbin/route add -net netmask dev eth0

Both these machines are now fully interacting with each other, and any other machine on the same network device and network address.  To make it even clearer, typing /sbin/route on these two machines yeilds

Destination Gateway Netmask Flags Interface
Workstation 1 * UH 0 0 0 eth0 * U 0 0 0 eth0 * U 0 0 0 lo
Workstation 2 * UH 0 0 0 eth0 * 0 0 0 eth0 * U 0 0 0 lo

NOTE: the all important netmask. Anything for 192.168.16.anything goes to eth0

NOTE: also, eth0 is NOT the same device (obviously?) on each machine.

The default route

Imagine you now wish to ping (

Through smoke and mirrors your machine 'discovers' the ip address. (smoke and mirrors = way way outside the thrust of this document).

This ip address has nowhere to go, there is NOTHING in your machine that will respond (remember hosts?) to this address.

Enter the default route
/sbin/route add default

this is shorthand for the following
/sbin/route add netmask gw

and your routing table now looks like this

Destination Gateway Netmask Flags Interface
Workstation 1 * UH 0 0 0 eth0 * U 0 0 0 eth0 * U 0 0 0 lo
default UG 0 0 0 eth0

This table offers up some essential concepts.

ANY 192.168.16.X address that this machine is a Host for, will stay in this machine. In this example, only one. In other examples, think of websites and you strongly get the picture. Grasp this, and you understand how an Apache Server 'works'.

Anything else destined for the network will go out the eth0 device and NOT the default route. In this example, they are one and the same, but never assume.

Anything that 'falls thru the cracks', ie, anything that cannot be covered by what could sometimes be a very large route table, gets forwarded to another ip address for it to handle (as best it can). In this example it is a machine which hosts the ip address Where is it? On ethernet device 0, and that's all we need to know.

And, there is some redundancy here, routing is recursive, the gateway device for can be found because we said, network 192.168.16.anything is on ethernet 0

Look at the flags and see the relationship between a Host, a fully qualified ip number, and the mask that MUST be asssociated with it.

Look at the Netmask and notice that a network address is neither a gateway, nor a host, it is just a network on a device.

Look at the flags, and see the relationship between a Gateway and a specific host it must go to.

Notice the loopback device. It's inherent in every system. It allows sofware applications to be written in a standard manner, everything the software wants to do, goes to a TCP/IP connection. The fact that it's internal, is neither which way. Only one code to write, not one for internet and one for internal devices. Think printing, you're well on your way.

Imagine. This much power and all you did was type

/sbin/route add -host <ip address>
/sbin/route add -net <network address>
/sbin/route add default <some address>

Spend some value-time reviewing this table and section. Light bulbs should be turning on in your head how your Linux Kernel operates.

You have been given some valuable pointers here into how printing and web servers 'work'.


So far, we now know how to get out to other machines on our intranet, and, how to reach a gateway. The term is called cascading. If you think about it now, there is nothing different to do at each gateway. Each one successively drops you into another network. What is stupendously wonderful about cascading is that at no point does any machine on any network need to know anything more. It does not need to know where is, only where it's own gateway is, and so on. While this concept might now sound blindingly obvious to you. Believe me, in the course of your intranet career you will lead yourself up some blind alleys. If you start massaging a routing table on a machine that is more than one hop away, you got it wrong. In the above example, if you have any statements route-wise in about 192.168.1.anything, you got it badly wrong. I have been there, I have dun that, and I still continue to make the odd mistake.

The 'black stuff' shows a typical bridge. It has TWO ethernet cards. eth0 and eth1 respectively. Where are they and what are they? Frankly, who cares. If you recall the section on tcp/ip layers and the protocol stack, IP offers a level of abstraction over what the ethernet driver, it's card, and its 'real address' is. The issue of whether it's a Realtek 8019, or an Acorn 83C05 should be of total indifference. In every respect this same comment applies to ppp0. The ip layer deals with devices, eth0, ppp0 etc. The physical media for routing is irrelevant. Stop wasting time on it. But, if you really must know, the answer is /sbin/ifconfig

In the intranet figure above, it is fairly clear (or certainly should be), that the gateway machine, alias the router, alias the bridge, has two Host names associated with it. Put another way, it will respond to two ip addresses. It should also be fairly obvious that each ethernet card owns one of theses addresses and that each ethernet card is in some way responsible for the network address connected to that card. Lets look at the commands to achieve this, they *should* be very familiar to you.

/sbin/route add -host dev eth0
/sbin/route add -host dev eth1
/sbin/route add -net netmask dev eth0
/sbin/route add -net netmask dev eth1

some comments here, ymmv with the route command, it is very pernickity about the syntax it accepts. The above works on my machines, I am tired of discovering each nuance of the syntax, dependent on route revlevel. What is important is the above syntax should be very clear to you what we are attempting to achieve. Because, all we are saying to the kernel is, ethernet0 has a device ip addresses of 16.10 and ethernet 1 has a device address of 1.10. If you, the kernel, want to access other hosts on these two networks (and no other), then use the respective ethernet device. (or ppp if we had stated that).

Some other comments that are worthy of mention.

You now have a machine that will ping any host on either of the networks (and similarly you can assume other hosts on those networks can equally ping this machine). Ping in this context means the whole caboodle, including telnet if you're allowed to. What you cannot do is ping accross networks, we'll get to that a little later.

If you think about it. you haven't done one single thing that's different to, you've simply applied the same building blocks, twice.

And finally, the all important netmask. It alone defines your network address(es). The above examples give the classic class C network. I am going to belabour this fundamental point, it is critical to your success in netadmin. IARNA do NOT define your network, ARPANET cannot define your network, There is no such thing as class A,B C anything. Forget all you ever read on this nonsense. You alone, not only define your network, you and you alone are the only person who *can* define your network. The only defintion of a network is that all hosts on that network must have the same identical netmask. If you wanted to, and there are many many examples of just such a case, you *could* define a netmask of (a net with a maximum of 16-2 hosts). In the context of the wider internet, this technique is known as subnetting.

The reason why I really do need to thump this message home, is you can read tomes of material on Internet class licences, public / private ip addresses, and *still* be completely impotent when it comes to setting up your machine(s). The name of the game is netmask, not, netaddress, and the only place where netmask is effective is in the routing table.


If you ping from, you will get no response. The bridge, alias host does not know what to do with it.
/sbin/route add -net gw dev eth0
/sbin/route add -net gw dev eth1

and, as a final touch
/sbin/route add default

what this simple syntax says is

anything coming in destined for the 1.0 network is handled by the host, and ditto anything for 16.0 network is the 16.10 host.

imagine now, that pings wouldn't have a clue who this is, it is told to cascade via it's default route.

A default route by definition is a specific machine (, this new host interface picks up the request. In turn, it has't a clue either, but 'knows' that anything to do with 1.anything is handled by 1.10, another specific gateway. We have just jumped the bridge. 1.10 knows nothing about 1.20 but does know to shovel it out the eth1 network because we told it to. Finally, 1.20 will respond to the return address 16.8 Since it doesn't have a clue who 16.8 is, you can be very sure it's default route finds it's way back to 1.10, which in turn, fowrwards it to host 16.10 and so on. We have again, jumped the bridge.

A final nicety is the default route. We have told the gateway to forward traffic for either network to either network. Wheras the default route, you can be sure, is the cascade ip address that finally opens the front door to the internet. Perpaps not 1.1 directly, but somewhere down that waterfall is the door, elsewise we wouldn't have said so. What makes this marvellous topology tick, is we don't have to care whether 1.1 is the door to the internet, or something beyond it. Pause on that thought a moment, because suddenly, you should now see how inserting additional network layers has zilch effect on all your previou hard work.


PPP in every respect is the same discussion. Simply replace any of the workstations in the first diagram with a ppp dialup link (whether other hosts are also on that 'network' is immaterial. The only point of confusion is that the remote machine takes on the identity of the dialled machine.

Assume if you will that has an additioanal dial IN port, and, it will consider anyone who dials in to be

After you establish a remote connection, if you type /sbin/route on the remote machine, it will say it is a host for 16.8. SImilarly, the dialled in machine assumes a host of on ppp0 in addition to its host ip of on eth0.

This is perhaps the opposite of what you may have expected. The remote machine IS, but it's host routing table says it hosts (responds to) I leave it to you to work this out.

searchSearch Index