Requiring a Default Gateway

Overview

Typically, multiple problems with routing will exist at this point of the network setup. This tends to be one of the less glamorous aspects of the entire process, because it's all about fixing something (network communications) using devices that already exist (NICs), rather than seemingly creating something new.

However, repairing these routing issues is an activity that really does need to be done, sometime, in order to have a nice network at the end. This point, of the whole process, is probably as good of a time as any.

Address comparisons

There are a number of addresses that are mentioned. They will need to be handled accurately. This may be less exciting, but the details are quite critical. So, make sure things are done correctly. Part of the process of doing things correctly is to be careful to correctly type in commands.

Another key part of handling this correctly is to choose the right addresses. As noted by demonstration subnets, the sample addresses should be customized. So, you really ought to be using some customized addresses. For IPv4, typically this involves using addresses from IETF BCP 5 (commonly referred to as RFC 1918). Those address ranges are:

Some IPv6 addresses have been reserved to offer the same sort of capability with IPv6.

Creating a useful chart

It takes a small bit of time to make the chart, but is expected to help speed up processes when handling firewalls. This speed-up is obtained by helping to correctly match documentation to actual addresses more quickly.

Keep that chart handy. (For example, if you made an HTML version, or a text file, you may wish to keep it in a separate “web browser” tab, for easy access.)

Intro/Initial Setup

Log into both the firewall and the other server, which we will call the “endpoint” server (for the time being). (For the guide that these instructions were initially created for, the “endpoint server” refers to the “automatic addressing server”, which was created for the purposes of running a DHCP server.)

This guide is currently assuming that the systems can communicate with each other.

So far, you may have been working with only IPv6 or only IPv4. Go ahead and assign addresses for both of these address families. That way, we can troubleshoot both address families at the same time. Overall, that may be less work than trying to troubleshoot one, and then later on remembering the process well enough to successfully troubleshoot the other.

Adjusting routing: Part 1

For most systems, routing can easily be configured rather automatically. For IPv4, that is often done using information that is obtained using DHCP/IPv4. However, that won't work for the DHCP/IPv4 server itself. For that system, the routing will need to happen a bit more manually.

First, let's verify the first problem that is likely to be fixed.

Packets don't get sent out
Some info gathering

On the firewall, figure out the IP address of the first NIC.

ifconfig em0

e.g.:

user@ttyC0:firewall:~/$ ifconfig em0

In this example, we'll assume the address is 198.51.100.250 (which could be in a subnet as small as a /30) and 2001:db8:8::a (which could be in a subnet as small as a /126). If everything has been set up correctly, then the netmask is not a value that will need a lot of attention for this particular part.

The IP addresses shown are values are based on demonstration subnets. Presumably, for an actual network, different values will be used, and those different values will be nicely written down in some network documentation. Feel free to follow along by typing commands that refer to the corresponding addresses that are actually being used on the network.

Also, on the same firewall, figure out the address of the second NIC.

ifconfig em1

e.g.:

user@ttyC0:firewall:~/$ ifconfig em1

In this example, we'll assume the address is 198.51.100.1 (which could be in a subnet as small as a /30) and 2001:db8:1::1 (which could be in a subnet as small as a /126). If everything has been set up correctly, then the netmask is not a value that will need a lot of attention for this particular part. These values are based on demonstration subnets. Presumably, for an actual network, different values will be used, and those different values will be nicely written down in some network documentation.

Problem detection/verification

Now, on the endpoint system, try to communicate with the nearest NIC (e.g. em1) on the firewall.

user@ttyC0:endpoint:~/$ sudo ping6 -c 2 -i .5 2001:db8:1::1
user@ttyC0:endpoint:~/$ echo ${?}
user@ttyC0:endpoint:~/$ sudo ping -c 2 -i .5 198.51.100.1
user@ttyC0:endpoint:~/$ echo ${?}

In both cases, the echo command shows a value of zero (“0.

Now, on the endpoint system, try to communicate with a further NIC (e.g. em0) on the firewall.

Note: It is normal that the first command will take a while to run. (In theory, the time would be twice of the default maxwait. The default maxwait is 10 seconds. However, in reality, this has been seen to take approximately 35 seconds.)

user@ttyC0:endpoint:~/$ time ping -c 2 198.51.100.250
user@ttyC0:endpoint:~/$ echo ${?}
1
user@ttyC0:endpoint:~/$ sudo ping6 -c 2 -i .5 2001:db8:8::a
ping6: UDP connect: No route to host
user@ttyC0:endpoint:~/$ echo ${?}
1
user@ttyC0:endpoint:~/$

(It is believed that tcpdump would show that the packets do not leave the source machine.)

Solution

The ping6 command's output provided a key clue. The endpoint system may be missing the route.

Fixing issue (immediate fix)

Here is the most widely supported syntax to view a route:

netstat -nr

That command works on Unix-type systems and even Microsoft Windows.

Alternatively, there may be additional ways to view routes. However, these may vary a bit more, with some systems using slightly different syntax than other systems.

Microsoft Windows
route print
OpenBSD
route show
GNU/Linux operating systems
Traditional:
route
Using the ip command:
ip route

(Further details may be forthcoming.)

Viewing routing tables

Check current routes

Before mucking around with changes, it makes good sense, as a habit, to see what is currently set up.

First, check what routing currently exists. On the endpoint system, run:

netstat -nr | grep -v lo0

or

route -n show | grep -v lo0
viewing routes
Remove route

It is possible that an invalid route may pre-exist. For instance, if Qemu's internal SLiRP-based network stack had a DHCP server, then the machine may have created a route based on that information. After fixing Qemu so that it is not using the SLiRP-based network stack, old information may still be operational, and in the way. In that case, the right information will not be addable (easily) until the wrong information is out of the way, first.

sudo route delete default
Add route

Add the firewall to the endpoint system's default route.

sudo route add default 198.51.100.1

e.g.:

user@ttyC0:endpoint:~/$ sudo route add -inet default 198.51.100.1
add net default: gateway 198.51.100.1
user@ttyC0:endpoint:~/$ echo ${?}
0
user@ttyC0:endpoint:~/$ sudo route add -inet6 default 2001:db8:1::1
add net default: gateway 2001:db8:1::1
user@ttyC0:endpoint:~/$ echo ${?}
0
user@ttyC0:endpoint:~/$
View updated route

The previous commands can be performed again. (Use netstat -nr or one of the alternative methods, shown in the prior notes, for viewing the route.)

Retry problem

The IPv4 command's syntax has been slightly altered, just to speed things up. (In general, it is a bad idea to verify that a problem is fixed by using an altered test. In this case, the test is being intentionally altered in order to demonstrate some options to the ping commands.)

user@ttyC0:endpoint:~/$ time sudo ping -c 2 -i .01 198.51.100.250
user@ttyC0:endpoint:~/$ echo ${?}
0
user@ttyC0:endpoint:~/$ sudo ping6 -c 2 -i .5 2001:db8:8::a
user@ttyC0:endpoint:~/$ echo ${?}
0
user@ttyC0:endpoint:~/$
Stabilizing Fix

Make the computer apply this behavior after the computer reboots.

Identify the exact command that were used for adjusting the IPv6 route, and the exact command that were used for adjusting the IPv4 route. The following might be useful:

history | grep route | grep -v grep | cut -f 2 | tail -20

The precise method may vary based on operating systems.

Stablizing default gateway setting in OpenBSD
cpytobak /etc/hostname.em0
echo !route add -inet6 default 2001:db8:1::1| sudo -n tee -a /etc/hostname.em0
echo !route add -inet default 198.51.100.1| sudo -n tee -a /etc/hostname.em0
echo ${VISUAL}
sudoedit /etc/hostname.em0
sudo route delete -inet6 default
echo ${?}
sudo route delete -inet default
echo ${?}
sudo ${SHELL} -c ". /etc/netstart em0"