Post Installation

Table of Contents

1. Adding the “inside” Interface
2. Configuring Basic NAT
3. Configuring IPv6 Router Advertisements and a Static Address
4. Pruning Services
5. The Internet Super Server
6. Access Control using TCP Wrappers
7. Assessment
8. [Appendix] Building a Replacement radvd Package

In the previous lab, we installed our server virtual machine, Server1, applied a bunch of updates, and moved it into our production environment. In this lab, we’re going to continue from there, and actually make it part of the same network as our client, set up some IPv4 and IPv6 addressing and run a few tests. We shall also spend some time looking at one way of creating network services, as well as one common way to restrict access to network services.


Except where explicitly noted (typically in command prompts, but also in the text), all work is to be performed on the server you installed previously. You will also need Client1, but nothing else.

1. Adding the “inside” Interface

Currently, Server1 has been moved from the nursery into the production, and its “outside” interface is configured to attach to VirtualBox’s “NAT”, allowing it to access the outer (campus) network without the server needing an address on the outer network. But with this attachment comes a restriction; we can’t talk to other virtual machines. We want our virtual machines to all be connected to each other in a dedicated LAN.

We could re-attach the “outside” interface of Server1 to the internal network, which would allow us to connect with Client1, but that means we wouldn’t be able to connect to the outer network if we needed packages. That’s really annoying.

To solve this problem, we shall add another apaptor to VirtualBox, and configure the new interface as the “inside” interface. This will allow us to create a “dual-homed” configuration whereby we can talk to both the outside world and the internal network.

Shutdown the server cleanly. It needs to show its status as “Powered off”. If it is showing as “Saved” you will need to start it, then shut it down cleanly using shutdown -h now.

In the VirtualBox network setting for the server, leave Adaptor 1 as it is (it should be attached to NAT), and go into Adaptor 2. Enable the interface and attach it to the Internal Network “TELE301 Internal Network 1”.

Start the server. To prevent confusion, use the same method we used in an earlier lab to change the interface name from “eth1” to “inside” (hint: /etc/udev/rules.d/70-persistent-net.rules).

Change the network interface configuration inside the server by editing the file /etc/network/interfaces.

auto outside
iface outside inet dhcp

auto inside
iface inside inet static

Affect the changes by rebooting.

# shutdown -r now

Check that everything is now as expected, taking a screenshot of each test. First, are the interfaces configured as we would expect?

$ ifconfig insideIP address should be
$ ifconfig outsideIP address should be

Okay, now check that the routing table is as we expect, with a default route going out the “outside” interface:

$ route
Destination     Gateway      Genmask        … Iface        *    … outside     *    … inside
default        … outside

Finally, a “test by doing”: can we get to the package repository?

# apt-get update
Fetched 565kB in 6s (87.56kB/s)     Success!
Reading package lists... Done

Testing by doing

How might you test if a web server is working? You could look to see if it running (pstree etc.), but that isn’t an exhaustive test. It is much better to simply retrieve a page (possibly multiple pages), which tests the entire “stack”. Testing by doing is a great way of testing for success conditions, but is not a good way of diagnosing faults.

Okay, so now we know that Server1 can talk to the world. Let’s re-introduce Client1 into the network so we can test that we can communicate with hosts in the internal network.

Before you start Client1, go into the settings for tele301-client1 and ensure that the network adaptor Adaptor 1 is connected to the Internal Network “TELE301 Internal Network 1”. Then start Client1.

If you recall, in the lab on basic interface management, we only gave Client1 a temporary IP address, and did not make a permanent configuration. Let’s create one now. On Client1, edit /etc/network/interfaces and replace the stanza for iface eth0:

auto eth0
iface eth0 inet static

Affect the change using ifup:

client1# ifup eth0
ssh … we can ignore such lines
client1$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 08:00:27:99:c2:7d  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::a00:27ff:fe99:c27d/64 Scope:Link
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:5000 (5.0 KB)

Ensure you get the IPv4 address specified. Take a screenshot to show that you have successfully given Client1 its address.

We added Client1 to the network to ensure that Server1 could talk to other internal hosts, so let’s test that now. Still on Client1, let’s check that we can ping Server1:

client1$ ping -c2
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=3.39 ms
64 bytes from icmp_seq=2 ttl=64 time=0.358 ms

--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.358/1.874/3.391/1.517 ms

That worked, which means traffic can flow in both directions. To be doubly sure[42], let’s try the same thing on Server1:

server1$ ping -c2
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=4.88 ms
64 bytes from icmp_seq=2 ttl=64 time=0.385 ms

--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.385/2.636/4.887/2.251 ms

Hooray! So we know local deliveries are working on the internal network. Time to go onto the next section.

[42] At present, its not actually needed, but in general, because of devices such as firewalls and NAT, it pays to test both directions if needed.