HOWTO: The Five Minute VPN Guide

UPDATE: 05-06-2012, latest version: VPN v1.03

I posted some time ago a guide for setting up a PPP over SSH vpn but it was a bit clunky and I was never fully happy with it.

So, I have spent some time adding all of the hard work to a fully interactive script that has the following features;

* Automatically configure your client details in a "vpn.conf" file.

* Bi-directional routing between the server and all remote nodes is automatically configured.

* Interactive functions to stop and start the VPN

* Function to check the VPN status, attempts restart if down

* Send email to a specified administrator when the state of the VPN changes.

* Automatic setup of keys for passwordless connections.

* Zero scripting skills required

Audience:

Network admins who want to connect two or more offices using an encrypted, secure VPN over the public Internet. Clients at remote sites will access the Internet directly through their local gateway while all internal traffic is automatically routed via encrypted VPN links back to the central site.

Pre-requisites:

Two debian or ubuntu servers configured as routers, designated as SERVER and CLIENT. Both must be connected to the internet and the SERVER should have a FQDN of some sort (see www.dyndns.com if you don't have your own domain). Assuming you are running a firewall on the server you must poke a hole in it to allow SSH connections from the internet.

Authors Note:

This script started out as a simple clean up of the old one but of course that quickly blew out to a full on rewrite until I ended up with an all singing, all dancing mega-vpn management utility that I reckon is the easiest way to setup a VPN ever. Not one line of the original script remains intact!

Anyway, enough of the chest beating, let's get on with the show!

Step 1: Setting up the Server

Clients connecting to the server will do so using a local account on the server that is specifically used for this purpose.

Create a user called "vpn"

sudo adduser --system --group vpn

The --system parameter has set the vpn users shell to be /bin/false. However, because the vpn user needs to be able to log in via ssh, we must change this to /bin/bash in the /etc/passwd file.

Edit the passwd file;

sudo vi /etc/passwd

Modify the line for the vpn user so that it ends with /bin/bash;

vpn:x:110:110::/home/vpn:/bin/bash

We also need to set a password for the "vpn" account;

sudo passwd vpn

NOTE:

The vpn account password will only be used while doing the initial configuration of your VPN clients. You should choose a reasonably complex (secure) password and not be concerned about making it easy to type or remember.

The vpn user needs to be able to bring the ppp connection up and down as well as modify the system routing table. We will configure sudo to allow access to those commands.

Edit your sudoers file;

sudo visudo

Append these lines to the end of the file;

vpn ALL=NOPASSWD: /usr/sbin/pppd
vpn ALL=NOPASSWD: /sbin/route

Finally, we need to log in as the vpn and set up a few bits in its home folder.

Change to the vpn user;

sudo su vpn

Create an ssh directory;

mkdir .ssh

We need to seed an "active_networks" file with the subnet(s) that the VPN clients should be able to route to (usually the local LAN subnet that your VPN server is on but if you have a more elaborate network there may be multiple subnets. Simply add all the ones that you need remote hosts to route to). The "active_networks" file should be located in the vpn user's home folder (and owned by the vpn user)

Create an active_networks file;

vi ~/active_networks

Add a line for the servers local subnet followed by a hash and the server name.

Example:

10.1.1.0/24 # vpn-server

If you have more than one subnet then you can add them too (on separate lines)

Note:

The active_routes file holds a record of all the remote subnets (VPN network nodes) that the server is connected to. As each client gateway connects to the server it adds it's own LAN subnet to the file. If new routes are added later you can do a "vpn check" on the client gateway which will automatically update the local routing table with any new routes for any other nodes that may have been recently added to your network.

And that's all there is for the server part of this howto!

Yes, seriously.

Step 2: Configuring a Client

Configuring the client is even easier than the server, we just need to download and run my new VPN script.

On the client host, download my vpn client script

Put the vpn script file somewhere in your system path or make a link to wherever you decide to put it.

E.g. sudo ln -s /store/scripts/vpn /usr/sbin/vpn

Install dependencies;

sudo apt-get install ipcalc ppp

And finally, execute the script with the "setup" directive;

sudo ./vpn setup

This will create a default config for your VPN. If this will be the first or only client node to be connected to your VPN server then the only required value is the SERVER_HOSTNAME for the VPN server. This should be a FQDN that is pingable from the Internet. For 99% of scenarios the rest of the default settings will work perfectly fine.

Once you have finished the setup, you can start the vpn;

sudo ./vpn start
Starting vpn to vpn.tuxnetworks.net on port 22 - Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
Deflate (15) compression enabled
local  IP address 192.168.2.2
remote IP address 192.168.2.1
Setting static routes
Added route to 10.1.1.0/24
Added route to 10.48.17.0/24

Check the status of your VPN connection;

sudo ./vpn status
---------------------------------------------------------
Local network : 10.1.3.1/255.255.255.0 [eth0]
Connected to  : vpn.tuxnetworks.net
Remote IP     : 192.168.2.1
Local IP      : 192.168.2.2
PID           : 25493

To have your client check whether the VPN is up (and automatically restart it if it's not) add an entry to your system crontab;

sudo vi /etc/crontab

Add a line like so;

*  *    * * *   root    vpn check >> /dev/null 2>&1

This will run every minute, check the vpn status as well as update any new routes to new nodes that have been added since the last time it was run.

Note:

Of course the vpn script file will need to be in your system path for this cronjob to execute. (See above)

If you also configure an administrator email address (and your system is able to send emails of course) then it will email the administrator every time the VPN link goes down, and again when it comes back up.

I've tried to make the script as simple as possible to use and I hope I have covered all the possible failure scenarios gracefully.

Give it a go and let me know in the comments or send me an email to the address contained in the script header and tell me what you think.

Any and all feedback is welcome.

Cheers!

Getting Up To Speed With IPv6: Basic IPv6 Setup

This is the third in a series of articles that I hope will get you on the road to IPv6 in a relatively painless fashion.

If you arrived here from a search query, you may be interested in reading the Introduction and Setting The Stage articles first.

In order to use IPv6 our router requires a globally routable IP address. This means we cannot use one of the ubiquitous "home network gateways" in it's normal mode of operation as a NAT router as they do not offer native support for IPv6 and we cannot do IPv6 over NAT.

Fortunately, most of these devices can be configured in "bridge" mode which will allow a Debian/Ubuntu server to take over the role of our main Internet router thereby paving the way to IPv6 goodness.

Step 1: Configure A Server As An IPv4 Internet Gateway

Follow the IPv4 router guide found here to prepare your router for IPv6. Come back here when you are finished.

OK, once you have your IPv4 router setup and running we can start adding IPv6 support.

Step 2: Basic IPv6 Functionality

Creating an account with a Tunnel Broker:
The first thing you need to do is visit Hurricane Electric's Tunnel Broker page and sign up for an IPv6 tunnel account.

Once you have created your account we need to configure the tunnel on our router.

Creating an IPv6 tunnel:
Login to your tunnel account and click on "Create Regular Tunnel"

Enter the public IP address of your server in the text field called "IPv4 Endpoint (Your side): (ie: The IP address of your ppp0 adapter)

Choose a tunnel server that is closest to where you are (you can use traceroute to find one with the lowest number of hops or simply go by geographical location). Going with the default server offered is probably the best bet though.

Click on "Create Tunnel"

You should now see something like this;



And that's it, your tunnel has been created!

Configuring Your Tunnel

Now we need to configure our router to use our new tunnel.

As root, edit your interfaces file;

sudo vi /etc/network/interfaces

Add the following lines replacing the parts in [italics] with the address details as provided on your Tunnel Details Page;

auto ip6tunnel
iface ip6tunnel inet6 v4tunnel
address [Client IPv6 Address]
netmask 64
ttl 64
gateway [Server IPv6 Address]
endpoint [Server IPv4 Address]
local [Client IPv4 Address]

Note: When entering addresses, don't include the /n at the end as this is the netmask and is not part of the address. It is worth noting that, unlike IPv4, IPv6 supports only CIDR notation (bitwise) netmasks, decimal netmasks are not supported.

Once that is done, save the file and restart your router, I'll wait here until that's finished.

OK, now let's have a look around and do some tests.

In a shell console, enter;

ifconfig ip6tunnel

ip6tunnel Link encap:IPv6-in-IPv4
inet6 addr: fe80::7b02:25c5/128 Scope:Link
inet6 addr: 2001:470:c:2345::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1472 Metric:1
RX packets:170953 errors:0 dropped:0 overruns:0 frame:0
TX packets:168578 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:140703681 (140.7 MB) TX bytes:20945209 (20.9 MB)

Hopefully you will see similar output to above.

Let's try and ping the Hurricane Electric IPv6 DNS servers. The address for this server can be found on the tunnel details page.

IPv6 uses the ping6 command but it works exactly like "normal" ping;
ping6 -c 4 2001:470:20::2
PING 2001:470:20::2(2001:470:20::2) 56 data bytes
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=64 time=437 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=64 time=474 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=64 time=441 ms
64 bytes from 2001:470:20::2: icmp_seq=4 ttl=64 time=510 ms

--- 2001:470:20::2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 437.905/465.959/510.010/29.213 ms

Awesome. Right now you are probably thinking "I can't believe it was that easy!". Well, hold on there cowboy, it's not over yet. Right now our gateway is the only host on our network that can use IPv6, and it can't even resolve names to IPv6 yet.

We can fix name resolution very easily for now by simply adding an entry for HE's IPv6 DNS server to our resolv.conf file;

sudo vi /etc/resolv.conf

Add an extra nameserver line like so;

nameserver 2001:470:d:1018::1

Let's try pinging a name this time;

ping -c 4 ipv6.tuxnetworks.com
ping: unknown host ipv6.tuxnetworks.com

Oops, don't forget we need to use ping6 instead! Let's try it again;

ping6 -c 4 ipv6.tuxnetworks.com
PING ipv6.tuxnetworks.com(2001:470:c:1004::2) 56 data bytes
64 bytes from 2001:470:c:1004::2: icmp_seq=1 ttl=63 time=227 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=2 ttl=63 time=332 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=3 ttl=63 time=230 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=4 ttl=63 time=227 ms

--- ipv6.tuxnetworks.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms

That's a whole lot better but there are still some things to be done. We will cover those in the next article.

Continue on to Step 3: LAN access and autoconfiguration

P.S. Don't forget that June 8 is IPv6 Day!

Getting Up To Speed With IPv6: Setting The Stage

This is the second article in my series on getting up to speed with IPv6. For the first article look here.

Ideally, to use IPv6 on your network your ISP will simply provide you with an IPv6 address and you will be good to go automagically. In practice, virtually no ISP's at this point are enlightened enough to do this which means we must go out of our way before we can reach the state of IPv6 Nirvana that we so desire.

Here is a list of ISP's that currently support IPv6.

The odds are that your ISP is not on that list.

As a first step, let's check our current IPv6 readiness using the online tool at http://test-ipv6.com/

Your test result will most likely look something like this;



That's OK though, we expected that.

Let's start by summarising the steps we must take to get IPv6 up and running on our networks (assuming our ISP does not provide it for us already).

1) A debian/ubuntu server operating as a IPv4 router.

2) Deployment of an IPv6 tunnel on our router.

3) Configure IPv6 network services for clients

And that is it, really. The first step will require a "non-routing" adsl or cable modem. If you have a typical modem+router[1] device it will need to be configured in "bridged" mode[2]. This can be done in various ways depending on what type of device you have[3]. For obvious reasons I will not be able to provide step by step instructions on how to go about this for every make and model router available, but I will give an example using the Netgear DG834G I use on my own network.

Once this is done, step two will prove to be surprisingly simple. There are numerous free and commercial "IPv6 tunnel brokers" to choose from out there however we are going to use the free service from Hurricane Electric[4].

The third step involves configuring multiple services to make your IPv6 network usable by hosts on your LAN. It will actually be a series of articles for different services.

Continue on to Step 1: Basic IPv6 Setup

P.S. Don't forget that June 8 is IPv6 Day!

[1] It is most likely that your current home network uses a cheap consumer grade "router" which is more accurately described as a "NAT gateway" as it does not do true routing.

[2] You cannot use IPv6 over IPv4 NAT.

[3] Alternately, if you are so inclined, you could also choose to hack the firmware on your existing "router" to use the open source "openwrt" Linux distribution which includes IPv6 support by default. I will not be describing this procedure in this series.

[4] Registration required.

Getting Up To Speed With IPv6: Introduction

With all the news about ipv4 address exhaustion going around not to mention that IPv6 Day is just around the corner I thought it was time that I investigate IPv4's successor, IPv6.

(If you are wondering whatever happened to IPv5 then look here)

The good old IPv4 address that we all currently know and love (and understand, I hope) is basically a 32 bit number divided into four 8 bit "octets".

That gives us a theoretical address space of 2^32 (4.3 billion) addresses.

On the other hand, IPv6 uses 128 bit address's represented as eight groups of four hexadecimal digits, each group representing 16 bits (two octets)

This new address space supports 2^128 (340 undecillion) addresses which is more than we will ever conceivably require on Planet Earth.

Right now you are probably thinking "Yeah, I've heard that before about 640K RAM and we all know how that one worked out" so to put the sheer size of the IPv6 address space into perspective let me quote an excellent IPv6 primer over at Ars Technica, "there are currently 130 million people born each year. If this number of births remains the same until the sun goes dark in 5 billion years, and all of these people live to be 72 years old, they can all have 53 times the address space of the IPv4 Internet for every second of their lives."

Now, I'm sure you'll agree, that is a lot of addresses.

For a good overview of how IPv6 addressing works, I recommend this article.

After reading up a bit about IPv6 you could be excused for concluding that the whole idea of IPv6 is quite daunting and then push the whole damned thing into the "too hard" basket. This is what most people and organisations have been doing up to this point and explains why adoption rates are currently so low.

ISP's in particular are putting off the inevitable by hoarding blocks of the remaining IPv4 space.

Don't be put off by the apparent complexity of IPv6 though!

In practice it is in fact not that hard to get up and running, even if you don't completely understand how it all hangs together at first. I still haven't figured it out properly, but soldier on I will!

As they say, practice makes perfect and this is the intention of the series of articles I will be posting on getting up to speed with IPv6.

Note: A word of warning, these articles are intended to be used for educational purposes only. Because we cannot use an IPv6 address range of our own we are going to be obtaining one through what is known as an "IPv6 Tunnel Broker". This is of course not an ideal situation because we are going to be relying on that broker for all of our IPv6 addresses and routing. I do not advise that you configure a production network for IPv6 connectivity using this guide as you will surely face performance penalties, possible reliability issues, and (most importantly) future migration issues when your ISP eventually starts providing you IPv6 directly. If you are intending to roll out IPv6 in a production scenario I suggest that you choose an ISP that is already providing native IPv6 to their customers.

Next up, Setting The Stage

Adding to system PATH for all users

I have a few scripts that I use to do certain things on my machines. Rather than copy them to /usr/sbin or similar I like to keep them segregated in a "scripts" directory. In this way I can copy them to new machines or keep them up to date using rsync without messing up the standard scripts that ship with Debian/Ubuntu.

To make the scripts executable for users without typing in the full path to the scripts directory you can edit the users bash profile file ".bashrc" and add the path there. However, this gets messy real fast when dealing with lots of users, so we want a way to update the path for every user that logs in. We do this by putting a script in the /etc/profiles.d directory

Note: Scripts in /etc/profile.d are executed whenever a user logs in to a bash session.

Create a file in /etc/profile.d.
sudo vi /etc/profile.d/addpath.sh

Add this line;

PATH=$PATH:/usr/scripts

Log out and log in again and check to see if your path has been updated;

echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/scripts
Enjoy!

HOWTO: MASTER and SLAVE with Bind

So you have built yourself an authoritative nameserver and now you want to build a slave for it to replicate to.

Unfortunately, this is one of those things that is unnecessarily difficult to do on Linux. There are lot's of guides and howto's but they all seem to be missing bits and pieces of the puzzle. The good news is that after a few days of frustration I've figured out how to do it and I'm here to share the secret. Once you know what to do it is really extremely simple.

I'm using Ubuntu LTS Server 10.04 "Lucid Lynx", but as usual any debian based distro should be fine.

Pre-requisites:

Two working authoritative DNS servers built according to this guide. Both of these servers should be able to authoritatively resolve names for your local network.

Note:

In this howto we will using an MD5 key. The key used in this guide is sanitized (ie: not a real key) and should not be used "as is".

Example Network:

For the example network the domain I will be using is tuxnetworks.net, the MASTER server will be on 10.1.1.1 and the SLAVE server on 10.1.1.2. Of course you should substitute these values for ones that are valid on your own network. The two servers will be named ns1 and ns2.

OK, let's get cracking.

First up, before we can start doing zone transfers, we need to enable "dns security extensions" on both servers;

On BOTH servers, edit your named.conf.options file;

sudo vi /etc/bind/named.conf.options

Add this line within the options { }; section;

dnssec-enable yes;

Modify the allow recursions line so that it looks similar to this (using your own IP address's of course).

allow-recursion { 127.0.0.1; 10.1.1.0/24; };

Note:

These are all the hosts and networks that will be allowed to query the server(s) and should include both the Bind servers we are building. Since both our servers are in the 10.1.1.0/24 subnet we don't need to explicitly define them, if they weren't you would put their IP address in here too.

When we install bind, it will create a key that we can use. However, the keys will be different on the two servers. Let's copy the key from the MASTER to the SLAVE.

On the SLAVE, backup the old key file;

sudo cp /etc/bind/rndc.key /etc/bind/default.rndc.key

Cat the rndc.key file on the MASTER;

sudo cat /etc/bind/rndc.key
key "rndc-key" {
 algorithm hmac-md5;
 secret "BCRNAwUG2DRqz3fYleLO/g==";
};

On the SLAVE edit the rndc.key file and change the "secret" so that it is the same as the secret in the MASTER key.

sudo vi /etc/bind/rndc.key

The "secret" line should be changed to look the same as on the MASTER;

secret "BCRNAwUG2DRqz3fYleLO/g==";

Great. Now we need to edit the zone definition files on both servers. If you followed my guide to build your servers then it will be in named.conf.myzone-net. Other guides might put this info into named.conf or named.conf.options. The file is the one with the zone myzone { }; definition for your zone in it.

On BOTH servers, edit your zone definition file;

sudo vi /etc/bind/named.conf.tuxnetworks-net

Add this line to the end of the file.

include "/etc/bind/rndc.key";

Now we reach the part where the MASTER and SLAVE servers are configured differently.

We will begin with the MASTER server. On the MASTER, edit your zone definition file again;

sudo vi /etc/bind/named.conf.tuxnetworks-net

Add this section (using the IP address of the SLAVE server);

server 10.1.1.2 {
        keys {
                rndc-key;
        };
};

Next we configure the SLAVE. Again, we edit the zone definition file;

sudo vi /etc/bind/named.conf.tuxnetworks-net

Inside the definition for the zone change the type from "master" to "slave" and add two lines to define the master servers details and specifically allow it to update the SLAVE.

Here is an example (use the IP address of your MASTER server here);

# This is the zone definition for the tuxnetworks.net zone.
zone "tuxnetworks.net" {
        type slave;
        file "/etc/bind/db.tuxnetworks.net";
        masters { 10.1.1.1; };
        allow-notify { 10.1.1.1; };
};

Also, add another section (using the MASTER IP address) to tell it to use the rndc-key;

server 10.1.1.1 {
        keys {
                rndc.key;
        };
};

And that's it. We also need to ensure that both the servers are listed in the SOA section of your zone file (the zone file is the one where all the IP addresses for your network are located.

On BOTH servers open your zone file;

sudo vi /etc/bind/db.tuxnetworks.net

The top or second line should look like this (ie it should be showing both your DNS servers);

tuxnetworks.net. IN SOA ns1.tuxnetworks.net. ns2.tuxnetworks.net. (

Your NS servers should be defined properly;

; DNS Servers
tuxnetworks.net.        IN      NS              ns1.tuxnetworks.net.
tuxnetworks.net.        IN      NS              ns2.tuxnetworks.net.

We also need to define the IP address for both servers;

ns1             IN      A       10.1.1.1
ns2             IN      A       10.1.1.2

Finally, for replication to occur, the two servers must be in close time sync. To ensure their internal clocks are synced properly, we will install ntpdate on both servers (this may already be installed on your systems)

sudo apt-get install ntpdate

Update the system time on both servers;

sudo ntpdate ntp.ubuntu.com

Check that the times are both in sync with the date command on both servers;

date
Wed Feb 11 10:30:16 EST 2011

Both systems should be within a few seconds. If they are way out, check that the timezones on both systems are the same;

dpkg-reconfigure tzdata

NOTE:

There is a bug in Ubuntu 10.04 bind package. When you it installs bind it fails to set the permissions correctly on the /etc/bind directory. I'm not sure if this affects other debian based distro's or not. A tell tale sign that the bug is in place (apart from slave updates not working) is an error in the syslog "bind dumping master file permission denied". To fix this change the ownership of the directory to the bind user;

sudo chown bind:bind /etc/bind

To make all the changes, restart bind on both servers;

sudo service bind9 restart

To test if your replication is working, go to the master server and edit the zone file. Increment the "serial" by one and issue a reload command on both servers;

sudo rndc reload

Now, if you look at the zone file on the slave, it should have been updated with the new serial.

When you are satisfied that both servers are working properly, you should remember to update your clients (or more likely your DHCP server) so that all your clients use both of your servers for resolving names.

Troubleshooting:
- Check your server times are in sync
- Check the permissions on /etc/bind
- Check that there are no firewalls between the two servers

A word on zone files:

Any time you make a change to the zone file on the master you need to update the serial. There is no set rule as to how the serial number should be formed. It can simply be an integer that you increment for each change if you like. I prefer to use the date in the form YYYMMDD with two trailing digits to allow for multiple increments within a day. That way I can know the date the last time the file was modified. As always YMMV.

I've tried to make this as simple to follow as possible. If there is something I haven't made clear enough then by all means leave me a message in the comments and I will tweak this howto accordingly.

Also, to make things a bit easier, you might like to download copies of all the example config files and modify them to suit your network.

Otherwise, enjoy your new DNS servers!

HOWTO: Configure A Router

Now we get to turn our debian or ubuntu server into a router. Read on!

Prerequisites;
1) A server as per this guide.

2) A working PPPoE or PPPoA based Internet connection. Most consumer ADSL and Cable Internet is provided using one of these protocols, support for which is built into the consumer "router" I am assuming you are currently using.

3) The ISP provided username and password combo for your Internet connection. If you have a "router" that was provided by your ISP they sometimes print these on a label attached to the device, otherwise it will be written on the documentation you received when you signed up (and promptly lost I'm sure). You will have to call your ISP on the actual telephone to retrieve this information if you have lost it.

4) An Ethernet switch and sufficient cables to connect at least two devices. Your current Internet Gateway may currently have the Ethernet switch built in to it. Alternately, you may use a separate switch if you prefer.

5) If you are intending to use a discreet modem (cable or ADSL) and a separate switch then two LAN cards are required. Unless you are one of the incredibly lucky few who have access to FttH you will most likely have some form of ADSL or Cable service with speeds measured in single-figure MegaBits. This means that it is perfectly OK to reuse a discarded old 100baseT adapter (or indeed even a 10baseT if you still have one of those in the antiques cupboard) for your WAN interface. Even the slowest LAN card will be considerably faster than most current Internet connections. If you intend to go down the Router-in-bridged-mode road then a single Ethernet adapter will suffice.

OK, now that you have all the prerequisites in order, and a basic server up and running we can get on with bidness proper.

The first thing we need to do is install a few packages we will need before we disconnect ourselves from the Internet.

apt-get install pppoeconf ppp

Next we configure the LAN side of the network.

Note: I will assume that your LAN adapter is eth0 from this point onwards. If you are using two Ethernet adapters this would make your WAN interface eth1.

Because we are configuring a router, we must use a static IP address for our LAN adapter. If you followed my server guide then you have already done that, otherwise you should backtrack and configure a static IP address as per that guide.

Pro Tip: For testing purposes, I recommend that you configure some other PC on your LAN with a static IP in the 10.1.1.x subnet with a default gateway of 10.1.1.1. We will be using this PC from time to time for testing. This can be either a Linux or Windows PC.

Plug both the server and client hosts into your LAN and check that you can ping the server at 10.1.1.1 from the client.

OK. Once you can ping your server from the test PC we can continue.

The next step varies depending on whether you are using a single adapter and a router in "bridged mode" or a separate modem and 2 Ethernet adapters.

Separate modem and two adapters: You must configure eth1 as per the above instructions for eth0 using any old IP address you like. I suggest you use 192.168.254.254/24. The address will not be used for anything on your network but is required so that the pppoeconf utility in the next section can locate your modem. Make sure you plug your modem into this interface

Consumer router in "bridged" mode: You will need to configure the router in "bridged" mode[1] according to the instructions provided by the manufacturer of the device. On my DG834G it is a simple matter of browsing to http://192.168.0.254/setup.cgi?next_file=mode.htm (where 192.168.0.254 is the address of my gateway) and setting the drop-down box to "Modem Only". I found that info via a Google search here. You should do a Google search for something like my-gw-model-number +"bridged mode" or similar to find instructions on how to configure your particular router.

Once you have your router in bridge mode, we can use the pppoeconf utility to configure a PPP connection to our ISP;

sudo pppoeconf

Go through each screen choosing the default option until you get to the "ENTER USERNAME" screen. Enter the username for your ISP account here.

The next screen asks for your password, enter that too.

In the "USE PEER DNS" screen select "No"

Select the default option on all the remaining screens.

You should now have Internet connectivity on this host. You can check this with the ifconfig command;

ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:123.4.56.789 P-t-P:123.4.8.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:59687317 errors:0 dropped:0 overruns:0 frame:0
TX packets:50606162 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:2967668270 (2.9 GB) TX bytes:2950135549 (2.9 GB)


You should (hopefully) see a ppp0 adapter in the output similar to this. If you do, we should do a few more tests. First, lets check we can ping our DNS server. To find your DNS server type;

cat /etc/resolv.conf

There should be an entry "nameserver" with an IP address in the output.

Let's ping that IP address and see if it works;

ping -c 4 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=322 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=196 ms
64 bytes from 208.67.222.222: icmp_seq=3 ttl=55 time=281 ms
64 bytes from 208.67.222.222: icmp_seq=4 ttl=55 time=547 ms

--- 208.67.222.222 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 196.763/337.020/547.292/129.589 ms

(The IP above is for OpenDNS)

We can test that DNS is working by pinging by name;

ping -c 4 www.google.com
PING www.l.google.com (74.125.237.18) 56(84) bytes of data.
64 bytes from 74.125.237.18: icmp_seq=1 ttl=57 time=261 ms
64 bytes from 74.125.237.18: icmp_seq=2 ttl=57 time=285 ms
64 bytes from 74.125.237.18: icmp_seq=3 ttl=57 time=24.2 ms
64 bytes from 74.125.237.18: icmp_seq=4 ttl=57 time=122 ms

If you got this far then that is great, but please be aware that although our Internet connection is now up and working, we have not done enough to get our LAN clients up and on the 'net. For that we need to configure routing, NAT and a firewall.

We can configure routing by issuing editing the following file;

sudo vi /etc/sysctl.conf

Find the following line and change it from 0 to 1;

net.ipv4.ip_forward=1

To configure an extremely basic firewall, create a file in a suitable location such as /usr/sbin/ with the following contents;

sudo vi /usr/sbin/firewall
8< - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/bash

WAN=ppp0
LAN=eth0

sudo /sbin/iptables --flush

# Accept ALL packets inbound from our local networks
sudo /sbin/iptables -A INPUT -i $LAN -j ACCEPT
sudo /sbin/iptables -A INPUT -i lo -j ACCEPT

# Do NAT for LAN clients
sudo /sbin/iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE

# Allow ping packets
sudo /sbin/iptables -A INPUT -p icmp -j ACCEPT

# Allow returning packets for established sessions
sudo /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all traffic out from this host and our LAN clients
sudo /sbin/iptables -A OUTPUT -j ACCEPT
sudo /sbin/iptables -A FORWARD -i $LAN -j ACCEPT

# Drop all other traffic inbound from the Internet
sudo /sbin/iptables -A INPUT -i $WAN -j DROP
sudo /sbin/iptables -A FORWARD -i $WAN -j DROP
8< - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Note: This is not a particularly secure firewall, it basically allows any host on your LAN to send anything out and only drops unwanted packets coming in via the WAN interface (ppp0).

Make the firewall script executable;

chmod +x /usr/sbin/firewall

To make the firewall start at boot simply edit your rc.local file.

vi /etc/rc.local

Add this line to the end (but before the "exit 0" line)

/usr/sbin/firewall

You should reboot your router/server now and redo the ping tests as shown above.

Now that the router has been rebooted and assuming the ping tests have worked OK, you should be able to use your LAN client with the static IP address and ping/browse to the Internet.

That's great, but we don't want to be configuring all our clients with static addresses, so we probably should configure our router as a DHCP server as well.

And while we are at it, why don't you take the next step and turn your router into a funky caching DNS server too.

Or even better, connect your sites together with encrypted VPN's using this super easy Five Minute VPN Guide

[1] AKA "modem" or "modem only" mode.

-