diff --git a/en_US.ISO8859-1/articles/filtering-bridges/article.sgml b/en_US.ISO8859-1/articles/filtering-bridges/article.sgml index af4cf51e9a..f864e45e1d 100644 --- a/en_US.ISO8859-1/articles/filtering-bridges/article.sgml +++ b/en_US.ISO8859-1/articles/filtering-bridges/article.sgml @@ -1,356 +1,385 @@ %man; ]>
Filtering Bridges - Nick - Sayer - + Alex + Dupre -
nsayer@FreeBSD.org
+
sysadmin@alexdupre.com
 - + $FreeBSD$ - For those of you who do not know, DSL differs from more traditional - connectivity methods in that the connectivity spigot that comes - out of the wall has no possibility for packet filtering. If you get - a T1 line or some such it will come with a router that can generally - include a packet filter. If you get ISDN or a dialup link, you also - either have a software routing component (a PPP daemon, specifically) - that can do some filtering or can be combined with a filter on the - machine running the link. But with DSL you only get a little white - box with some Blinkenlights on it and an Ethernet port that takes - your traffic back and forth from the Internet and nothing else (to - some extent the same can be said of other mass-market high speed - connectivity methods, like cable modems or high speed wireless links - as well. The same technique I plan to describe works just as well - for them, or for any other technology that provides an Ethernet - port with no filtering). + Often it is useful to divide one physical network (like an + Ethernet) into two separate segments without having to create subnets, + and use a router to link them together. The device that connects the + two networks in this way is called a bridge. A FreeBSD system with + two network interfaces is enough in order to act as a bridge. + + A bridge works by scanning the addresses of MAC + level (Ethernet addresses) of the devices connected to each of its + network interfaces and then forwarding the traffic between the two + networks only if the source and the destination are on different + segments. Under many points of view a brigde is similar to an Ethernet + switch with only two ports. Why use a filtering bridge? - Bridging is not the only conceivable option. It is possible to - set up a two Ethernet machine as a router instead of a bridge. - Where it is possible to do so, it is actually a better idea. - Bridges run their interfaces in promiscuous mode, meaning they - must process every packet presented to them. The problem is - that routers can only route traffic between different subnets. - Also, subnets can only be made by by cutting an existing space in - half or defining a new space that is typically unroutable (see - RFC 1918). - This wastes half of the useful addresses (or at least puts - them on the wrong side of the router—the thing that is - doing the packet filtering that makes the inside network safe). - Using a bridge costs some CPU cycles, but makes all of the - problems of adding a 2nd router go away. + More and more frequently, thanks to the lowering costs of broad band + Internet connections (xDSL) and also because of the reduction of + available IPv4 addresses, many companies are connected to the Internet + 24 hours on 24 and with few (sometimes not even a power of 2) IP + addresses. In these situations it is often desirable to have a firewall + that filters incoming and outgoing traffic from and towards Internet, + but a packet filtering solution based on router may not be applicable, + either due to subnetting issues, the router is owned by the connectivity + supplier (ISP), or because it doesn't support such + functionalities. In these scenarios the use of a filtering bridge is + highly advised. + + A bridge-based firewall can be configured and inserted between the + xDSL router and your Ethernet hub/switch without any IP numbering + issues. - - Configuring a Kernel - + + How to Install + + Adding bridge functionalities to a FreeBSD system is not difficult. + Since 4.5 release it is possible to load such functionalities as modules + instead of having to rebuild the kernel, simplifying the procedure a + great deal. In the following subsections I will explain both + installation ways. + - After configuring and installing a kernel as shown here, you - should carry out the other - final preperation - tasks before booting into your new kernel. + Do not follow both instructions: a procedure + excludes the other one. Select the best choice + according to your needs and abilities. - Adding bridging to a FreeBSD machine is not hard to do. It means - having 2 (or more, but we will just use 2 here) Ethernet cards and adding - a couple of lines to the kernel configuration. Since May of 2000, - RELENG_4 and -current have had bridging support for all Ethernet - interfaces. This does not mean that any Ethernet interface will work. - For them to work, they have to support a working promiscuous mode for - both reception and transmission—that is, they have to be able to - transmit Ethernet packets with any source address, not just their own. - In order to get good throughput, the cards should also be PCI bus - mastering cards. The best choices still are the Intel EtherExpress Pro - 100 cards, with 3com 3c9xx cards being second. - - So you will want to add the following to your kernel configuration - file: - - device fxp (or whatever is appropriate for the cards you are using) -options BRIDGE + Before going on, be sure to have at least two Ethernet cards that + support the promiscuous mode for both reception and transmission, since + they must be able to send Ethernet packets with any address, not just + their own. Moreover, to have a good throughput, the cards should be PCI + bus mastering cards. The best choices are still the Intel EtherExpress + Pro, followed by the 3Com 3c9xx series. To simplify the firewall + configuration it may be useful to have two cards of different + manufacturers (using different drivers) in order to distinguish clearly + which interface is connected to the router and which to the inner + network. + + + Kernel Configuration + + So you have decided to use the older but well tested installation + method. To begin, you have to add the following rows to your kernel + configuration file: + + options BRIDGE options IPFIREWALL options IPFIREWALL_VERBOSE - Note that recent versions of FreeBSD support dynamically loading the - IP Firewall code into the kernel. You can not do this, however, with - bridging, as the bridge code itself needs to interact with IPFIREWALL - in a special way. - - It is also a good idea at this point to see if Luigi has updated - versions of the bridge code available that are more recent than what is - in the distribution. As an example, 3.3-RELEASE comes with 981214, but - as of this writing, the most up-to-date bridge code is 990810. You can - fetch the latest version from - http://www.iet.unipi.it/~luigi/. You will want to fetch bridge.c and bridge.h and drop them into sys/net/. - - For instructions on how to build and install a new kernel, refer to - the - Building and Installing a Custom Kernel section of the handbook + The first line is to compile the bridge support, the second one is + the firewall and the third one is the logging functions of the + firewall. + + Now it is necessary to build and install the new kernel. You may + find detailed instructions in the Building + and Installing a Custom Kernel section of the FreeBSD + Handbook. + + + + Modules Loading + + If you have choosen to use the new and simpler installation + method, the only thing to do now is add the following row to + /boot/loader.conf: + + bridge_load="YES" + + In this way, during the system startup, the + bridge.ko module will be loaded together with the + kernel. It is not required to add a similar row for the + ipfw.ko module, since it will be loaded + automatically after the execution of the steps in the following + section. + Final Preperation - Before you boot the new kernel, you must make some preparations in - rc.boot and rc.firewall. The - default rule for the firewall is to drop all packets on the floor. You - will want to override this by setting up the open firewall in - /etc/rc.conf. Put these lines in - /etc/rc.conf to achieve this: - -firewall_enable="YES" -firewall_type="open" - - There is one more thing that is necessary. When running IP over - Ethernet, there are actually two Ethernet protocols in use. One - is IP, the other is ARP. ARP is used when a machine must figure out - what Ethernet address corresponds to a given IP address. ARP is not - a part of the IP layer, since it only applies to IP when run over - Ethernet. The standard ipfirewall rule for the open firewall is - - pass ip from any to any - - but what about ARP? If ARP is not passed, no IP traffic can flow at - all. But IPFIREWALL has no provisions for dealing with non-IP - protocols, and that includes ARP. Fortunately, a hackish extension was - made to the ipfirewall code to assist filtering bridges. If you set up - a special rule for UDP packets from IP address - 0.0.0.0, the UDP port number will be used - to match the Ethernet protocol number for bridged packets. In this way - your bridge can be configured to pass or reject non IP protocols. So add - this line just below the two lines near the top of - /etc/rc.firewall that deal with - lo0 (the ones that say that you should almost - never change those two rules). - - ${fwcmd} add allow udp from 0.0.0.0 2054 to 0.0.0.0 - - This rule makes almost no sense at all from a normal perspective on - IPFIREWALL, but the bridge code will use it to pass ARP packets without - restriction (which you almost certainly want to do). - - Now you should be able to reboot your machine and have it act no - differently than it did before. There will be some new boot messages - about bridging, but the bridging will not be enabled. If there are any - problems, you should try and sort them out at this point before - proceeding. + Before rebooting in order to load the new kernel or the required + modules (according to the previously choosen installation method), you + have to make some changes to the /etc/rc.conf + configuration file. The default rule of the firewall is to reject all IP + packets. Initially we'll set up an 'open' firewall, in order to verify + its operation without any issue related to packet filtering (in case you + are going to execute this procedure remotely, such configuration will + avoid you to remain isolated from the network). Put these lines in + /etc/rc.conf: + + firewall_enable="YES" +firewall_type="open" +firewall_quiet="YES" +firewall_logging="YES" + + The first row will enable the firewall (and will load the module + ipfw.ko if it is not compiled in the kernel), the + second one to set up it in 'open' mode (as explained in + /etc/rc.firewall), the third one to not show rules + loading and the fourth one to enable logging support. + + About the configuration of the network interfaces, the most used way + is to assign an IP to only one of the network cards, but the bridge will + work equally even if both interfaces or none has a configured IP. In the + last case (IP-less) the bridge machine will be still more hidden, as + inaccessible from the network: to configure it, you have to login from + console or through a third network interface separated from the bridge. + Sometimes, during the system startup, some programs require network + access, say for domain resolution: in this case it is necessary to + assign an IP to the external interface (the one connected to Internet, + where DNS server resides), since the bridge will be + activated at the end of the startup procedure. It means that the + fxp0 interface (in our case) must be mentioned + in the ifconfig section of the /etc/rc.conf file, + while the xl0 is not. Assigning an IP to both + the network cards does not make much sense, unless, during the start + procedure, applications should access to services on both Ethernet + segments. + + There is another important thing to know. When running IP over + Ethernet, there are actually two Ethernet protocols in use: one is IP, + the other is ARP. ARP does the + conversion of the IP address of a host into its Ethernet address + (MAC layer). In order to allow the communication + between two hosts separated by the bridge, it is necessary that the + bridge will forward ARP packets. Such protocol is not + included in the IP layer, since it exists only with IP over Ethernet. + The FreeBSD firewall filters exclusively on the IP layer and therefore + all non-IP packets (ARP included) will be forwarded + without being filtered, even if the firewall is configured to not permit + anything. + + Now it's time to reboot the system and use it as before: there will + be some new messages about the bridge and the firewall, but the bridge + will not be activated and the firewall, being in 'open' mode, will not + avoid any operations. + + If there are any problems, you should try and sort them out now + before proceeding. - Enabling The Bridge - - Next, you should do this: - - &prompt.root; sysctl -w net.link.ether.bridge_ipfw=1 -&prompt.root; sysctl -w net.link.ether.bridge=1 - - At this point, the bridge should be enabled, and because of the - previous changes to /etc/rc.conf, the firewall - should be wide open. At this point, you should be able to insert the - machine between two sets of hosts and go back and forth without - difficulty. If so, the next step is to add those two sysctl lines to - either /etc/rc.local or add the net.link.[blah - blah]=1 portions of the lines to /etc/sysctl.conf - (which path you take depends on what version of FreeBSD you - have). - - Now before we started all of this, you should have had a machine - with two Ethernet interfaces, but with only one of them configured. That - is, there should only be one ifconfig line - /etc/rc.conf. With the bridge in place, that is - still true. But there is a detail that deserves some thought. The - bridge is not in place by default. That means that until the sysctls - are run that turn the bridge on, rather late in the startup, it is still - an ordinary machine with two interfaces, only one of which is configured - by /etc/rc.conf. This becomes important for those - portions of the startup that require network access, say for DNS - resolution. Some care must be made in picking which interface is going - to be the configured one. In most cases, you are best to pick the - outside one (that is, the interface connected to the Internet). Let's - presume for the sake of the examples to come, that - fxp0 is the outside interface, and - fxp1 is the inside one. That means that fxp0 - should be mentioned in /etc/rc.conf's ifconfig - sections, but fxp1 should not be. The sysctl - that turns the bridge on will make fxp1 start - working automagically. + Enabling the Bridge + + At this point, to enable the bridge, you have to execute the + following commands (having the shrewdness to replace the names of the + two network interfaces fxp0 and + xl0 with your own ones): + + &prompt.root; sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0 +&prompt.root; sysctl net.link.ether.bridge_ipfw=1 +&prompt.root; sysctl net.link.ether.bridge=1 + + The first row specifies which interfaces should be activated by the + bridge, the second one will enable the firewall on the bridge and + finally the third one will enable the bridge. + + At this point you should be able to insert the machine between two + sets of hosts without compromising any communication abilities between + them. If so, the next step is to add the + net.link.ether.[blah]=[blah] + portions of these rows to the /etc/sysctl.conf + file, in order to have them execute at startup. - + Configuring The Firewall - - Now it is time to start adding ipfirewall rules to secure the inside - network. There are some complications in doing this because not all of - the ipfirewall functionality is available on bridged packets. Also, - there is a difference between packets that are in the process of being - bridged and packets that are being received by the local machine. In - general, packets being bridged are only run through ipfirewall once, not - twice as is usually the case. Bridged packets are filtered while they - are being received, so rules that use out or xmit will never match. - I usually use in via which is an older syntax, but one that makes - sense as you read it. Another limitation is that you are restricted - only to pass or drop for filtering bridged packets. Sophisticated - things like divert or forward or reject are not available. Such - options can still be used, but only on traffic to or from the bridge - machine itself. - - New in FreeBSD 4.0 is the concept of stateful filtering. This is a - big boost for UDP traffic, which typically is a request going out, - followed shortly thereafter by a response with the exact same set of IP - addresses and port numbers (but with source and dest reversed, of - course). For firewalls that have no statekeeping, there is almost no - way to deal with this sort of traffic short of setting up proxies. But - a firewall that can remember an outgoing UDP packet and for the next - few minutes allow a response, handling UDP services is trivial. The - example to follow shows how to do this. The truly paranoid can also set - up rules like this to handle TCP. This allows you to avoid some sorts - of denial of service attacks or other nasty tricks, but it also - typically makes your state table mushroom in size. - - Let's look at an example setup. Note first that at the top of - /etc/rc.firewall we should already have taken care - of the loopback interface and the special hack for ARP should still be - in place. So we will not worry about them any further. - -us_ip=192.168.1.1 -oif=fxp0 -iif=fxp1 - -# Things that we've kept state on before get to go through in a hurry. -${ipfw} add check-state -# Throw away RFC 1918 networks -${ipfw} add deny log ip from 10.0.0.0/8 to any in via ${oif} -${ipfw} add deny log ip from 172.16.0.0/12 to any in via ${oif} -${ipfw} add deny log ip from 192.68.0.0/16 to any in via ${oif} + Now it is time to create your own file with custom firewall rules, + in order to secure the inside network. There will be some complication + in doing this because not all of the firewall functionalities are + available on bridged packets. Furthermore, there is a difference between + the packets that are in the process of being forwarded and packets that + are being received by the local machine. In general, incoming packets + are run through the firewall only once, not twice as is normally the + case; in fact they are filtered only upon receipt, so rules that use + 'out' or 'xmit' will never match. Personally, I use 'in via' which is an + older syntax, but one that has a sense when you read it. Another + limitation is that you are restricted to use only 'pass' or 'drop' + commands for packets filtered by a bridge. Sophisticated things like + 'divert', 'forward' or 'reject' are not available. Such options can + still be used, but only on traffic to or from the bridge machine itself + (if it has an IP address). + + New in FreeBSD 4.0, is the concept of stateful filtering. This is a + big improvement for UDP traffic, which typically is a + request going out, followed shortly thereafter by a response with the + exact same set of IP addresses and port numbers (but with source and + destination reversed, of course). For firewalls that have no + statekeeping, there is almost no way to deal with this sort of traffic + as a single session. But with a firewall that can "remember" an outgoing + UDP packet and, for the next few minutes, allow a + response, handling UDP services is trivial. The + following example shows how to do it. It's possible to do the same thing + with TCP packets. This allows you to avoid some + denial of service attacks and other nasty tricks, but it also typically + makes your state table grow quickly in size. + + Let's look at an example setup. Note first that at the top of + /etc/rc.firewall there are already standard rules + for the loopback interface lo0, so we shouldn't + have to care for them anymore. Custom rules should be put in a separate + file (say /etc/rc.firewall.local) and loaded at + system startup, by modifying the row of + /etc/rc.conf where we defined the 'open' + firewall: + + firewall_type="/etc/rc.firewall.local" -# Allow the bridge machine to say anything it wants (keep state if UDP) -${ipfw} add pass udp from ${us_ip} to any keep-state -${ipfw} add pass ip from ${us_ip} to any + + You have to specify the full path, otherwise + it will not be loaded with the risk to remain isolated from the + network. + -# Allow the inside net to say anything it wants (keep state if UDP) -${ipfw} add pass udp from any to any in via ${iif} keep-state -${ipfw} add pass ip from any to any in via ${iif} + For our example imagine to have the fxp0 + interface connected towards the outside (Internet) and the + xl0 towards the inside + (LAN). The bridge machine has the IP 1.2.3.4 (it is not possible that your + ISP can give you a class A address like this, but for + our example it is good). -# Allow all manner of ICMP -${ipfw} add pass icmp from any to any + # Things that we have kept state on before get to go through in a hurry +add check-state + +# Throw away RFC 1918 networks +add drop all from 10.0.0.0/8 to any in via fxp0 +add drop all from 172.16.0.0/12 to any in via fxp0 +add drop all from 192.68.0.0/16 to any in via fxp0 + +# Allow the bridge machine to say anything it wants +# (if the machine is IP-less don't include these rows) +add pass tcp from 1.2.3.4 to any setup keep-state +add pass udp from 1.2.3.4 to any keep-state +add pass ip from 1.2.3.4 to any + +# Allow the inside hosts to say anything they want +add pass tcp from any to any in via xl0 setup keep-state +add pass udp from any to any in via xl0 keep-state +add pass ip from any to any in via xl0 # TCP section -# established TCP sessions are ok everywhere. -${ipfw} add pass tcp from any to any established -# Pass the "quarantine" range. -${ipfw} add pass tcp from any to any 49152-65535 in via ${oif} +# Allow SSH +add pass tcp from any to any 22 in via fxp0 setup keep-state +# Allow SMTP only towards the mail server +add pass tcp from any to relay 25 in via fxp0 setup keep-state +# Allow zone transfers only by the slave name server [dns2.nic.it] +add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state # Pass ident probes. It's better than waiting for them to timeout -${ipfw} add pass tcp from any to any 113 in via ${oif} -# Pass SSH. -${ipfw} add pass tcp from any to any 22 in via ${oif} -# Pass DNS. Only if you have name servers inside. -#${ipfw} add pass tcp from any to any 53 in via ${oif} -# Pass SMTP to the mail server only -${ipfw} add pass tcp from any to mailhost 25 in via ${oif} +add pass tcp from any to any 113 in via fxp0 setup keep-state +# Pass the "quarantine" range +add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state # UDP section -# Pass the "quarantine" range. -${ipfw} add pass udp from any to any 49152-65535 in via ${oif} -# Pass DNS. Only if you have name servers inside. -#${ipfw} add pass udp from any to any 53 in via ${oif} +# Allow DNS only towards the name server +add pass udp from any to ns 53 in via fxp0 keep-state +# Pass the "quarantine" range +add pass udp from any to any 49152-65535 in via fxp0 keep-state + +# ICMP section +# Pass 'ping' +add pass icmp from any to any icmptypes 8 keep-state +# Pass error messages generated by 'traceroute' +add pass icmp from any to any icmptypes 3 +add pass icmp from any to any icmptypes 11 # Everything else is suspect -${ipfw} add deny log ip from any to any +add drop log all from any to any Those of you who have set up firewalls before may notice some things - missing. In particular, there are no anti-spoofing rules. That is, - we did not add: + missing. In particular, there are no anti-spoofing rules, in fact we did + not add: - ${ipfw} add deny ip from ${us_ip}/24 to any in via ${oif} + add deny all from 1.2.3.4/8 to any in via fxp0 - That is, drop packets claiming to be from our network that are - coming in from the outside. This is something that you would commonly - do to make sure that someone does not try and evade the packet filter by + That is, drop packets that are coming in from the outside claiming + to be from our network. This is something that you would commonly do to + be sure that someone does not try and evade the packet filter, by generating nefarious packets that look like they are from the inside. - The problem with that is that there is at least one host on the outside - interface that you do not want to ignore—your router. In my - particular case, I have some machines on the outside and some on the - inside, but I do not necessarily want the outside machines to have - routine access to the inside. At the same time, I do not want to throw - their traffic away. In my own case, my ISP anti-spoofs at their router, - so I do not need to bother. And in general, the fewer rules the better, - since it will take time and CPU to process each one. - - Note also that the last rule is almost an exact duplicate of the - default rule 65536. There are two major differences when it comes to - bridging, however. Our rule logs what it drops, of course, but our rule - will only apply to IP traffic. Apart from the UDP - 0.0.0.0 trick there is no way to deal - with non IP traffic, so the default rule at 65536 will drop ALL traffic, - not merely all non-IP traffic. So the net effect is that unmatched IP - traffic will be logged, but not non-IP traffic. If you want, you can - add option IPFIREWALL_DEFAULT_TO_ACCEPT to your - kernel configuration and - non-IP traffic will be passed instead of dropped. But in the case of a - filtering bridge between you and the Internet, it is unlikely that you - would want to do this (if you are sufficiently paranoid). - - There is a rule for passing SMTP to a mailhost if you have one. - Obviously the whole ruleset above should be flavored to taste, and - that is an example of a specific service exemption. Note that - in order for mailhost to work, name service lookups must work - BEFORE the bridge is enabled. This is an example of making sure - that you enable the correct interface. - - Another item to note is that the DNS rules are set up only to - allow DNS servers to work. This means that if do not set up a - DNS server, you do not need them. - - Folks used to setting up IP firewalls also probably are used to - either having a reset or a forward rule for ident packets - (TCP port 113). Unfortunately, this is not an option with the - bridging code, so the path of least resistance is to simply pass - them to their destination. As long as that destination machine - is not running an ident daemon, this is relatively harmless. - The alternative is dropping port 113 connections, which makes - firing up things like IRC take forever (the ident probe must + The problem with that is that there is at least one + host on the outside interface that you do not want to ignore: the + router. But usually, the ISP anti-spoofs at their + router, so we do not need to bother that much. + + The last rule seems to be an exact duplicate of the default rule, + that is, do not let anything pass that is not specifically allowed. But + there is a difference: all suspected traffic will be logged. + + There are two rules for passing SMTP and + DNS traffic towards the mail server and the name + server, if you have them. Obviously the whole rule set should be + flavored to personal taste, this is only a specific example (rule format + is described accurately in the &man.ipfw.8; man page). Note that in + order for 'relay' and 'ns' to work, name service lookups must work + before the bridge is enabled. This is an example of + making sure that you set the IP on the correct network card. + Alternatively it is possible to specify the IP address instead of the + host name (required if the machine is IP-less). + + People that are used to setting up firewalls are probably also used + to either having a 'reset' or a 'forward' rule for ident packets + (TCP port 113). Unfortunately, this is not an + applicable option with the bridge, so the best thing is to simply pass + them to their destination. As long as that destination machine is not + running an ident daemon, this is relatively harmless. The alternative is + dropping connections on port 113, which creates some problems with + services like IRC (the ident probe must timeout). - The only other thing that is a little weird that you may have noticed - is that there is a rule to let ${us_ip} speak and a separate rule to - allow the inside network to speak. Remember that this is because the - two sets of traffic will be taking different paths through the kernel - and into the packet filter. The inside net will be going through the - bridge code. The local machine, however, will be using the normal IP - stack to speak. Thus the two rules to handle the different cases. The - in via ${oif} rules work for both paths. In general if you use in via - rules throughout the filter, you will need to make an exception for - locally generated packets, because they did not come in via - anything. + The only other thing that is a little weird that you may have + noticed is that there is a rule to let the bridge machine speak, and + another for internal hosts. Remember that this is because the two sets + of traffic will take different paths through the kernel and into the + packet filter. The inside net will go through the bridge, while the + local machine will use the normal IP stack to speak. Thus the two rules + to handle the different cases. The 'in via + fxp0' rules work for both paths. In general, if + you use 'in via' rules throughout the filter, you will need to make an + exception for locally generated packets, because they did not come in + via any of our interfaces. Contributors - To some extent the material for this discussion is a combination of - the items that were discussed by Luigi Rizzo in his Dummynet lecture at - FreeBSDcon '99 and by Mark Murray during his Network Security lecture. - In addition, for quite some time now I have been putting together - filtering bridges for friends and colleagues who were getting DSL - connections for their home. - -
+ Many parts of this article have been taken, updated and adapted from + an old text about bridging, edited by Nick Sayer. A pair of inspirations + are due to an introduction on bridging by Steve Peterson. + + A big thanks to Luigi Rizzo for the implementation of the bridge + code in FreeBSD and for the time he has dedicated to me answering all of + my related questions. + A thanks goes out also to Tom Rhodes who looked over my job of + translation from Italian (the original language of this article) into + English. + +