Louwrentius - Networking

Raspberry Pi as a router using a single network interface

2021-09-29T12:00:00+02:00

Introduction

Disclaimer: this article is intended for consumers and hobbyists.

If you want to run your own router at home, the Raspberry Pi 4 Model B¹ can be an excelent hardware choice:

it's fairly cheap
it's fast enough
it can saturate it's gigabit network port
it is power-efficient

The key problem it seems, is that it has only one, single network interface. If you build a router, you need at least two:

The first interface connected to your internet modem/router (ideally in bridge mode)
The second interface connected to your home network (probably a switch)

So if you would use the Raspberry Pi, you would probably buy a gigabit USB3 NIC for around $20 and be done with it.

click on the image for a larger version

Now, what if I told you that you can build exactly the same setup by using only the single on-board network interface of the Raspberry Pi 4?

How is that possible?

Introducing VLANs

Yes, I'm introducing the reader to a technology that exists since the '90s. It is widely used within businesses and other organisations.

Because I have a sense that this technology is less well-known in circles outside IT operations, I think it may be an interesting topic to discuss.

Understanding VLANs

VLAN technology allows you to run different, separate networks over the same, single physical wire and on the same, single switch. This saves a lot on network cabling and the number of physical switches required if you want to operate networks that are separate from each other.

If you want to run traffic from different networks over the same physical wire or switch, how can you identify those different traffic flows?

With VLAN technology enabled, such network 'packets' are labeled with a tag. As the VLAN technology operates at the level of Ethernet, we should not talk about 'packets' but about 'ethernet frames'. The terminology is not important to understand the concept, I think.

It suffices to understand that there is a tag put in front of the ethernet frame, that tells any device that supports VLANs to which network a frame and thus a packet belongs.

This way, network traffic flows, can be distinguished from each other. And those tags are nothing fancy, they are called a VLAN ID and it is just a number between 1 and 4096².

Managed switch

Now that we understand the concept of VLANs, how do we use it?

First of all, you need a managed network switch that supports VLANs.

The cheapest switch with VLAN support I could find is the TP-LINK TL-SG105E, for around 25 euros or dollars. This is a 5-port switch, but the 8-port version is often only a few euros/dolars more.

Juan Pedro Paredes in the comments point out that this TP-LINK switch may not be able to handle the large number of ARP requests that may arrive at the port connected to the Internet Modem. Others are quite negative about this switch in the Hacker News discussion (linked below). I'm not sure if Netgear switches, which are near the same price, fare any better.

A switch like this has a web-based management interface that allows you to configure VLANS on the device.

Tagged vs untagged

In the context of VLANS, a network switch port can be in two states:

Member of a particular network (VLAN) (untagged)
Transporting multiple networks (VLANs) (tagged)

If a port is just a member of a VLAN, it just behaves like any other switch port. In this mode, it can obviously only be a member of one network/VLAN. The VLAN tags are stripped off all network traffic coming out of this port.

However, a port that is assigned 'tagged' VLAN trafic, just forwarded traffic as-is, including their VLAN tag.

This is the trick that we use to send network packets from different networks (VLANS) to our Raspberry Pi router over a single port/wire.

click on the image for a larger version

So let's unpack this picture together, step by step.

Let's imagine a (return) packet from the Internet arrives at the modem and is sent into switchport 1.

The switch knows that any traffic on that switch port belongs to VLAN 10. Since this traffic needs to be send towards the Pi Router, it will put a tag on the packet and forwards the packet, including the tag towards the Pi on switch port 2.

The Pi - in turn - is configured to work with VLANs just as the switch. The tag on the packet tells the Pi to wich virtual interface the packet must be send.

A netplan configuration example to illustrate this setup:

network:
  version: 2
  ethernets:
    enp2s0f0:
      dhcp4: no
  vlans:
    enp2s0f0.10:
       id: 10
       link: enp2s0f0
       addresses:
         - 68.69.70.71/24 (fake internet address)
       gateway4: 68.69.70.1 (fake upstream ISP router)
    enp2s0f0.20:
       id: 20
       link: enp2s0f0
       addresses:
         - 192.168.0.1/24 (internal network address, acting as gateway)

As you can see, the VLAN packets that arrive as tagged packets, are send (without their tags) to a virtual network interface belonging to that particular network. Those virtual network interfaces all share the same physical interface (enp2s0f0). The virtual network interfaces are just the physical interface name with ".(VLAN ID)" added.

From here on out, you probably understand where this is going: those two virtual network interfaces are basically similar to a setup with two physical network interfaces. So all the routing and NAT that needs to happen, just happens on those two virtual interfaces instead.

How to work with VLANs

To work with VLANs, you need a managed switch that supports VLANs. A managed switch has a management interface, often a web-based management interface.

In this example, I'm using the TP-LINK TL-SG105E switch as an example. To get to this page, go to VLAN --> 802.1Q VLAN in the web interface.

So from this table we can derive that:

Port 1 is an untagged member of VLAN 10
Port 2 is a tagged member of VLAN 10 and VLAN 20
Port 3 is an untagged member of VLAN 20

Please note that it is also recommended to remove ports from VLANs they don't use. So I removed ports 1, 2 and 3 from the default VLAN 1.

Now, if you have more devices to connect to the internal LAN on this switch, you need to configure the ports to be an untagged member of VLAN 20.

Caveats

Bandwidth impact

Obviously, if you use a single interface, you only get to use the bandwidth of that sinle interface. In most cases, this is not an issue, as gigabit ethernet is full-duplex: there is physical exclusive wiring for upstream traffic and downstream traffic.

So you might say that full-duplex gigabit ethernet has a raw throughput capacity of two gigabit/s, although we mostly don't talk about it that way.

So when you download at 200 Mbit/s, that traffic is ingested over VLAN 10 over the incomming traffic path. It is then sent out over VLAN 20 towards your computer over VLAN 20 using the outgoing path. No problem there.

If you would also use the Raspberry Pi as a backup server (with an attached external hard drive), the backup traffic and the internet traffic could both 'fight' for bandwidth on the same gigabit link.

Impact on gigabit internet

Update June 2022 I was actually able to use full Gigabit internet speed over VLANs, at around 111 MB/s. I made some mistakes during earlier testing.

You will never get the full gigabit internet network speed if you would build this setup. It will probably max out at ~900 Mbit. (I'm assuming here that you would use x86 hardware as the Pi would not be able to handle firewalling this traffic anyway.)

This is because most traffic is based on TCP connections and when you download, there is traffic both ways!. The download traffic is the bulk of the traffic, but there is a substantial steady stream of return packets that acknowledges to the sender that traffic has been received (if not, it would trigger a retransmission).

Remember that in this single-port setup, the Pi uses the same gigabit port to send the return traffic to the internet over VLAN 10 and the download data towards your home computer over VLAN 20. So the size of the upstream traffic will limit your maximum download performance.

The Raspberry Pi 4 Model B as a router

The biggest limitation - which becomes an issue for more and more people - is performance. If you use IPTABLES on Linux for firewalling, in my experience, network throughput drops to a maximum of 650 Mbit/s.

That's only an issue (first world problems) if you have gigabit internet or an internet speed beyond what the Pi can handle.

If your internet speed doesn't even come close, this is not an issue at all.

Maybe the Raspberry Pi 400 or the compute module performs better in this regard as their CPUs are clocked at higher Ghz.

Closing words

If it makes any sense for you to implement this setup, is only for you to decide. I'm running this kind of setup (using an x86 server) for 10 years as I can't run a second cable from my modem to the room where my router lives. For a more detailed picture of my home network setup, take a look here.

Feel free to leave any questions of comments below.

The hacker news discussion about this article can be found here.

Route-on-a-stick

I learned from the hacker news discussion that a router with just one network interface is called a router on a stick.

Older models of the Raspberry Pi are significantly network bandwidth constrained. So much so, that they would not be suitable as Internet routers if your internet speed is above 100Mbit. ↩
most cheap switches can't operate more than 32 ~ 64 VLANs maximum. Only more expensive, enterprise gear can work with the full 4096 VLANS at the same time. However, this is probably not relevant for consumers. ↩

My home network setup based on managed switches and VLANs

2020-04-10T12:00:00+02:00

My home networking setup

I live in a two story apartment, with on the top floor my utilities closet and my living room. The bottom floor contains a bedroom with all my servers and networking gear.

So this is my setup (click for a bigger version):

I like to run my own router but my utilities closed is not the safest place in terms of security and climate.

By default, most people who run their own home router will use a box with two network interfaces, one connected to the (cable) modem and the other one connected to the home network.

I could have done the same thing, by running a cable from the modem to my router, and a second cable back up towards my closet (and livingroom).

However, I didn't want to run multiple cables from my utilities closed to my bedroom downstairs, I saw no need for that: because I can use VLANs.

The small 8-port switch in the closed is connected with a single (long) cable to the 24-port switch I have in my bedroom downstairs. This switch connects to my router and multiple servers.

I've setup a trunk between these two switches where my internet traffic flows over 'VLAN 100' and my home network uses 'VLAN 200'.

The router, an HP N40L, has only a single network interface. I just expose the two VLANS as 'tagged' and let the router route traffic between the two VLANS. No need for a second interface (as many home setups do).

So in my setup there are two trunks, one between the two switches and the other one between the bedroom switch and my router. All other devices are connected to untagged network ports, in their appropriate VLAN.

The small switch in the closet is responsible for carrying my home network to the switch in my living room.

The raspberry pi connects to my smart meter to collect information about my power and gas usage.

Setup a VPN on your iPhone with OpenVPN and Linux

2018-06-18T04:00:00+02:00

⚠️ 🚨 Update 2024 🚨⚠️

I'm not using OpenVPN anymore for my VPN needs and this article is considered unmaintained. It's stronly recommended not to use this tutorial and find up-to-date documentation. I also have no plans to update this blogpost in the future.

[Update 2018]

This article has been substantially updated since it was published in 2013.

Introduction

In this article, I will show you how to setup a Linux-based OpenVPN server. Once this server is up and running, I'll show you how to setup your iOS devices, such as your iPhone or iPad so that they can connect with your new VPN server.

The goal of this effort is to encapsulate all internet traffic through your VPN connection so no matter where you are, nobody can monitor which sites you visit and what you do. This is ideal if you have to visit the internet through untrusted internet sources like public Wi-Fi.

Some typical scenarios would be:

you run an OpenVPN service on your Linux-based home router directly
you run an OpenVPN service on a device behind your home router using portforwarding (like a Raspberry Pi)
you run an OpenVPN service on a VPS hosted by one of many cloud service providers

Your iOS devices will be running OpenVPN Connect, a free application found in the App store.

A note on other platforms: Although this tutorial is focussed on iOS devices, your new OpenVPN-based VPN server will support any client OS, may it be Windows, MacOS, Android or Linux. Configuration of these other clients is out-of-scope for this article.

This tutorial is based on OpenVPN, an open-source product. The company behind OpenVPN also offers VPN services for a price per month. If you find the effort of setting up your own server too much of a hassle, you could look into their service. Please note that I have never used this service and cannot vouch for it.

This is a brief overview of all the steps you will need to take in order to have a fully functional setup, including configuration of the clients:

Install a Linux server (out-of-scope)
Install the OpenVPN software
Setup the Certificate Authority
Generate the server certificate
Configure the OpenVPN server configuration
Configure the firewall on your Linux server
Generate certificates for every client (iPhone, iPad, and so on)
Copy the client configuration to your devices
Test your clients

How It Works

OpenVPN is an SSL-based VPN solution. SSL-based VPNs are very reliable because if you set it up properly, you will never be blocked by any firewall as long as TCP-port 443 is accessible. By default, OpenVPN uses UDP as a transport at port 1194, but you can switch to TCP-port 443 to increase the chance that your traffic will not be blocked at the cost of a little bit more bandwidth usage.

Authentication

Authentication is based on public/private key cryptography. The OpenVPN server is similar to an HTTPS server. The biggest difference is that your device doesn't use a username/password combination for authentication, but a certificate. This certificate is stored within the client configuration file.

So before you can configure and start your OpenVPN service, you need to setup a Certificate Authority (CA). With the CA you can create the server certificate for your OpenVPN server and after that's done, generate all client certificates.

OpenVPN installation

OpenVPN is available on most common Linux Distros by default. apt-get install openvpn for any Debian or Ubuntu version is all you need to install OpenVPN.

Or take a look here

I have never tried it out, but you can try and take a look at an OpenVPN install script

This script seems to automate a lot of steps, like firewall configuration, certificate generation, etc.

Tip

It's out-of-scope for this tutorial, but you should make sure that you keep your OpenVPN software up-to-date, in case security vulnerabilities are discovered in OpenVPN in the future.

Security

I'm creating this tutorial on an older system, with less secure default configuration settings for both the Certificate Authority as the OpenVPN server itself. The settings I use in this tutorial are based on the steps in this blog.

Notable improvements:

AES256 for encryption
2048 bit key sizes over 1024 bit keys
SHA256 over sha1/md5

Performance

I did some performance tests and got around 40-50 Mbs per iOS client. I believe that the bottleneck lies with my old HP Microserver N40L with its relatively weak CPU.

Traffic Shaping

If you want to limit how much bandwidth a client is allowed to use, I recommend to use this tutorial. I have tried it out and it works perfectly.

Creating a certificate authority.

For unbuntu: install the package "easy-rsa" and use the 'make-cadir' command instead of the setup instructions below.

I assume that you will setup your OpenVPN configuration in /etc/openvpn. Before you can setup the server configuration, you need to create a certificate authority. I used the folder /etc/openvpn/easy-rsa as the location for my CA.

mkdir /etc/openvpn/easy-rsa

We start with copying all these files to this new directory:

cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0* /etc/openvpn/easy-rsa

Please note that depending on your Linux flavour, these files may be found at some other path.

Next, we cd into the destination directory.

cd /etc/openvpn/easy-rsa

Now, open the 'vars' file with your favorite text editor. The following instructions are straight from the OpenVPN howto.

You should change all the values to ones that apply to you (obviously).

export KEY_COUNTRY="US"
export KEY_PROVINCE="California"
export KEY_CITY="San Fransisco"
export KEY_ORG="My Company"
export KEY_EMAIL="my@mail.com"
export KEY_CN=server
export KEY_NAME=server
export KEY_OU=home

Change the KEY_SIZE parameter:

export KEY_SIZE=2048

How long would you like your certificates to be valid (10 years?)

export CA_EXPIRE=3650
export KEY_EXPIRE=3650

Then I had to copy openssl-1.0.0.cnf to openssl.cnf because the 'vars' script complained that it couldn't find the latter file.

cp openssl-1.0.0.cnf openssl.cnf

Notice I went through these steps on an older Linux installation. I had to edit the file /etc/openvpn/easy-rsa/pkitool and changed all occurrences of 'sha1' to 'sha256'.

Now we 'source' var and run two additional commands that actually generate the certificate authority. Notice the dot before ./vars.

. ./vars
./clean-all
./build-ca
./build-dh

You will have to confirm the values or change them if necessary.

Now we have a certificate authority and we can create new certificates that will be signed by this authority.

WARNING: be extremely careful with all key files, they should be kept private.

I would recommend performing these commands:

chown -R root:root /etc/openvpn 
chmod -R 700 /etc/openvpn

By default, OpenVPN runs as root. With these commands, only the root user will be able to access the keys. If you don't run OpenVPN as root, you must select the appropriate user for the first command. See also this article.

Creating the Server Certificate

We create the server certificate:

./build-key-server server

It's up to you to come up with an alternative for 'server'. This is the file name under which the key files and certificates are stored.

All files that are generated can be found in the '/etc/openvpn/easy-rsa/keys' directory. This is just a flat folder with both the server and client keys.

Creating the optional TLS-AUTH Certificate

This step is optional but it doesn't take much effort and it seems to add an additional security layer at no significant cost. In this step we create an additional secret key that is shared with both the server and the clients.

The following steps are based on this article (use of -tls-auth).

cd /etc/openvpn/easy-rsa/keys
openvpn --genkey --secret ta.key

When we are going to create the server configuration, we will reference this key file.

Creating the Client Certificate

Now that we have a server certificate, we are going to create a certificate for our iPhone (or any other iOS device).

./build-key iphone

Answer the questions with the defaults. Don't forget to answer these questions:

Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

So now we have everything in place to start creating an OpenVPN configuration. We must create a configuration for the server and the client. Those configurations are based on the examples that can be find in /usr/share/doc/openvpn/examples/.

Example Server configuration

This is my server configuration which is operational. It is stored in /etc/openvpn/openvpn.conf

dev tun2
tls-server
cipher AES-256-CBC
auth SHA256
remote-cert-tls client
dh easy-rsa/keys/dh2048pem
ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/server.crt
key easy-rsa/keys/server.key
tls-auth easy-rsa/keys/ta.key
server 10.0.0.0 255.255.255.0
log /var/log/openvpn.log
script-security 2
route-up "/sbin/ifconfig tun2 up"
port 443
proto tcp-server
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"

I believe you should be able to use this configuration as-is. Depending on your local IP-addresses within your own network, you may have to change the server section.

I use TCP-port 443 as this destination port is almost never blocked as blocking this port would break most internet connectivity. (The downside is that I can no longer host any secure web site on this IP-address).

The OpenVPN service will provide your client with an IP-address within the address range configured in the 'server' section.

Change any parameters if required and then start or restart the OpenVPN service:

/etc/init.d/openvpn restart

Make sure that the server is running properly in /var/log/openvpn.log

If you want to use your VPN to browse the internet, we still need to configure a basic firewall setup.

I'm assuming that you already have some kind of IPtables-based firewall running. Configuring a Linux firewall is out-of-scope for this article. I will only discuss the changes you may need to make for the OpenVPN service to operate properly.

You will need to accept traffic to TCP port 443 on the interface connected to the internet.

iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

If your OpenVPN server is behind a router/firewall, you need to configure port-forwarding on that router/firewall. How to do so is out-of-scope for this article, as it is different for different devices.

Assuming that you will - for example - use the 10.0.0.0/24 network for VPN clients such as your iPhone, you must also create a NAT rule so VPN clients can use the IP-address of the Linux server to access Internet.

iptables -t nat -A POSTROUTING -s "10.0.0.0/24" -o "eth0" -j MASQUERADE

Please note that you must change eth0 with the name of the appropriate interface that connects to the internet. Change the IP-address range according to your own situation. It should not conflict with your existing network.

iptables -A FORWARD -p tcp -s 10.0.0.0/24 -d 0.0.0.0/0 -j ACCEPT

Please note that I haven't tested these rules, as I have a different setup. But this should be sufficient. And make sure that forwarding is enabled like this:

echo 1 > /proc/sys/net/ipv4/ip_forward

Example Client configuration

Most OpenVPN clients can automatically import files with the .ovpn file extension. A typical configuration file is something like 'iphone.ovpn'.

Warning: the .ovpn files will contain the certificate used by your iPhone/iPad to authenticate against your OpenVPN server. Be very carefull where you store this file. Anyone that is able to obtain a copy of this file, will be able to connect to your VPN server.

This is an example configuration file, but we are not going to create it by hand, it's too much work.

What you will notice from this example is that the .ovpn file contains both the client configuration and all the required certificates:

the CA root certificate
the server certificate to validate the server
the client private certificate
the TLS-AUTH certificate (an optional extra security measure)

Create a client configuration file (.ovpn) with a script

You can create your client configuration file manually but that is a lot of work. Because you need to append all the certificates to a single file, that also contains the configuration settings.

So we will use a script to setup the client configuration.

First we are going to create a folder where our client configuration files will be stored.

mkdir /etc/openvpn/clientconfig
chmod 700 /etc/openvpn/clientconfig

Now we will download the script and the accompanying configuration template file. Notice that the links may wrap.

cd /etc/openvpn
wget https://raw.githubusercontent.com/louwrentius/openvpntutorial/master/create-client-config.sh
wget https://raw.githubusercontent.com/louwrentius/openvpntutorial/master/client-config-template
chmod +x create-client-config.sh

Please note that you first need to create the certificates for your devices before you can generate a configuration file. So please go back to that step if you need to.

Also take note of the name you have used for your devices. You can always take a look in /etc/openvpn/easy-rsa/keys to see how your devices are called.

Now, edit this client-config-template and change the appropriate values where required. You may probably only need to change the first line:

remote <your server DNS address or IP address>

Now you are ready to run the script and generate the config file for your device.

When you run this script, a configuration file is generated and placed in to the folder /etc/openvpn/clientconfig.

The script just puts the client configuration template and all required certificates in one file. This is how you use it:

./create-client-config.sh iPhone

Some output you will notice when running the script:

user@server:/etc/openvpn# ./create-client-config.sh iphone
Client's cert found: /etc/openvpn/easy-rsa/keys/iphone
Client's Private Key found: /etc/openvpn/easy-rsa/keys/iphone.key
CA public Key found: /etc/openvpn/easy-rsa/keys/ca.crt
tls-auth Private Key found: /etc/openvpn/easy-rsa/keys/ta.key
Done! /etc/openvpn/clientconfig/iphone.ovpn Successfully Created.

You should now find a file called 'iphone.ovpn' in the directory /etc/openvpn/clientconfig.

We are almost there. We just need to copy this file to your iOS device.

You have three options:

Use iCloud Drive
Use iTunes
Use email (obviously insecure and not discussed)

Setting up your iPhone or iPad with iCloud Drive

First install the OpenVPN Connect application if you haven't done so.
Copy the .ovpn file from your OpenVPN server to your iCloud Drive.
Take your device and use the 'files' browser to navigate within your iCloud drive to the .ovpn file you just copied.
Tap on the file to download and open it.
Now comes the tricky part: press the share symbol

Open the file with the OpenVPN application on your iOS device:

When you get the question "OpenVPN would like to Add VPN Configurations", choose 'Allow'.

Continue with the step 'Test your iOS device'.

If the OpenVPN Connect client doesn't import the file, remove the application from the device and re-install it. (This is what I had to do on my iPad).

Setting up your iPhone or iPad with iTunes

You can skip this step if you used iCloud Drive to copy the .ovpn profile to your device.

You need to get the following files on your iOS device:

iphone.ovpn

Copy this file from your OpenVPN server to the computer running iTunes. Then connect your device to iTunes with a cable.

Open iTunes
Select your device at the top right
Go to the Apps tab
Scroll to the file sharing section
Select the OpenVPN application
Add the iphone.ovpn
Sync your device

Test your iOS device

Open the OpenVPN client. You will see a notice that a new configuration has been imported and you need to accept this configuration.

As it might not work straight away, you need to monitor /var/log/openvpn.log on the server to watch for any errors.

Now try to connect and enjoy.

Conclusion

You should be able to keep your VPN enabled at all times because battery usage overhead should be minimal. If you are unable to connect to your VPN when you are at home behind your own firewall, you need to check your firewall settings.

Updated 20130123 with keepalive option. Updated 20130801 with extra server push options for traffic redirection and DNS configuration Updated 20180618 as substantial rewrite of the original outdated article.

Using InfiniBand for cheap and fast point-to-point Networking

2017-03-25T12:00:00+01:00

InfiniBand networking is quite awesome. It's mainly used for two reasons:

low latency
high bandwidth

As a home user, I'm mainly interested in setting up a high bandwidth link between two servers.

I was using quad-port network cards with Linux Bonding, but this solution has some downsides:

you can only go to 4 Gbit with Linux bonding (or you need more ports)
you need a lot of cabling
it is similar in price as InfiniBand

So I've decided to take a gamble on some InfiniBand gear. You only need InfiniBand PCIe network cards and a cable.

1 x SFF-8470 CX4 cable                                              $16
2 x MELLANOX DUAL-PORT INFINIBAND HOST CHANNEL ADAPTER MHGA28-XTC   $25
                                                            Total:  $66

I find $66 quite cheap for 20 Gbit networking. Regular 10Gbit Ethernet networking is often still more expensive that using older InfiniBand cards.

InfiniBand is similar to Ethernet, you can run your own protocol over it (for lower latency) but you can use IP over InfiniBand. The InfiniBand card will just show up as a regular network device (one per port).

ib0 Link encap:UNSPEC HWaddr 80-00-04-04-FE-80-00-00-00-00-00-00-00-00-00-00  
      inet addr:10.0.2.3  Bcast:10.0.2.255  Mask:255.255.255.0
      inet6 addr: fe80::202:c902:29:8e01/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:65520  Metric:1
      RX packets:7988691 errors:0 dropped:0 overruns:0 frame:0
      TX packets:17853128 errors:0 dropped:10 overruns:0 carrier:0
      collisions:0 txqueuelen:256 
      RX bytes:590717840 (563.3 MiB)  TX bytes:1074521257501 (1000.7 GiB)

Configuration

I've followed these instructions to get IP over InfiniBand working.

Modules

First, you need to assure the following modules are loaded at a minimum:

ib_mthca
ib_ipoib

I only had to add the ib_ipoib module to /etc/modules. As soon as this module is loaded, you will notice you have some ibX interfaces available which can be configured like regular ethernet cards

Subnet manager

In addition to loading the modules, you also need a subnet manager. You just need to install it like this:

apt-get install opensm

This service needs to run on just one of the endpoints.

Link status

if you want you can check the link status of your InfiniBand connection like this:

# ibstat
CA 'mthca0'
    CA type: MT25208
    Number of ports: 2
    Firmware version: 5.3.0
    Hardware version: 20
    Node GUID: 0x0002c90200298e00
    System image GUID: 0x0002c90200298e03
    Port 1:
        State: Active
        Physical state: LinkUp
        Rate: 20
        Base lid: 1
        LMC: 0
        SM lid: 2
        Capability mask: 0x02510a68
        Port GUID: 0x0002c90200298e01
        Link layer: InfiniBand
    Port 2:
        State: Down
        Physical state: Polling
        Rate: 10
        Base lid: 0
        LMC: 0
        SM lid: 0
        Capability mask: 0x02510a68
        Port GUID: 0x0002c90200298e02
        Link layer: InfiniBand

Set mode and MTU

Since my systems run Debian Linux, I've configured /etc/network/interfaces like this:

auto ib0
iface ib0 inet static
    address 10.0.2.2
    netmask 255.255.255.0
    mtu 65520
    pre-up echo connected > /sys/class/net/ib0/mode

Please take note of the 'mode' setting. The 'datagram' mode gave abysmal network performance (< Gigabit). The 'connected' mode made everything perform acceptable.

The MTU setting of 65520 improved performance by another 30 percent.

Performance

I've tested the card on two systems based on the Supermicro X9SCM-F motherboard. Using these systems, I was able to achieve file transfer speeds up to 750 MB (Megabytes) per second or about 6.5 Gbit as measured with iperf.

~# iperf -c 10.0.2.2
------------------------------------------------------------
Client connecting to 10.0.2.2, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[  3] local 10.0.2.3 port 40098 connected with 10.0.2.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  7.49 GBytes  6.43 Gbits/sec

Similar test with netcat and dd:

~# dd if=/dev/zero bs=1M count=100000 | nc 10.0.2.2 1234
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 128.882 s, 814 MB/s

Testing was done on Debian Jessie.

During earlier testing, I've also used these cards in HP Micro Proliant G8 servers. On those servers, I was running Ubuntu 16.04 LTS.

As tested on Ubuntu with the HP Microserver:

------------------------------------------------------------
Client connecting to 10.0.4.3, TCP port 5001
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[  5] local 10.0.4.1 port 52572 connected with 10.0.4.3 port 5001
[  4] local 10.0.4.1 port 5001 connected with 10.0.4.3 port 44124
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-60.0 sec  71.9 GBytes  10.3 Gbits/sec
[  4]  0.0-60.0 sec  72.2 GBytes  10.3 Gbits/sec

Using these systems, I was able eventually able to achieve 15 Gbit as measured with iperf, although I have no 'console screenshot' from it.

Closing words

IP over InfiniBand seems to be a nice way to get high-performance networking on the cheap. The main downside is that when using IP over IB, CPU usage will be high.

Another thing I have not researched, but could be of interest is running NFS or other protocols directly over InfiniBand using RDMA, so you would bypass the overhead of IP.

Creating configuration backups of HP procurve switches

2015-01-12T12:00:00+01:00

I've created a tool called procurve-watch. It creates a backup of the running switch configuration through secure shell (using scp).

It also diffs backed up configurations against older versions, in order to keep track of changes. If you run the script from cron every hour or so, you will be notified by email of any (running) configuration changes.

The tool can backup hundreds of switches in seconds as it is running the configuration copy in parallel.

A tool like Rancid may actually be the best choice for this task, but it didn't work. The latest version of Rancid doesn't support HP Procurve switches (yet) and older versions created backups containing garbled characters.

I've released it on github, check it out and let me know if it works for you and you have suggestions to improve it further.

Configuring, attacking and securing VRRP on Linux

2015-01-02T12:00:00+01:00

The VRRP or Virtual Router Redundancy Protocol helps you create a reliable network by using multiple routers in an active/passive configuration. If the primary router fails, the backup router takes over almost seamlessly.

This is how VRRP works:

Clients connect to a virtual IP-address. It is called virtual because the IP-address is not hard-coded to a particular interface on any of the routers.

If a client asks for the MAC-address that is tied to the virtual IP, the master will respond with its MAC-address. If the master dies, the backup router will notice and start responding to ARP-requests.

Let's take a look at the ARP table on the client to illustrate what is happening.

Master is active:

(10.0.1.140) at 0:c:29:a7:7d:f2 on en0 ifscope [ethernet]
(10.0.1.141) at 0:c:29:a7:7d:f2 on en0 ifscope [ethernet]
(10.0.1.142) at 0:c:29:b2:5b:7c on en0 ifscope [ethernet]

Master has failed and backup has taken over:

(10.0.1.140) at 0:c:29:b2:5b:7c on en0 ifscope [ethernet]
(10.0.1.141) at 0:c:29:a7:7d:f2 on en0 ifscope [ethernet]
(10.0.1.142) at 0:c:29:b2:5b:7c on en0 ifscope [ethernet]

Notice how the MAC-address of the virtual IP (.140) is now that of the backup router.

Configuring VRRP on Linux

configure static IP-addresses on the primary and backup router. Do not configure the virtual IP on any of the interfaces. In my test environment, I used 10.0.1.141 for the master and 10.0.1.142 for the backup router.
Because the virtual IP-address is not configured on any of the interfaces, Linux will not reply to any packets destined for this IP. This behaviour needs to be changed or VRRP will not work. Edit /etc/sysctl.conf and add this line:
```
net.ipv4.ip_nonlocal_bind=1
```
Run this command to active this setting:
```
sysctl -p
```
Install Keepalived
```
apt-get install keepalived
```

Sample configuration of /etc/keepalived/keepalived.conf for MASTER

vrrp_instance VI_1 {
    interface eth0
    state MASTER
    virtual_router_id 51
    priority 101

    authentication {
        auth_type AH
        auth_pass monkey
    }

    virtual_ipaddress {
        10.0.1.140
    }
}

Sample configuration of /etc/keepalived/keepalived.conf for SLAVE

vrrp_instance VI_1 {
    interface eth0
    state BACKUP
    virtual_router_id 51
    priority 100

    authentication {
        auth_type AH
        auth_pass monkey
    }

    virtual_ipaddress {
        10.0.1.140
    }
}

Start keepalived:
```
service keepalived start
```

The only configuration difference regarding keepalived between the master and the standby router is the 'priority' setting. The master server should have a higher priority than the backup router (101 vs. 100).

As there can be multiple VRRP configurations active within the same subnet, it is important that you make sure that you set a unique virtual_router_id.

Please do not forget to set your own password in case you enable authentication.

VRRP failover example

This is what happens if the master is shutdown:

64 bytes from 10.0.1.140: icmp_seq=148 ttl=64 time=0.583 ms
64 bytes from 10.0.1.140: icmp_seq=149 ttl=64 time=0.469 ms
64 bytes from 10.0.1.140: icmp_seq=150 ttl=64 time=0.267 ms
Request timeout for icmp_seq 151
Request timeout for icmp_seq 152
Request timeout for icmp_seq 153
Request timeout for icmp_seq 154
64 bytes from 10.0.1.140: icmp_seq=155 ttl=64 time=0.668 ms
64 bytes from 10.0.1.140: icmp_seq=156 ttl=64 time=0.444 ms
64 bytes from 10.0.1.140: icmp_seq=157 ttl=64 time=0.510 ms

After about five seconds (default) the standby router takes over and starts responding to the virtual IP.

Security

A host within the same subnet could just spoof VRRP packets and disrupt service.

An attack on VRRP is not just theoretical. A tool called Loki allows you to take over the virtual IP-address and become the master router. This will allow you to create a DoS or sniff all traffic.

VRRP security is also discussed in this document from the Loki developers.

According to rfc3768 authentication and security has been deliberately omitted (see section 10 Security Considerations) from newer versions of the VRRP protocol RFC.

The main argument is that any malicious device in a layer 2 network can stage similar attacks focussing on ARP-spoofing and ARP-poisoning so as the fundament is already insecure, why care about VRRP?

I understand the reasoning but I disagree. If you do have a secure Layer 2 environment, VRRP becomes the weakest link. Either you really need to filter out VRRP traffic originating from untrusted ports/devices, or implement security on VRRP itself.

Attacking VRRP with Loki

I have actually used Loki on VRRP and I can confirm it works (at least) as a Denial-of-Service tool.

I used Kali (Formerly known as Back-Track) and installed Loki according to these instructions. Please note the bottom of the page.

What I did on Kali Linux:

apt-get install python-dpkt python-dumbnet
wget http://c0decafe.de/svn/codename_loki/packages/kali-1/pylibpcap_0.6.2-1_amd64.deb
wget http://c0decafe.de/svn/codename_loki/packages/kali-1/loki_0.2.7-1_amd64.deb
dpkg -i pylibpcap_0.6.2-1_amd64.deb
dpkg -i loki_0.2.7-1_amd64.deb

Then just run:

loki.py

This is only an issue if you already protected yourself against ARP- and IP-spoofing attacks.

Protecting VRRP against attacks

Keepalived offers two authentication types regarding VRRP:

PASS (plain-text password)
AH (IPSEC-AH (authentication header))

The PASS option is totally useless from a security perspective.

As you can see, the password 'monkey' is visible and easily obtained from the VRRP multicast advertisements. So to me, it does not make sense to use this option. Loki just replayed the packets and could still create a DoS.

So we are left with IPSEC-AH, wich is more promising as it actually does some cryptography using the IPSEC protocol, so there is no clear-text password to be captured. I'm not a crypto expert, so I'm not sure how secure this implementation is. Here is some more info on IPSEC-AH as implemented in Keepalived.

If I configure AH authentication, the Loki tool does not recognise the VRRP trafic anymore and it's no longer possible to use this simple script-kiddie-friendly tool to attack your VRRP setup.

IPSEC-AH actually introduces an IPSEC-AH header between the IP section and the VRRP section of a packet, so it changes the packet format, which probably makes it unrecognisable for Loki.

Running VRRP multicast traffic on different network segments

It has been pointed out to me by XANi_ that it is possible with Keepalived to keep the virtual IP-address and the VRRP multicast traffic in different networks. Clients will therefore not be able to attack the VRRP traffic.

In this case, security on the VRRP traffic is not relevant anymore and you don't really need to worry about authentication, assuming that untrusted devices don't have access to that 'VRRP' VLAN.

Th first step is that both routers should have their physical interface in the same (untagged) VLAN. The trick is then to specify the virtual IP-addresses in the appropriate VLANs like this example:

virtual_ipaddress {

    10.0.1.1/24 dev eth0.100
    10.0.2.1/24 dev eth0.200
}

In this example, virtual IP 10.0.1.1 is tied to VLAN 100 and 10.0.2.1 is tied to VLAN 200.

If the physical router interfaces are present in the untagged VLAN 50 (example), the VRRP multicast traffic will only be observed in this VLAN.

Some background information on working with VLANs and Keepalived.

Firewall configuration

Update August 2018:

I had problems running VRRP on Red Hat / CentOS. Since I use AH authentication, the protocol is not seen as VRRP but (as TCPDUMP shows) "AH". This is why you need to create a service for Firewalld and enable it for the appropriate zone.

Create a file called "VRRP.xml" in /etc/firewalld/services

    <?xml version="1.0" encoding="utf-8"?>
    <service>
        <short>VRRP</short>
        <description>Virtual Router Redundancy Protocol</description>
        <port protocol="ah" port=""/>
    </service>

Enable VRRP (select the appropriate zone for your interface):

    sudo firewall-cmd --zone=public --permanent --add-service=VRRP

Reload the configuration

    sudo firewall-cmd --reload

check that the service is active with:

    sudo firewall-cmd --zone=public --list-services

Closing words

VRRP can provide a very simple solution to setup a high-availability router configuration. Security can be a real issue if untrusted devices reside in the same layer 2 network so implementing security with IPSEC-AH or network segmentation is recommended.

Getting the Sitecom AC600 Wi-Fi adapter running on Linux

2014-11-01T12:00:00+01:00

TL;DR Yes it works with some modifications of the driver source.

A USB Wi-Fi adapter I used with a Raspberry Pi broke as I dropped it on the floor, so I had to replace it. I just went to a local shop and bought the Sitecom AC600 adapter as that's what they had available (with support for 5Ghz networking).

I had some hope that I would just plug it in and it would 'just work™'. But no. Linux. In the end, the device cost me 30 euro's including taxes, but the time spend to get it to work may have made this a very expensive USB Wi-Fi dongle. And it's funny to think about the fact that the Wi-Fi dongle is almost the same price as the Raspberry Pi board itself.

But I did get it working and I'd like to show you how.

It started with a google for 'sitecom ac600 linux' which landed me on this page. This page told me the device uses a MediaTek chipset (MT7610U).

So you need to download the driver from MediaTek. Here is a direct link

So you may do something like this:

cd /usr/src
wget http://s3.amazonaws.com/mtk.cfs/Downloads/linux/mt7610u_wifi_sta_v3002_dpo_20130916.tar.bz2
tar xjf mt7610u_wifi_sta_v3002_dpo_20130916.tar.bz2
cd mt7610u_wifi_sta_v3002_dpo_20130916

Now you would hope that it's just like this:

make
make install

And we're happy right? Linux FTW! Well, NO! We're using Linux so we have to work for stuff that works right out of the box on Windows and Mac OS.

So we first start with editing "include/os/rt_linux.h" and go to line ~279. There we make sure that we edit the struct like this:

    typedef struct _OS_FS_INFO_
 {
    kuid_t              fsuid;
    kgid_t              fsgid;
    mm_segment_t    fs;
 } OS_FS_INFO;

Basically, the words int are replaced by kuid_t and kgid_t, or else, compilation will abort with an error.

Ofcourse, the Sitecom AC600 has an USB identifier that is unknown to the driver, so after compilation, it still doesn't work.

lsusb output:

Bus 001 Device 004: ID 0df6:0075 Sitecom Europe B.V.

So google landed me on this nice thread by 'praseodym' that explained the remaining steps. I stole the info below from this thread.

So while we are in the source directory of the module, we are going to edit "common/rtusb_dev_id.c" and add

{USB_DEVICE(0x0DF6,0x0075)}, /* MT7610U */

So this will make the AC600 gets recognised by the driver. Now we also need to edit "os/linux/confik.mk" and change these lines like this:

HAS_WPA_SUPPLICANT=y
HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y

So no, we are still not ready yet. I'm not 100 percent sure that this is required anymore, but I found this nice thread in Italian and a very small comment by 'shoe rat' tucked away at the end that may make the difference between a working device or not.

We need to edit the file "os/linux/config.mk" and go to line ~663. Then, around that line, change

CHIPSET_DAT = 2860

to:

CHIPSET_DAT = 2870

Yes. Finally! Now you can do:

make
make install

Imagine that such a 'make' takes about 20 minutes on a Raspbery Pi. No joke.

Now you can either do this:

modprobe mt7650u_sta

You should see something like this:

root@raspberrypi:/usr/src# lsmod
Module                  Size  Used by
snd_bcm2835            16181  0 
snd_pcm                63684  1 snd_bcm2835
snd_page_alloc          3604  1 snd_pcm
snd_seq                43926  0 
snd_seq_device          4981  1 snd_seq
snd_timer              15936  2 snd_pcm,snd_seq
snd                    44915  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
soundcore               4827  1 snd
mt7650u_sta           895786  1 
pl2303                  7951  0 
usbserial              19536  1 pl2303

You should be able to see a 'ra0' device when entering ifconfig -a or iwconfig and just configure it like any wireless device (out-of-scope).

So once up-and-running, the Sitecom AC600 works fine under Linux and even sees and connects to 5 GHz networks. But not without a caveat of-course. I needed to configure a 5 GHz channel below 100 (I chose 48) on my Apple Airport Extreme, or the Wi-Fi dongle would not see the 5GHz network and would not be able to connect to it.

So I hope somebody else is helped by this information.

How traffic shaping can dramatically improve internet responsiveness

2014-03-08T12:00:00+01:00

At work, access to the internet is provided by a 10 Mbit down / 1 Mbit up ADSL-connection. As we are a mid-size company, bandwidth is clearly a severe constraint. But it was not our biggest problem. Even simple web-browsing was very slow.

As I was setting up a monitoring environment based on Nagios and pnp4nagios, I started to graph the latency of our internet connection, just to prove that we have a problem.

Boy did we get that proof:

Just look at the y-axis, which scale is in milliseconds. For most of the day, the average latency is 175 ms, with some high spikes. Just browsing the web was a pain during times of high-latency, which was clearly almost all of the time.

I became so fed up with our slow internet access that I decided to take matters in my own hands and resolve the low latency issue. The solution? Traffic shaping.

I learned that as ADSL-connections are saturated, especially their upload capacity, you will experience high latency and packet loss. So the trick is to never saturate the connection.

I grabbed a Linux box with two network interfaces and placed it between our internet router and our firewall in bridge mode.

For actual traffic shaping I used wondershaper which is part of Debian or Ubuntu.

apt-get install wondershaper

The wondershaper script is extremely simple, it's specifically build to resolve the problem we face with our ADSL connection. It not only prioritises traffic, it allows you to limit bandwidth usage and thus prevent you from saturating the connection.

This simple example limits bandwidth a bit below full capacity, which dramatically improved latency.

Syntax:

wondershaper <interface> <rx> <tx>

Example:

wondershaper eth1 9500 700

As you can see, latency improved dramatically:

Again, look at the y-axis. We went from an average latency of 175 ms to an average of 35 ms. That's quite an improvement.

Can you spot on which day I implemented traffic shaping?

At the time of writing this blog post, the company is working on fiber internet access, resolving our internet woes, but it will take quite some time before that will be installed, so this is a nice intermediate solution.

Achieving 450 MB/s network file transfers using Linux Bonding

2014-01-07T01:00:00+01:00

Linux Bonding

In this article I'd like to show the results of using regular 1 Gigabit network connections to achieve 450 MB/s file transfers over NFS.

I'm again using Linux interface bonding for this purpose.

Linux interface bonding can be used to create a virtual network interface with the aggregate bandwidth of all the interfaces added to the bond. Two gigabit network interfaces will give you - guess what - two gigabit or ~220 MB/s of bandwidth.

This bandwidth can be used by a single TCP-connection.

So how is this achieved? The Linux bonding kernel module has special bonding mode: mode 0 or round-robin bonding. In this mode, the kernel will stripe packets across the interfaces in the 'bond' like RAID 0 with hard drives. As with RAID 0, you get additional performance with each device you add.

So I've added HP NC364T quad-port network cards to my servers. Thus each server has a theoretical bandwidth of 4 Gigabit. These HP network cards cost just 145 Euro and I even found the card for 105 Dollar on Amazon.

With two servers, you just need four UTP cable's to connect the two network interfaces and you're done. This would cost you ~300 Euro or ~200 dollar in total.

If you want to connect additional servers, you need a managed gigabit switch with VLAN-support and sufficient ports. Each additional server will use 4 ports on the switch, excluding interfaces for remote access and other purposes.

Managed gigabit switches are quite inexpensive these days. I bought a 24 port switch: HP 1810-24G v2 (J9803A) for about 180 euros (209 Dollars on Newegg) and it can even be rack-mounted.

Using VLANS

So you can't just use a gigabit switch and connect all these quad-port network cards to a single VLAN. I tested this scenario first and only got a maximum transfer speed of 270 MB/s while copying a file between servers over NFS.

The trick is to create a separate VLAN for every network port. So if you use a quad-port network card, you need four VLANs. Also, you must make sure that every port on every network card is in the same VLAN. For example, port 1 on every card needs to be in VLAN 21, port 2 in VLAN 22, and so on. You also must add the appropriate switch port to the correct VLAN. Last, you must add the network interfaces to the bond in the right order.

So why do you need to use VLANs? The reason is quite simple. Bonding works by spoofing the same hardware or MAC-address on all interfaces. So the switch sees the same hardware address on four ports, and thus gets confused. To which port should the packet be sent?

If you put each port in it's own VLAN, the 'spoofed' MAC-address is seen only once in each VLAN. So the switch won't be confused. What you are in fact doing by creating VLANs is creating four separate switches. So if you have - for example - four cheap 8-port unmanaged gigabit switches, this would work too.

So assuming that you have four ethernet interfaces, this is an example of how you can create the bond:

ifenslave bond0 eth1 eth2 eth3 eth4

Next, you just assign an IP-address to the bond0 interface, like you would with a regular eth(x) interface.

ifconfig bond0 192.168.2.10 netmask 255.255.255.0

Up to this point, I only achieved about 350 MB/s. I needed to enable jumbo frames on all interfaces and the switch to achieve 450 MB/s.

ifconfig bond0 mtu 9000 up

Next, you can just mount any NFS share over the interface and start copying files. That's all.

Once I added each interface to the appropriate VLAN, I got about 450 MB/s for a single file copy with 'cp' over NFS.

I did not perform a 'cp' but a 'dd' because I don't have a disk array fast enough (yet) that can write at 450 MB/s.

So for three servers, this solution will cost me 600 Euro or 520 Dollar.

What about LAGs and LACP?

Don't configure your clients or switches for LACP, it doesn't give you the speed benefit and it's not required.

10 Gigabit ethernet?

Frankly, it's quite expensive if you need to connect more than two servers. An entry-level 10Gbe NIC like the Intel X540-T1 does about 300 Euros or 450 Dollar. This card allows you to use Cat 6e UTP Cabling. (Pricing from Dutch Webshops in Euros and Newegg in Dollars).

With two of those, you can have 10Gbit ethernet between two servers for 600 Euro or 700 Dollar. If you need to connect more servers, you would need a switch. The problem is that 10Gbit switches are not cheap. An 8-port unmanaged switch from Netgear (ProSAFE Plus XS708E) does about 720 Euro's or 900 Dollar.

If you want to connect three servers, you need three network cards and a switch. So three network cards and a switch will cost you 900 Euro (1050 Dollar) for the network cards and 720 Euro (900 Dollar) for the switch, totalling 1800 euro or 1950 Dollar.

You will get higher transfer speeds, but at a significantly higher price.

For many business purposes this higher price can be easily justified and I would select 10 Gb over 1 Gb bonding in a heart-beat. Less cables, higher performance, lower latency.

However, bonding gigabit interfaces allows you to use off-the-shelf equipment and maybe a nice compromis between cost, usability and performance.

Operating System Support

As far as I'm aware, round-robin bonding is only supported on Linux. Other operating systems do not support it.

Eztables: simple yet powerful firewall configuration for Linux

2013-11-16T12:00:00+01:00

I've created and released Eztables on Github. Anyone who ever has a need to setup a firewall on Linux may be interested in this project.

It doesn't matter if you need to protect a laptop, server or want to setup a network firewall. Eztables supports it all.

If you're not afraid to touch the command line and edit a text file, you may be quite pleased with Eztables.

Go check it out!

Linux: script that creates table of network interface properties

2013-08-15T00:00:00+02:00

My server has 5 network interfaces and I wanted a quick overview of some properties. There may be an existing linux command for this but I couldn't find it so I quickly wrote my own script (download).

This is the output:

The only requirement for this script is that you have 'ethtool' installed.

Update 2013-08-17

I recreated the script in python (download) so I can just dynamically format the table and not use ugly hacks I used in the bash script.

How to compile HAProxy from source and setup a basic configuration

2013-08-14T01:00:00+02:00

To learn more about HAProxy I decided to compile it from source and use it to load-balance traffic to louwrentius.com across two different web servers.

I run HAProxy on a VPS based on Ubuntu 12.04 LTS. Let's dive right in.

First, we need to download the source. Don't copy/pased the exact code, you should download the latest version of HAProxy.

cd /usr/src
wget "http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz"
tar xzf haproxy-1.4.24.tar.gz
cd haproxy-1.4.24

Before you can compile software, you must make sure you have a working build-environment. With Ubuntu or Debian, you should run:

apt-get install build-essential

If you open the README file in the root directory, you will find some detailed instructions on how to compile HAProxy, which is really straight-forward.

Compiling HAProxy

Best CPU performance

The manual states that by default, it will compile HAProxy with no CPU-specific optimisations. To enable CPU-specific optimisations, you need to use the 'native' option.