Section 40.1. Objective 2: Configuring a Router


40.1. Objective 2: Configuring a Router

This Objective is perhaps a bit misnamed. It might better be called "configuring a firewall," which is what all the activities listed in this Objective turn out to be. (A router usually contains firewall software, though, and effectively does firewall-like work while it filters traffic.)

To be able to set up a good firewall, you'll have to study a book or two on firewalls; this section of the book is only an overview of key tasks. First we'll get the Linux box to do routing, then protect the network it routes with firewall rules and NAT.

40.1.1. The Example Networks

For this objective, we'll use a quite simple example throughout. The small company Example Incorporated (motto: "Set an example") has a cheap SDSL subscription with one fixed IP address and a very simple internal network on which they house one web server, a file and network server, and some clients. A network diagram is shown in Figure 40-1.

Figure 40-1. Network diagram for example network


When working with a firewall and doing routing, it's quite important to have a network diagram. It helps you check that you got all the directions, routings, filters, and so on straight. It's also very good to have when you are called in at odd hours to fix an urgent problem, because someone may well be working to a deadline and need you to fix a broken Internet connection as quickly as possible.

Before establishing a firewall/router, as well as all the time afterward, you should keep a written list of what the configuration should be like, so as to have something to compare your configurations and rulesets with if things seem to be broken. You can then follow the flow of a web connection through the rulesets rule by rule, checking that all the needed rules are there and that no rule that has no business in the firewall rules got in there by accident. Keep records somewhat along these lines:


Outside the firewall

  • Firewall outside interface: eth0, address 172.20.12.88.

  • Network: 172.20.12.0/255.255.252.0 (/22)

  • Default router: 172.20.12.1

  • Name servers: 62.179.100.29, 62.179.100.30, 213.46.243.88


Inside the firewall

  • Firewall inside interface: eth1, address 10.0.0.1

  • Network: 10.0.0.0/255.255.255.0 (/24)

  • Web server: 10.0.0.2

  • File server: 10.0.0.5

  • DHCP range: 10.0.0.130-10.0.0.200


Outgoing traffic

Allow all outgoing traffic


Incoming traffic

Deny all incoming traffic, except:

  • TCP port 80 (Web): Forward to web server

  • TCP port 22 (ssh): Forward to file server

  • TCP port 443 (IMAPS, IMAP over SSL): Forward to file server

40.1.2. Getting Routing Working

This is the first thing to do before setting up a firewall on your Linux machine. If you start filtering traffic before you even start routing, you won't know whether the routing works, and then you can't be sure whether it's the routing or the firewall ruleset biting you when traffic fails to flow. For routine, you need two working network interfaces, with networks on both. The networks should be minimally configured. There should also be a routing table making it possible for the firewall to reach both the outside network and the inside network. Keep in mind that there is no security yet, so make sure there are no production hosts connected to the router or the Internet. Use only hosts that you are confident are secure and that do not contain sensitive data.

You should be able to verify your hardware and network software as follows:

 # ifconfig eth0      Link encap:Ethernet  HWaddr 00:10:5A:FB:F0:D2           inet addr:172.20.12.88  Bcast:80.111.71.255  Mask:255.255.252.0           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:4408974 errors:3 dropped:0 overruns:3 frame:3           TX packets:3558877 errors:0 dropped:0 overruns:0 carrier:0           collisions:248 txqueuelen:100           RX bytes:1628403600 (1.5 GiB)  TX bytes:293411709 (279.8 MiB)           Interrupt:3 Base address:0x300 eth1      Link encap:Ethernet  HWaddr 00:02:2D:49:D7:05           inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:3823262 errors:0 dropped:0 overruns:0 frame:0           TX packets:4693316 errors:78 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:100           RX bytes:265557294 (253.2 MiB)  TX bytes:2232883546 (2.0 GiB)           Interrupt:5 Base address:0x100 ... # netstat -rn Kernel IP routing table Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface 10.0.0.0        0.0.0.0         255.255.255.0   U        40 0          0 eth1 172.20.12.0     0.0.0.0         255.255.252.0   U        40 0          0 eth0 0.0.0.0         172.20.12.1     0.0.0.0         UG       40 0          0 eth0 

If you compare this to the network diagram, it should match neatly.

If you now execute the following command, your router will start routing. But since you use a private address space on the inside, the outside will not know how to send traffic back to you, so it won't be working for any practical purposes. Still, if you use tcpdump on the outside interface, you should see packets from the inside leave the interface on their way into the world. It won't start working for real until you have NAT configured later in this objective.

 echo 1 > /proc/sys/net/ipv4/ip_forward 

40.1.3. Firewall Rulesets

With Linux 2.2 kernels, firewalls were set up with ipchains. This is pretty much obsolete by now, as 2.4 and 2.6 kernels dominate the Linux world, and these kernels use iptables. Many things are about the same with these firewall implementations, but there are also significant differences that concern even a novice firewall administrator.

40.1.3.1. ipchains versus iptables

At the user level, the main differences between ipchains and iptables is the way packets are processed when they're routed from an input interface to an output interface. The flow of traffic in ipchains is shown in Figure 40-2, whereas the flow for iptables is shown in Figure 40-3.

Figure 40-2. Chains and traffic flow in ipchains


Figure 40-3. Chains and traffic flow in iptables


Considering ipchains first, you can see from Figure 40-2 that a packet from the inside network destined for the Internet will hit the input chain first. Here it will be accepted or denied. It then hits the packet router, which sees that the packet is not for local delivery and finds that the packet's destination fits the default routing, which leads it to eth0. The packet then passes the forward chain, unless it's rejected there, before it is sent to the output chain, where it again is checked and passed or dropped.

If the packet was destined for the local host, it gets to the receiving process directly from the packet router. When a process on the host wants to send traffic, it is checked against the output chain. Note that traffic to and from local processes do not pass the forward chain; only packets in transit do. In our example, the forward chain would contain a rule to masquerade outgoing trafficin other words, make it look as if all outgoing traffic comes from the firewall. This is because the firewall has a public IP address, so the return traffic will find its way back to the firewall, and then the demasquerade mechanism will translate the addresses back to the original, internal addresses and pass the traffic directly to the firewall's output chain. In other words, with masquerading, the return traffic bypasses the forward filter.

It is worth noting that ipchains does not support stateful packet processing. In other words, you can't say: "Let all related traffic pass" or "Let the return traffic for all established connections pass." This valuable feature was developed for iptables .

As Figure 40-3 shows, iptables packet processing is quite a bit simpler than ipchains. The PREROUTING and POSTROUTING tables are the first and last tables to touch traffic, and they process all traffic. They are used for address translation. For example, changing the destination (port forwarding) of an incoming packet is done in PREROUTING, while different kinds of NAT are usually done in POSTROUTING. The destination of the packet when it hits the router determines its later fate: either local delivery through the INPUT chain or forwarding through the FORWARD chain. Any traffic originated locally is sent through the OUTPUT chain.

Given iptables supports stateful packet processing, as mentioned earlier, and that there are protocol agents that understand FTP and other complex protocols, so you can support them easily, there is not much reason to keep using ipchains.

40.1.3.2. Antispoofing

Attacks done by spoofing, or forging, the source addresses of packets to get past security mechanisms crop up in many contexts. For example, quite some time ago a security problem involving NFS was discovered. A security exploit was published that managed to alter NFS exported files by sending just one UDP packet to an NFS server. No answer was needed back; this one packet just had to be sent and accepted. NFS relies on IP authentication, but forging a source address is not hard, so the attack was quite deadly. There are many interesting new and old ways to use spoofing, and you should do your best to stop it at your firewall. On Linux, a shell loop like the following enables antispoof checking on all interfaces:

 for f in /proc/sys/net/ipv4/conf/*/rp_filter; do      echo 1 > $f done 

When this value is set, Linux checks the source address of packets against the routing table. Referring back to our example network, the checks work like this: a packet arriving at eth1 is supposed to be on the internal network and therefore can have only source addresses in the 10.0.0.0/255.255.255.0 subnet. A packet arriving at eth0, which has the default or "any" routing, can have any source address except those allowed on the other interfaces on the machine. This mechanism is unchanged since at least Linux 2.2. If this is not correct in your network, however, this antispoof mechanism cannot be used and you will have to write explicit rules against spoofing yourself.

40.1.4. Using ipchains

The older Linux firewalling system used ipchains for packet filtering and ipmasqadm for masquerading.

40.1.4.1. ipchains

The general syntax for ipchains is:

 ipchains main_option chain [specification] [ -j target ] 

A variety of subcommands can be issued within ipchains. Table 40-1 lists the six most common options, their usage, and descriptions of what the options do. For a complete list, view the ipchains (5) manpage.

Table 40-1. Options for ipchains

Main option

Usage

Description

-A

ipchains -A chainrule

Append a rule specification to end of specified chain. This is what you usually want.

-D

ipchains -D chainrule

Delete a rule from specified chain.

-n -L

ipchains -n -L [chain]

List all rules in selected chain. If no chain is specified, all rules are listed. The -n option stops ipchains from trying to resolve IP numbers and ports to names, which usually slows it down a lot.

-F

ipchains -F chain

Flush all rules from selected chain.

-P

ipchains -P chaintarget

Set the policy of the specified chain to the given target.

-h

ipchains -h

Print a help message.


Rule specifications are required when you add (-A) or delete (-D) a rule. Several parameters can be used for rule specifications . Five popular rule specifications are:


-p

Specifies a protocol. The protocol can be tcp, udp, icmp, or all.


-s

Specifies the source address. The source can be name of host or network, or an IP address.


-j

Specifies a target to a rule, meaning what to do if a packet matches.


-i

Specifies the interface the packet source came from.


-y

The packet is a SYN packet generated as part of an opening TCP handshake. SYN+ACK will not match this.

When specifying your rule, you can specify several types of targets. The target is what happens when your rule specifications are matched. The most common target values are explained in Table 40-2.

Table 40-2. ipchains targets

Target

Description

ACCEPT

Allow packet through.

DENY

Drop packet without attempted to notify the sender.

REJECT

Similar to DENY, but send an ICMP message back to sender stating that the packet was dropped.

MASQ

Used only in forward chains (or user-defined chains). Requires CONFIG_IP_MASQUERADE to be compiled in the Linux kernel. Packets are masqueraded as if they originated from local host. (Reverse packets are also demasqueraded automatically, bypassing the forwarding chain.) Masquerading is described in more detail later in "ipmasqadm."


Then there is one special usage to masquerade the inside network:

 ipchains -P forward DENY ipchains -A forward -s 10.0.0.0/24 -j MASQ 

Because masquerading bypasses the forward chain, you can close that chain entirely. But if you have any public addresses on the inside network that are not masqueraded, you must set the forward policy to ACCEPT or insert detailed rules to forward the traffic from those systems.

40.1.4.2. ipmasqadm

ipmasqadm allows port forwarding of different kinds. Only one kind is interesting to us here. The command to do port forwarding looks like this:

 ipmaswadm portfw -a -P tcp -L local_address local_port \    -R remote_address remote_port 

The local address must be the firewall's own address, and the port must be the port the traffic is addressed to on the firewall. The traffic will be forwarded to the remote address and port.

40.1.4.3. Sample ipchains setup

The following is a complete script matching our example setup . The comments in the file should be enough to let you understand it. The one extra syntax issue worth noting is that an exclamation point (!) reverses the effect of the following clause. For instance, because -y means "match a TCP SYN packet, ! -y means "match any packet that is not a TCP SYN packet."

 #!/bin/sh # Useful variables ALL="0.0.0.0/0"# Anything # OUTSIDE INTERFACE OUTIF=eth0 OUTIFA=172.20.12.1# Outside interface address OUTNA=80.11.68.0# Outside network address OUTNM=255.255.252.0# Outside netmask OUTNET="$OUTNA/$OUTNM"# Outside subnet # INSIDE INTERFACE INIF=eth INIFA=10.0.0.1                  # Inside interface address INNA=10.0.0.0                   # Inside network address INNM=255.255.255.0              # Inside netmask INET="$INNA/$INNM"# All addresses on the inside WEBSERV=10.0.0.2 FILESERV=10.0.0.5 # Enable antispoofing. for f in /proc/sys/net/ipv4/conf/*/rp_filter; do      echo 1 > $f done # Flush ipchains rules. ipchains -F # Default Policies ipchains -P input REJECT ipchains -P forward REJECT ipchains -P output ACCEPT # Masquerade the internal network; all outgoing traffic will get the # firewall's address. ipchains -A forward -s 10.0.0.0/24 -j MASQ # All TCP traffic from the inside is acceptable. ipchains -A input -p TCP -s $INET -j ACCEPT # Web is always allowed and forwarded to the web server. ipchains -A input -p TCP -d $ALL 80 -j ACCEPT ipmasqadm portfw -a -P tcp -L $OUTIFA 80 -R $WEBSERV 80 # And SSH is always allowed and forwarded to the file server. ipchains -A input -p TCP -d $ALL 22 -j ACCEPT ipmasqadm portfw -a -P tcp -L $OUTIFA 22 -R $FILESERV 22 # IMAPS is always allowed and forwarded to the file server. ipchains -A input -p TCP -d $ALL 443 -j ACCEPT ipmasqadm portfw -a -P tcp -L $OUTIFA 443 -R $FILESERV 443 # Let ICMP through to enable ping, path mtu discovery, # ECN, and other good things. ipchains -A input -p ICMP -j ACCEPT # Accept DNS answers from the outside. ipchains -A input -p UDP -s $ALL 53 -j ACCEPT ipchains -A input -p TCP -s $ALL 53 -j ACCEPT # Put these at the end:  Incoming TCP SYN is not allowed except # on connections opened earlier. ipchains -A input -i $OUTIF -p TCP -d $DMZNET -y -j DENY ipchains -A input -i $OUTIF -p TCP -d $INET -y -j DENY # But we must allow incoming TCP non-SYN, because that is the return # traffic from outgoing traffic. ipchains -A input -p TCP -d $DMZNET ! -y -j ACCEPT ipchains -A input -p TCP -d $INET ! -y -j ACCEPT # Rules set, we can enable forwarding in the kernel. echo "1" > /proc/sys/net/ipv4/ip_forward 

The hardest part about using ipchains is remembering that openings for traffic in one direction are not enough, as the comments on the closing rules say. Due to the lack of state in the system, you actually have to let in all traffic that comes knocking on the outside interface, because it includes return traffic from outgoing connections. The only packets that can be barred are incoming SYN packets. This at least stops outsiders from starting new TCP connections, except at the ports opened previously: 22, 80, and 443, along with 53 for DNS.


Warning: These commands just illustrate some of the possibilities and typical uses for ipchains. Don't just copy the ruleset and configure it on a real firewall. It would not be very secure or easy to work with. It would not be secure because there are many more things that should be blocked. Nor would it be easy to work with, because you want more logging to help you find out where this or that packet ended up when debugging the rules.

40.1.5. Using iptables

While people usually refer to the Linux's firewall code by the name of the command used to manipulate the rules, such as ipchains and iptables, the more proper name for the iptables implementation is Netfilter; that refers to the firewalling subsystem the kernel developers work on.

40.1.5.1. The iptables command

The iptables command is a lot like the ipchains command, which is not too surprising because the same person wrote both. The general format is:

 iptables -main_option chain [specification] [ -j target ] 

The main options are the same as ipchains: -A, -D, -n -L, -F, -P and -h.

The specifications are pretty much the same, but long alternatives are now present, which can make reading the rules much easier. Furthermore, built-in chain names are in all uppercase.


-p, --protocol

Specifies the protocol. The protocol can be tcp, udp, icmp, or all.


-s, --source

Specifies the source address. It can be a hostname or network or an IP address.


-d, --destination

Specifies the destination address. It can be a hostname or network or an IP address.


-j, --jump

Specifies what to do if the specification matches the packet being processed.


-i, --in-interface

Specifies the interface the packet came from. This is allowed only in the INPUT, FORWARDING, and PREROUTING tables.


-o, --out-interface

Specifies the interface the packet will be sent out from. This is allowed only in OUTPUT, FORWARDING, and POSTROUTING tables.


--dport, --destination-port

Specifies the destination port of the packet.


-m state, --state state

The -m option ties into a module. Here we discuss only the state module, which keeps connection state. When you select this, rules can specify connection states such as ESTABLISHED, INVALID, or RELATED or a comma-separated list of such states.

The rule targets in iptables will be familiar: ACCEPT, DROP, DENY, and MASQUERADE. DENY is used instead of REJECT. An additional target used for port forwarding is DNAT. A rule that uses DNAT takes an additional option that specifies the address to redirect to and optionally the port, if that too is to be changed. An example use of DNAT is:

 iptables -t nat -A PREROUTING ... --jump DNAT --to address[:port ] 

40.1.5.2. Example netfilter configuration

As with the ipchains example, you should be able to understand what the following script does from the previous explanation:

 #!/bin/sh IN_IF=eth1 OUT_IF=eth0 modprobe ip_conntrack # Establish antispoofing for f in /proc/sys/net/ipv4/conf/*/rp_filter; do      echo 1 > $f done IN_NET=10.0.0.0/24 IN_NW=10.0.0.0 IN_BC=10.0.0.255 ANY=0/0 FILESERV=10.0.0.5 WEBSERV=10.0.0.2 # NEW connections to the inside network that should be accepted iptables -N new_net iptables -A new_net -p tcp --dport imaps --destination $FILESERV \                          --jump ACCEPT iptables -A new_net -p tcp --dport ssh   --destination $FILESERV \                                                          --jump ACCEPT iptables -A new_net -p tcp --dport 80    --destination $WEBSERV \                                                          --jump ACCEPT iptables -A new_net --jump RETURN # INPUT traffic is for the firewall iptables -A INPUT -m state --state INVALID               --jump DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED --jump ACCEPT # We basically trust our loopback-interface iptables -A INPUT -i lo  --jump ACCEPT # Not much that is acceptable :-) iptables -A INPUT --jump DROP # Packets to and from the network iptables -A FORWARD -m state --state INVALID --jump DROP iptables -A FORWARD -m state --state ESTABLISHED,RELATED --jump ACCEPT # Accept all traffic from the inside interface iptables -A FORWARD -i $IN_IF -m state --state NEW       --jump ACCEPT # Traffic from the outside interface is checked by new_net iptables -A FORWARD -i $OUT_IF -m state --state NEW --jump new_net # All else is junked iptables -A FORWARD --jump DROP iptables -A OUTPUT -m state --state INVALID --jump DROP iptables -A OUTPUT -m state --state ESTABLISHED,RELATED  --jump ACCEPT # Connections allowed from the firewall: all UDP, but only DNS over UDP iptables -A OUTPUT -p tcp --jump ACCEPT iptables -A OUTPUT -p udp --dport domain  --jump ACCEPT # Also allow ping iptables -A OUTPUT -p icmp --icmp-type echo-request      --jump ACCEPT # Again: trust the loopback interface iptables -A OUTPUT -o lo                                 --jump ACCEPT iptables -A OUTPUT --jump DROP # ################## NAT # Masquerade all packets passing out from internel network echo Masquerading iptables -t nat -A POSTROUTING -o $OUT_IF --jump MASQUERADE # IMAPS and SSH traffic is meant for file server iptables -t nat -A PREROUTING -i $OUT_IF -p tcp --dport imaps \                                                 --jump DNAT --to $FILESERV iptables -t nat -A PREROUTING -i $OUT_IF -p tcp --dport 22                                                 --jump DNAT --to $FILESERV # Web traffic is for web server iptables -t nat -A PREROUTING -i $OUT_IF -p tcp --dport 80 \                                                 --jump DNAT --to $WEBSERV echo Enabeling forwarding # Enable packet forwarding echo 1 > /proc/sys/net/ipv4/ip_forward echo Done 

Things worth noting in this configuration include:

  • As long as the rules regarding ESTABLISHED,RELATED are in place, all return traffic will be accepted, including the ICMP messages related to TCP connections.

  • The ruleset does not need to contain a rule to accept DNS responses, because responses to outgoing DNS are accepted as part of the ESTABLISHED state.

  • If connection tracking for FTP was enabled (it is not, in the rules shown), both passive and active connections would be allowed in as RELATED. The same goes for the other protocol agents available in Linux 2.4 and 2.6.

As with the earlier ipchains example, this ruleset is not complete. On a real firewall, you should do a lot more to protect yourself, as documented in many books and manpages.

40.1.6. Firewalling Miscellanea

There are a few more points to add to the firewall discussion before you go on to the next Objective.

40.1.6.1. /proc/sys/net/ipv4

Besides ip_forward, the kernel IP stack offers a lot of security-related tuning in the /proc/sys/net/ipv4 directory. By using sysctl or a simple echo command (see Chapter 28) to change these settings, you can do considerable benefit (or damage) to your firewall and network. Linux 2.4 has more than 50 options you can change. The complete list, with very complete descriptions, can be found in the kernel source tree, in Documentation/networking/ip-sysctl.txt. Some of the more useful are:


tcp_ecn

Whether to use explicit congestion notification (ECN). This is a way to signal that there is network congestion. Unfortunately, it breaks brutally if a firewall blocks too many ICMP messages. Therefore the default is still 0, and most administrators should keep it that way.


icmp_ignore_bogus_error_responses

Whether bogus error responses are logged. Usually they are, but that can grow tedious if some device you can't fix is sending them.


ip_dynaddr

If your firewall uses dynamic IP, such as managed by DHCP, PPP, or diald, you should set the value in this file to 1.


tcp_syncookies

When a system is inundated with new connections, it can either be because it is popular or because it is being attacked. An attack known as SYN flooding can cause your TCP state tables to fill up with illegitimate connections, stopping legitimate connections from getting through. If you're fairly sure this is happening and you compiled your kernel with CONFIG_SYNCOOKIES enabled, you can enable a defense to SYN flooding by setting this to 1. It is off by default.

However, note that the syncookies defense breaks the official TCP/IP specification, disables TCP extensions, and renders some clients unable to connect at all.

To help your system cope with too many legitimate connections, look at tcp_max_syn_backlog, tcp_synack_retries, and tcp_abort_on_overflow.


tcp_max_syn_backlog

This sets the maximum of connections remembered while no ACK is received on them. It is 1024 on hosts with more than 128 MB memory, 128 on those with less. Increasing the value may help if you're getting connections faster than they can be completed.


tcp_synack_retries

When a SYN packet is received and a starting connection is in the SYN backlog, this is how many times a SYN+ACK will be retried as long as no corresponding ACK is received. The default of 5 causes the connection to be retried five times, which works out to 180 seconds. You may want to lower this a bit if your system is suffering.


tcp_abort_on_overflow

Zero (disabled) by default. If enabled, your host starts sending RST packets back to clients if a service, such as Apache, is not accepting new connections quickly enough. Doing this may disrupt your clients.


icmp_echo_ignore_broadcasts

Echo broadcasts are sometimes used in DDOS (Distributed Denial of Service) attacks, for a method known as network amplification. For obvious security reasons, all traffic from the outside that is directed to broadcast addresses within your local network should be blocked on an outer firewall (unless you are using this to find out how many hosts on your network are up).


conf/all/accept_source_route

Source routing can be used in attacks involving IP spoofing and has been considered generally harmful for more than 10 years. The default is off.


conf/all/log_martians

A Martian is a packet whose sender the router does not know how to route. A router with a default routing should never see Martians.

40.1.6.2. Saving and reloading rulesets

The ipchains and iptables packages typically include two commands, one to save the ruleset after changes and the other to restore it after a reboot. For the iptables commands, usage is very simple:

 # iptables-save > firewall-rules # iptables-restore firewall-rules 

Many administrators prefer to write an init script that contains a commented and nicely formated ruleset, such as the ones shown earlier in this chapter, to install a known ruleset at each boot. That way, it's easier to relate your current configuration to the documented specifications.

40.1.6.3. NAT and security

While NAT was conceived to solve the problem of running out of IP numbers, and not security, many peope consider sites more secure if internal networks are hidden and use a private IP space.

If a router has no firewall rules, the internal hosts in the network will be unreachable from the outside even if forwarding is enabled (barring tricks with spoofed source addresses and source routing). To allow access to the internal network, firewall rules have to be configured to activate port forwarding and masquerading rules. And once the firewall rules are activated, you will also have protective filtering.

40.1.6.4. Dynamic routing

In an environment that uses dynamic routing , Linux has several ways to manage it. routed uses a mutation of an old Xerox routing protocol, which is not very useful outside pure Unix environments in which all routers support routed. On the upside, routed is pretty automatic and requires only minimal configuration.

Another vintage dynamic routing implementation on Unix is gated, but neither Red Hat nor Debian supports it. If you want standards-based dynamic routing on Linux now, you should install Zebra (known as Quagga on some distributions), which supports dynamic routing protocols of every stripe: specifically, RIPv1, RIPv2, RIPng, OSPF, OSPF6, BGP4+, and BGP4-.

If you're going to run any of these routing systems, remember to make openings for their packets in the ruleset.



LPI Linux Certification in a Nutshell
LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596005288
EAN: 2147483647
Year: 2004
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net