IP Routing

Most sysadmins don’t need to understand much about IP routing, because most servers have only one network interface and one default gateway. The network administrator gives you an IPv4 address and a default route, you put them in the appropriate configuration files, and you’re routed. You don’t need even that for most IPv6 hosts, as autoconfiguration makes things magically work. Servers will need a static IPv6 address and a manual default route.

Some servers have multiple interfaces, such as one to their default gateway and another to a group of related application or backup servers. OpenBSD systems frequently wind up in the network infrastructure, however, or sit in demilitarized zones (DMZs) where the server must make routing decisions. If you want to use OpenBSD in such an environment, or as a firewall, you must understand the basics of routing.

Routing is simply deciding where to send packets. If your system is attached to a network, it doesn’t need to make any decisions; it just sends the packet to that network. Your system on 192.0.2.0/24 already knows how to reach any IP address beginning with 192.0.2—it can just send everything out to the local Ethernet. Where does it send those packets?

Most computers use a default route, which is an IP address on the local network where they send all packets bound for nonlocal IP addresses. This is very common where one router or firewall provides all network access. This device probably also has a default route that points to your ISP, which makes all the complicated routing decisions for you.

In other cases, you might have a dynamic routing protocol running on your network. If you’re using Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), or Routing Information Protocol (RIP), OpenBSD has daemons specifically for integrating these protocols. There’s an introductory middle ground between full dynamic routing and simple default routes, however, and you should understand it before attempting full dynamic routing.

We’ll cover a simple case here using an IPv4 example. (IPv6 routing is exactly like IPv4 routing, but with a lot more colons.)

IPv4 Routed Network Example

If a network has multiple gateways leading to different networks, hosts on the network must make routing decisions. Suppose your network has multiple routers attached to it, each going to a different network. Machines on your network decide where to send packets. Here’s an example of a common double-firewall situation:

image with no caption

In this network design, hosts must transit a DMZ before entering either the Internet or the internal network. (Other designs exist, such as the hub-and-spoke model, but I’ve specifically chosen a design where routing is needed.)

The external firewall provides one layer of protection. It permits only traffic specifically deemed necessary (we’ll go into the default deny stance in Chapter 21). It does, however, permit incoming connections to hosts in your DMZ.

The hosts in the DMZ are to some extent vulnerable. They are not trusted enough to be on the internal network. Your intrusion-detection systems or your web servers might live here.

The internal firewall, like the external firewall, permits only traffic deemed necessary to organization purposes. It probably doesn’t allow any connections from the outside world, however, and it doesn’t trust the hosts on the DMZ.

Only highly trusted hosts are permitted on the internal network. This is where the organization keeps its most precious data, such as the financial records, customer databases, and movie collections.

Many of the hosts in this network need to make only very simple routing decisions. Anything on the internal network has just one way to reach anything, and any host on the Internet has only one way to reach the internal or DMZ networks.

The external firewall is directly attached to the DMZ network, so it can send packets to those hosts. It needs a default route pointing to the Internet so it can reach the rest of the world. To reach the hosts on the internal network, it must send packets to the internal firewall’s external interface. If you don’t configure this on the external firewall, data will never reach the internal firewall. Because the external firewall is responsible for the internal network’s Internet access, losing this route would disconnect the internal network from the Internet; internal systems could send packets, but would never receive any. The external firewall needs routing.

Similarly, you could configure routing on each host inside the DMZ. In that case, ICMP redirects from the firewalls would provide routing for these hosts, but trusting ICMP redirects on a vulnerable network is unwise and messy because it assumes that every host on the DMZ and every firewall accepts and sends ICMP redirects. If you’re using OpenBSD, you want your server to be secure, so configure routing on your DMZ systems.

In this example, I configure routing for the external firewall. Configuring routing for the DMZ hosts is nearly identical to this example.

Managing Routing with route(8)

The route(8) command manages all system routing. Like netstat, route has several subfunctions that allow you to view, edit, and monitor the system routing table. While the route(8) man page has complete details, the ability to view, add, and delete routes should be enough to get you started.

Viewing Routes

OpenBSD, like any other network device, keeps routes in a routing table. To view the IPv4 and IPv6 routes, enter route show. Add -n to remove IP-address-to-name translations.

Here’s the IPv4 routing table:

  $ route -n show
  Routing tables
  Internet:
  Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
1 default            192.0.2.1          UGS        4     6414     -     8 vic0
2 127/8              127.0.0.1          UGRS       0        0 33196     8 lo0
3 127.0.0.1          127.0.0.1          UH         1      170 33196     4 lo0
4 192.0.2.32/24      link#1             UC         1        0     -     4 vic0
5 192.0.2.1          00:0c:42:20:7f:42  UHLc       1        0     -     4 vic0
6 224/4              127.0.0.1          URS        0        0 33196     8 lo0

The table shows the following information:

  • The Destination field lists the range of IP addresses this route applies to—destination addresses. The default entry indicates the default gateway, which is where the system sends all packets that have no specific route.

  • The Gateway field tells where packets for this route should be sent. A gateway could be a hostname, an IP address, or a network interface.

  • The Flags field contains markers that indicate what sort of route this is and how it behaves. The next section covers the various route flags.

  • The Refs field shows the number of references to the route in the kernel (also known as the refcounter). If the refcounter drops to zero, the route is removed. This has no practical use for system administration, because one reference is sufficient to keep the route in the routing table; additional references don’t change anything.

  • The Use counter increments each time a packet uses that route.

  • The Mtu is the MTU—the largest frame size that can travel over this route. If the field contains a hyphen (-), OpenBSD uses the MTU of the underlying physical interface. The loopback interface, lo0, isn’t a physical interface, so OpenBSD explicitly sets the MTU very high. You might see a route with a lower MTU if Path MTU Discovery has kicked in.

  • The Prio field gives the route priority. OpenBSD supports multiple routes to a single destination. Some routes are more desirable than others, and OpenBSD will use the route with the lowest priority number. Routes provided by dynamic routing protocols, such as BGP or OSPF, get higher priority numbers than static routes.

  • The Iface field shows which interface this route uses.

Note

OpenBSD also includes dynamic routing daemons such as ospfd(8) and bgpd(8). I don’t cover them here, because that topic would fill a book on its own.

Let’s see what’s interesting in the routes in this sample. The first entry at 1 is the system default route. If there is no more specific route, packets will be sent to the IP address 192.0.2.1.

To reach the network 127.0.0.0/8 at 2, packets should go to the IP address 127.0.0.1. 127.0.0.0/8 is the address range reserved for loopback addresses, and 127.0.0.1 is always the local machine. Notice the high MTU; this is a software interface, so there’s no physical limit on the size of frames sent through it.

To reach the IP address 127.0.0.1 at 3, send the packets to the IP address 127.0.0.1. This might seem a bit pedantic, but it’s a valid route and needs to be in the table. Remember that 127.0.0.1 is always the loopback address of the local machine.

To reach the IP address 192.0.2.0/24 at 4, use a gateway of link#1. This is a local physical interface—in this case, our Ethernet interface. The interface named link#1 is actually the interface with index #1, which isn’t really exposed to the system administrator anywhere else. These addresses are local to the machine, and you must figure out which interface this is by the IP address attached to the machine. Addresses local to the machine don’t actually need to be in the routing table, but no one has bothered to remove this historical nit.

To reach a specific IP address on the local network at 5, you’ll get a route of the IP address and the physical media address. Because this host is connected via Ethernet, the gateway is a MAC address. Every local address that the system needs to find gets a route entry, and you should almost always show a specific route for the default gateway.

The last route at 6 is for the multicast address range 224/8. If you’re not using multicast, it should go to the local host.

Note

Multicast is a complicated topic beyond the scope of this book (again). But if you’re interested, OpenBSD supports multicast just fine.

Route Flags

The Flags column of the routing table indicates how routes are generated or used. netstat(1) contains a complete list of route flags. Table 11-2 lists the common ones.

Table 11-2. Table 11-2: Common Route Flags

Flag

Description

C

This route was cloned.

c

This is a protocol-specific route (such as to an Ethernet MAC address).

D

This route is dynamic.

G

This route goes via a gateway.

H

This route is for a specific host.

L

This route is for the local link layer.

M

This route was modified.

R

This is a reject route. Packets are dropped, and an error is sent.

B

This is a blackhole route. Packets are dropped silently.

These flags tell you where a route came from and how it’s used.

Adding Routes

Add routes with the route add command. You must know the destination network, its netmask, and the gateway.

# route add address-block/netmask netmask gateway

In our example network, the outer firewall needs a route to reach the private network, 192.0.2.128/25. To route this network to the inner firewall at 192.0.2.2, run this command:

# route add -net 192.0.2.128/25 192.0.2.2
add net 192.0.2.128: gateway 192.0.2.2

Packets will use that route immediately. If you run route show, you’ll see that new route.

To add a default route, run route add default with the IP address of the default gateway, like this:

# route add default 192.0.2.1
add net default: gateway 192.0.2.1

To add routes automatically at boot, put the route statement in the /etc/hostname.if file that leads to the destination network. These routes appear when the interface is brought up, before /etc/rc.securelevel runs or any local daemons start. You’ll see examples of using hostname.if for routes in the next chapter.

To add a default route automatically at boot, put the default router IP address in /etc/mygate.

Deleting Routes

To delete a routing table entry, use route delete with the network address and netmask.

# route delete address-block -netmask netmask

To remove the route added in the previous example, run this command:

# route delete -net 192.0.2.128 -netmask 255.255.255.128
delete net 192.0.2.128

You should now have a decent idea of how routing works.

Now that you know how things are supposed to fit together, let’s see how to configure Ethernet networks.



[27] You laugh, but the technical reviewer for this book was part of the first IP-over-carrier-pigeon implementation team that tackled the practical tests as specified in RFC 1149. That’s how I knew he had the time to review this book in excruciating detail. (If that’s how he spends his time, he couldn’t very well claim he was too busy, now could he?)

[28] I never do take pity on my readers; I just don’t want you to actually say so.

[29] Some operating systems treat addresses containing numbers that begin with 0 as octal. Don’t actually use addresses like 192.000.002.013, or you might get a base-8 surprise.

[30] Or you can go look it up. Whatever—you not believing me won’t hurt my feelings.

[31] For the record, Uncle Mike’s security policy prevents him from passing baked sweet potatoes. If you want them, you’re going to have to take them by force.

[32] I used to count how many people confused 514/tcp and 514/udp, but the number got so high that I got depressed, so I stopped.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.136.226