Lintrack: Linux for Internet Service Providers

[ Thursday, 2 November 2006, pjf ]


Lintrack is a new GNU/Linux distribution for routers, firewalls, network access servers and more. It features new approaches to several areas such as system configuration and integration, but has many ideas inspired by traditional Linux distributions as well. I would like to introduce you to the project and provide step-by-step instructions for configuring Lintrack as a simple OSPF backbone router and a PPPoE network access server.

Author: Paweł Foremski

About Lintrack

Lintrack started in the year 2004 and is actively being developed by a team of 3 persons. The project’s original motivation was to provide a free, open source operating system that (Wireless) Internet Service Providers could use to quickly build their network infrastructures. Nowadays there is an even stronger need for a free alternative to similar, but propertiary, operating systems, which are gaining high market share.

What makes Lintrack so special as a Linux distribution is that despite being just another distro, it aims to bring a new, higher level of integration and automation to the open source world. This means that the traditional GNU/Linux distribution elements are joined together with a single, system-wide configuration system that presents a consistent administration interface.

Installation

figure 1
Fig. 1 Lintrack installer

First, we need to obtain the Lintrack 2.0 installation CD – you can download this from the project’s website. After booting your target machine from the CD, you are presented with a screen similar to the one depicted in figure 1 showing the Lintrack installer welcome message.

Most users don’t need to enter any kernel parameters, so simply press Enter and allow the installer to finish booting. After booting, run 'setup' to start the plain, pure-text setup program. This program will ask you a small number of questions in order to install Lintrack onto your hard disk.

The first question requests the location of the target partition. Pressing Enter here will tell the installer to create a default partition on the first available hard disk. A swap partition is not required. After exiting cfdisk, enter the path to the new partition and answer ‘YES’ when asked whether it should be formatted. After the drive is formatted, packages are installed, which should take approximately 5 minutes.

The setup program next asks if you wish to install the GRUB bootloader. This program is installed on the MBR to facilitate the booting of the Linux kernel. If you plan to use GRUB, press Enter.

Congratulations, you have finished installing Lintrack. Remove the installation CD and run 'reboot'.

First steps

figure 2
Fig. 2 Lintrack login prompt

When Lintrack boots for the first time, you will be presented with the login prompt shown in figure 2. To log into the system, use the default username of root and password of asn.

Note: For security reasons, you should immediately change the default password. Run 'passwd' and do it now.

Lintrack uses Flatconf for software configuration. Flatconf presents configuration files as directories and single options as files. In this document we will use a Flatconf interface called fcc:

root@venus:~# fcc
Welcome to Flatconf CLI. Type "?" for help.
venus.lan fc>

Let’s start with few basic fcc commands:

  • ls – lists current directory
  • cd – changes to another directories
  • set – sets new value of an entry (variable)

So, to change the host name (fc:/sys/hostname in Flatconf), follow the steps below:

venus.lan sys> cd sys
venus.lan sys> ls

 [dir] disks      Disks
 [dir] ssl        Certificates (OpenSSL)
 [dir] time       Date and time
 [txt] hostname   Host name
       `venus.lan'
 [txt] hostip     Preferred host IP address
       `'
 [txt] sysloc     System location
       `'
 [txt] sysmail    System administrator e-mail address
       `'
 [dir] modules    Kernel modules
 [fil] rc_local   Local startup script (rc.local)

venus.lan sys> set hostname "router1.lan"

Notice the quotes around the new value. Because we’re using a single word, the quotes are not strictly necessary, but using them is recommended. You will not see the change in your hostname until after you reboot the system. Don’t reboot now, let’s tune a few more options first. Next we will set the preferred IP address, description of the physical machine location, and your e-mail address. You may safely skip the last two, but the first option is very important.

venus.lan sys> set hostip 192.168.1.1
venus.lan sys> set sysloc "PL, Warsaw, ul. Jakas 13"
venus.lan sys> set sysmail "admin@theisp.com"
venus.lan sys> ls

 [dir] disks      Disks
 [dir] ssl        Certificates (OpenSSL)
 [dir] time       Date and time
 [txt] hostname   Host name
       `router1.lan'
 [txt] hostip     Preferred host IP address
       `192.168.1.1'
 [txt] sysloc     System location
       `PL, Warsaw, ul. Jakas 13'
 [txt] sysmail    System administrator e-mail address
       `admin@theisp.com'
 [dir] modules    Kernel modules
 [fil] rc_local   Local startup script (rc.local)

To set the date and time, enter cd time. You’ll notice two new entry types here, bool ([0/1]) and select ([sel]). The bool type accepts only true and false values; the select accepts only a limited range of values. To show all of the possible settings, enter info timezone. This will output a large number of possible time zone settings, so it’s time to introduce autocompletion. Type 'set timezone Europe/' (or America, Asia, etc.) and press the Tab key twice to see the possible options. Type the beginning of the option you want (e.g. ‘War’ for Warsaw) and press Tab once again. This is known as black magic.

venus.lan sys> cd time
venus.lan time> set timezone Europe/(Tab, Tab)
Europe/Amsterdam    Europe/Kiev         Europe/San_Marino
Europe/Andorra      Europe/Lisbon       Europe/Sarajevo
...
Europe/Istanbul     Europe/Rome         Europe/Zaporozhye
Europe/Kaliningrad  Europe/Samara       Europe/Zurich
venus.lan time> set timezone Europe/War(Tab)
venus.lan time> set timezone Europe/Warsaw

To gain more familiarity with the cd command, let’s switch to the fc:/sys/ssl directory. Currently we are in the /sys/time directory. In a typical shell, we would type 'cd ../ssl', but in fcc, we use space characters instead of slashes (except for the first one).

venus.lan time> cd .. ssl
venus.lan ssl> ls

 [fil] ca_crt     CA certificate [info]
                  In .pem format
 [fil] host_crt   Host Certificate (in .pem format) [info]
                  In .pem format
 [fil] host_key   Host Private Key [info]
                  In .pem format
 [fil] dh1024     Diffie Hellman parameters [info]
                  1024 bits
 [act] genreq     Generate new certificate request

We are now in the global SSL configuration directory. These settings are used for EAP-TLS authentication in WPA, OpenVPN, IPsec IKE, and many others, so it is highly recommended that you set it properly. You will need to provide your Certificate Authority certificate and replace the self-signed host certificate with a new one signed by your CA. However, we have not configured networking yet, so I will just explain the procedure for now. You can come back here later, while being connected with SSH, so you can easily copy&paste the required files. Note that you will need SSL configured properly if you wish to have multiple Lintrack powered routers talk to each other securely. If you are only setting up a single Lintrack test box, you may safely skip this step and use the self-signed certificate.

Let’s start with generating a new certificate request. Notice the genreq entry titled “Generate new certificate request”, this is known as an action. This entry type is a directory which, despite being a normal Flatconf directory which you can configure like any other, also has an action script associated with it. This script can be executed with the act command. It’s quite simple:

venus.lan ssl> cd genreq
venus.lan genreq> set cn router1.lan
venus.lan genreq> set overwrite true
venus.lan genreq> act

-----BEGIN CERTIFICATE REQUEST-----
...

The certificate request is written to fc:/sys/ssl/host_crt and the private key to fc:/sys/ssl/host_key. You should sign the request with your CA and provide the result in ../host_crt. To do this, switch to the parent directory and enter 'set host_crt'. This will start vim, a text editor (this can be changed using the $EDITOR environmental variable). Replace any old contents with the signed certificate and save the file. Remember to update the ca_crt option in the same way.

Configuring networking – the big picture

So far so good, we’ve completed the basic configuration. In a moment, we will start the most important part, but first, how exactly is this Lintrack thing going to fit into your network? Well, this mostly depends on you. This how-to is intentionally open-ended and you don’t need to use all the functionality described here. For example, figure 3 shows one of the possible network topologies:

figure 3
Fig. 3 Example network topology

In the above figure, I assume you have already configured the Internet gateway machine and a RADIUS server for providing AAA services to your network infrastructure. Both of these services are quite common in an existing WISP. If you do not have a RADIUS server, I highly recommend using FreeRADIUS and ARA. Or, you can use WPA in PSK mode and local PPPoE authentication without a RADIUS server.

Ethernet devices

Let’s start by configuring the ethernet card that connects the Lintrack box #1 to the Gateway host. In Lintrack this is done in the fc:/net/if/eth directory. Use the cd command to get there. List the directory contents and then execute the scan action to show the ethernet devices that were found during system startup ('act scan').

In the directory listing you’ll notice a new element type, list ([lst]), which needs a bit of explanation as it’s very important. A list consist of other entries (called list elements or just elements) stored in a given order. Below are some of the possible operations that can be performed on lists and elements:

  • add +list element – adds an element to the +list
  • del element – deletes the element, regardless of the list it belongs to
  • up|down element – moves an element up or down in a list
  • disable|enable element – enables or disables an element
  • rename old new – changes an element’s name

Going back to our task, we would like to add our networking interface (eth0) to the +if list:

venus.lan ssl> cd / net if eth
venus.lan eth> act scan

Bus 00, device 03, MAC: 52:54:00:12:34:27 (currently eth0)

venus.lan eth> add +if eth0
venus.lan eth> ls

 [act] scan       Show existing ethernet devices
 [lst] +if
   [dir] eth0

Note the additional indenting in the ls output. This tells us that eth0 is an element of the +if list. A few remarks about elements. Element order, in most cases, matters and the name of a new element should be simple, e.g. no spaces, alphanumeric and optionally containing one of ‘-’, ‘_’, ‘#’, ‘:’ and single ‘.’ The name can be changed later if necessary, but it has to be unique within the current directory. Oh, and if you wish to see disabled elements in the output of the ls command, use 'ls -a'.

Now switch to the new directory and see what’s inside. There are several options, but we’re only interested in the “Interface description”. Set this if you wish to see a human-readable description when you list the fc:/net/if/eth directory, or use the ifconfig/ip tools. Let’s switch to the ip directory and configure the IP protocol on the eth0 interface:

venus.lan eth> cd eth0
venus.lan eth0> set descr "To Gateway"
venus.lan eth0> cd ip
venus.lan ip> add +addr main
venus.lan ip> set main addr 192.168.2.2/30

The ethernet card is now set up, so let’s consider some other configuration possibilities. In the case of an access point connected to router #2, there is a one issue we should discuss. If we set an IP address on the interface connected to the AP and we enable IP forwarding on it (we will discuss forwarding later), then users may be able to access the Internet without prior authentication with the PPPoE protocol. Preferably, your access point should be able to redirect all Ethernet frames received from the wireless stations to one specific hardware (MAC) address or pass only the PPPoE traffic. In the latter case, you’re done; otherwise configure your AP to pass all traffic to a specific MAC. This is configured after setting the IP address of the interface.

venus.lan ip> cd .. vlan
venus.lan vlan> add +mac clients0
venus.lan vlan> set clients0 mac 52:54:00:98:76:54

What we’ve done is adding a new MAC address to the ethernet interface and creating a new, virtual one, called clients0. These virtual interfaces are known as MAC VLANs. Note that we have not configured an IP on it. Oh, and if your AP doesn’t have any of the mentioned features, then you have 2 options. Either leave IP forwarding disabled on the interface connected to it (and administer it from the Lintrack box), or use a firewall to restrict IP forwarding (to be mentioned later).

In the latter case, when your clients are connected directly to your ethernet card (router #3), do not set an IP address on the interface. The same situation exists if you have your clients connect to a wireless card working in AP mode.

Atheros wireless devices

Let’s configure our wireless card. Switch to the fc:/net/if/ath directory and list it. Correct the countrycode option (remember the info command) and execute the scan action to show detected Atheros cards. As before, add your interface (probably wifi0) to the +if list and switch into the new directory.

You likely want to change the descr, channel and dist options, and enable some of the Atheros Super A/G features. But first, let’s get some information about your card’s capabilities:

venus.lan wifi0> cd list
venus.lan list> set caps true freq true
venus.lan list> act

athtmp2915=7782e40f...

Now that we have the radio configured, we can create a real network interface on top of it, a VAP (Virtual Access Point). Again, we need to add a new element to the +if list. This time, let’s call it ath0. After you have configured this, change to the new directory.

Change the mode option to either sta or ap and set the essid. To secure communication, switch to the wpa subdirectory and list it. If your VAP operates as an AP, set the mode to server, otherwise set it to client. Then, set a complicated, long passphrase in pskpass to finish the configuration of WPA2-PSK.

If you are not satisfied with PSK mode, set proto to either eap-tls, eap-peap or eap-ttls. By default, you will need to add your users and their passwords to the fc:/auth/wpa/phase2/+user list (except EAP-TLS), but you can also set the auth option to radius and authenticate them against your RADIUS server (configuration of which is going to be discussed later). Configuration of EAP in client mode is similar, but please note the login, pass and anonlogin options (in some EAP modes).

PPPoE server

The Lintrack project boasts superior PPPoE with RADIUS support. Let’s verify whether this is really the case. We need to enable the PPPoE server first:

venus.lan wpa> cd / net if pppoe server
venus.lan server> set boot true
venus.lan server> add +if eth0
venus.lan server> set authmethod chap
venus.lan server> set authsource radius
venus.lan server> set ipsrc radius

We have enabled the PPPoE server to start upon system boot, added eth0 to the list of network interfaces the service will be available on, enabled a requirement that passwords are sent encrypted using the CHAP protocol, and informed the server to use RADIUS. Remember to correct the DNS settings if you don’t want yout clients to use local DNS cache.

So let’s add our RADIUS server:

venus.lan server> cd / auth radius
venus.lan radius> add +server foobar
venus.lan radius> cd foobar
venus.lan foobar> set ip 192.168.2.6
venus.lan foobar> set pass "supersecret123"

Finally, you should add the ASN RADIUS dictionary to your RADIUS server if you wish to use some extra functionality. Note the ASN-Kbps-* and ASN-Pps attributes which can be used to control the maximal bandwidth (in kilobits/s) and packets per second speeds.

Static routing and DNS

In our scenario, the only router you need to enable static routing on is router number 1. This makes the router aware that it should contact the Internet via the Gateway machine. Run 'set / net route quickgw 192.168.2.1' to enable this.

To add your DNS servers and local domain(s) (if you wish), do the following:

venus.lan radius> cd / net dns
venus.lan dns> add +servers 192.168.2.1
venus.lan dns> add +search lan

Firewall

The firewall in Lintrack uses zones. Let’s consider the zones that we may need:

  • inet – the Internet; in our case – the Gateway host
  • backbone – other Lintrack routers and network management traffic
  • clients – authenticated clients
  • public – publicly or easily accessible infrastructure, a transport medium for previous zone

Each zone needs matches, ie. the information how to connect the actual IP traffic with a firewall zone. It is possible to match IP prefixes, whole network interfaces or simply use an iptables command line snippet. Note that the matches are connected with the OR operator.

Let’s see, in practice, how to configure the inet zone in case we’re on router #1:

venus.lan dns> cd / net fw
venus.lan fw> add +zone inet
venus.lan fw> cd inet
venus.lan inet> set descr "To Gateway"
venus.lan inet> add +matches match1
venus.lan inet> set match1 if eth0
venus.lan inet> cd srv
venus.lan srv> set forwarding on
venus.lan srv> cd .. actions
venus.lan actions> set clampmss true

The above assumes that you are connected to the Gateway machine with eth0 and that it does masquerading, additional firewalling, etc. If you are directly connected to the Internet and you only have a small LAN, you should set forwarding to ‘to‘ (allows new connections only to the zone), disable some services in srv and enable the masq option in the action directory.

The clampmss option causes the TCP/IP MSS parameter to be corrected according to the path MTU.

Now the backbone zone. Start with the same procedure, but this time remember to add other matches – e.g. on proper IP prefixes. While in the srv directory, enable forwarding, iperf, ospf and snmp. You don’t need to set anything in actions.

venus.lan fw> add +zone backbone
venus.lan fw> cd backbone
venus.lan backbone> set descr "Network backbone"
venus.lan backbone> add +matches lintracks
venus.lan backbone> set lintracks ip 192.168.1.0/24
venus.lan backbone> add +matches management
venus.lan backbone> set management ip 192.168.2.0/24
venus.lan backbone> cd srv
venus.lan srv> set forwarding on ospf true iperf true snmp true

There’s one trick you should be aware of while configuring the clients zone. To match any PPP interface (ppp0, ppp1, …), set the if option to ‘pppX‘. In srv, set forwarding to ‘public‘ (if you want your clients to be able to access only public IP addresses through your network; otherwise use ‘on‘ setting) and enable dns. In actions, again enable clampmss.

venus.lan fw> add +zone clients
venus.lan fw> cd clients
venus.lan clients> set descr "PPPoE clients"
venus.lan clients> add +matches pppx
venus.lan clients> set pppx if pppX
venus.lan clients> cd srv
venus.lan srv> set forwarding public dns true
venus.lan srv> cd .. actions
venus.lan actions> set clampmss true

For the public zone, I would recommend setting forwarding to ‘off‘ (or at least to ‘to‘) and disabling all services except ICMP and SSH. If you want this zone to be the default one, then after adding a new element to the +matches list, do not set anything in it. Please also remember that in such cases, the public zone has to be the last one on the fc:/net/fw/+zone list.

venus.lan fw> add +zone public
venus.lan fw> cd public
venus.lan public> set descr "Default rules"
venus.lan public> add +matches all
venus.lan public> cd srv
venus.lan srv> set gre false ipip false ipsec false openvpn false
venus.lan srv> cd .. ..
venus.lan fw> ls

 [0/1] boot       Start firewall at boot
       `true'
 [lst] +zone      Zones
   [dir] inet       To Gateway
   [dir] backbone   Network backbone
   [dir] clients    PPPoE clients
   [dir] public     Default rules
 [lst] +dnat      DNAT

OSPF

Let’s enable simple OSPF:

venus.lan fw> cd / srv quagga
venus.lan quagga> set boot true
venus.lan quagga> cd ospf
venus.lan ospf> set boot true
venus.lan ospf> set area0 192.168.2.0/24
venus.lan ospf> add +if ath0
venus.lan ospf> set ath0 md5key "supersecretkey"
venus.lan ospf> set authtype md5
venus.lan ospf> set defaultgw true

For all routers except #1, skip the last command (it causes the router to announce itself as an Internet gateway to other OSPF routers), Remember to correct the IP prefix of your network backbone (area0) and to set a good MD5 key.

Other services

It’s usually a good idea to have a DNS cache close to your clients, so let’s enable it:

venus.lan ospf> set / srv dnsmasq boot true

And finally, if you wish, you may enable the SNMP agent. For example, enable SNMP v2c as shown below:

venus.lan ospf> cd / srv snmpd
venus.lan snmpd> set boot true
venus.lan snmpd> add +community public
venus.lan snmpd> set public source 192.168.2.0/24

Conclusion

You may now exit fcc with the quit command (or by pressing Ctrl+D) and reboot your machine. If you have any problems, refer to the Lintrack wiki and forum. Have fun!


The author would like to thank Jason ‘Xenophage’ Frisvold (blog) for proofreading and improving readability of this article.

About the Author

Paweł Foremski

One of the creators of Lintrack, a GNU/Linux distribution for ISP providers.

New AdTaily ads!

Are you a film buff?

film buffs community, movie recommendations and reviews

RSS: Comments

You can follow the comments to this article through a special channel RSS 2.0 .

Related articles: HOWTOs

 more »

Related articles: Reviews

 more »

PolishLinux Top Content


Become our fan on Facebook!

PolishLinux.org on Facebook

Follow PolishLinux on Twitter!

Follow polishlinux on Twitter

Google Ads