Tag: BSD

Networking

Install and Configure pfSense in Your Home Network

(20180226 – This post has been amended to reflect changes in pfSense version 2.4.2 — iceflatline)

This post will describe how to install and perform initial configuration of pfSense for use in a home network. pfSense (i.e., “making sense of packet filtering”) is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router, and managed almost entirely from a web-based GUI (“webConfigurator”). In addition to being a firewall and router, pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free and open source and its source code is released under the BSD license.

So, let’s get started…

Hardware Considerations

Minimum requirements

The minimum hardware requirements for pfSense include a 500 MHz CPU, 512 MB of system RAM, 1 GB hard drive, and a minimum of two Network Interface Controllers (NIC). You’ll also need a CD-ROM drive or bootable USB drive in order to install pfSense to the hard drive. These requirements are extremely modest, but unless your data throughput requirements are fairly small, you’re likely going to want to use hardware offering a little better performance. Since a major contributor to throughput performance is the system’s CPU, let’s start there. pfSense published guidelines for CPU sizing recommends the following:

10-20 Mbps – a modern (less than 4 year old) Intel or AMD CPU clocked at at least 500MHz
21-50 Mbps – a modern 1.0 GHz Intel or AMD CPU
51-200 Mbps – No less than a modern Intel or AMD CPU clocked at 2.0 GHz. Server class hardware with PCI-e network adapters, or newer desktop hardware with PCI-e network adapters
201-500 Mbps – server class hardware with PCI-X or PCI-e network adapters, or newer desktop hardware with PCI-e network adapters. No less than 2.0 GHz CPU
501+ Mbps – Multiple cores at > 2.0GHz are required. Server class hardware with PCI-e network adapters

Your choice of NICs will also have a significant impact on reliability and throughput performance. Low cost NICs, notwithstanding the potential long term reliability concerns, tend to rely much more on the system CPU to process segments and packets compared to their higher priced counterparts. Consequently, the better the NIC, the better the throughput performance you can expect from a given CPU. In short, don’t be too frugal when it comes to the NICs you use. Intel NICs are well supported under FreeBSD and always a good choice. If possible use discreet NICs rather than the on-board ones featured on many motherboards.

You should also ensure you have enough system memory. The pfSense hardware requirements recommend 1 GB of RAM. Whether or not you’ll need more will depend largely on how you decide to operate pfSense. Some of the add-on packages for example will increase RAM requirements significantly. Another factor to keep in mind when considering memory requirements is the number of active network connections. pfSense keeps track of active connections using a state table. The default state table size is 10,000 entries, each requiring ~1 KB of RAM or ~10 MB in total – likely more than adequate for handling most home networks. But, if you require a significantly larger state table, keep system memory requirements in mind.

Compatibility

pfSense is purportedly compatible with any hardware supported by the FreeBSD version a particular pfSense build is based upon. pfSense version 2.4.2 for example is based upon FreeBSD 11.1-RELEASE. It’s always a good idea, however, to check the hardware you’re planning to use against the information contained in the FreeBSD 11.1-RELEASE hardware notes and the hardware compatibility section of the Frequently Asked Questions for FreeBSD 10.x and 11.x. The pfSense forums are another good resource, useful for gleaning the hardware compatibility experiences of others.

Installation

Performing a full installation of pfSense is a straight forward; however, before you get started there are a couple of preliminary steps I recommend. First, make a note of the Media Access Control (“MAC”) address for each NIC you’re installing in the system as well as its physical location in the motherboard. If your memory is as bad as mine, this will save you from wondering later “…now which NIC did I assign as the LAN interface?…” Second, disconnect the NICs from any LAN and WAN devices until you have the box up and running and configured to your requirements. Finally, if you have other hard drives in the system I recommend disconnecting them until the installation is complete so as to not accidentally install to the wrong drive.

Download a copy of the pfSense installer and burn it to a CD or place it on a bootable USB drive. After booting the system using the CD or USB drive and accepting the copyright and distribution notice, you’ll arrive at the initial installation screen (See Figure 1).

Figure 1

Select “OK” to continue. The pfSense installer will ask whether it should continue with the default U.S. keyboard key map or use a different one (See Figure 2).

Figure 2

After configuring the keymap, the installer will ask and whether it should partition the hard drive using the UFS or ZFS file system. I advise using ZFS if possible (See Figure 3).

Figure 3

Unless your requirements call for something different, the default ZFS configuration options will work just fine (See Figure 4).

Figure 4

Next, the installer will ask you select a ZFS virtual device type. The steps in this post assume you’ll be installing pfSense on a single hard drive. The stripe option is the correct choice in this case. If your requirements call for installing pfSense using two or more hard drives then you have the option of selecting a mirror or one of the raidz virtual devices types (See Figure 5).

Figure 5

The installer will then ask you to confirm the choice of hard drives (See Figure 6).

Figure 6

Finally, the installer will offer one last chance before destroying any previous content contained on the hard drive and continuing with the installation. If you’re satisfied with your configuration choices select “YES” to proceed (See Figure 7).

Figure 7

After the installer finishes the installation you’ll be offer the opportunity to open a shell session in order to make any modifications manually (See Figure 9).

Figure 8

If no further changes are required select “No” the installation will be complete and the system will ask to be rebooted (See Figure 9).

Figure 9

Configuration

After pfSense is installed and the system rebooted, you’ll arrive at the pfSense console menu (See Figure 10).

Figure 10

Note that in this example pfSense has chosen the NIC assigned the device name em1 as the WAN interface, and em2 as the LAN interface (I have a third NIC in this system, which is why you see an em0 device). If you’d like to reassign these interfaces or simply want to know which MAC address belongs to each NIC, then select “Assign Interfaces” (menu option 1). Note also that pfSense initially assigns the LAN interface the default static IPv4 address of 192.168.1.1, and configures the WAN interface to use DHCP so you will not see an IP address assigned to that interface.

Select “Set interface(s) IP address” (menu option 2) to configure pfSense’s LAN interface IPv4 address to one that will fall within the subnet you plan to use for your network. In this example we’ve configured the IPv4 address to 192.168.10.1, assuming that the subnet will be 192.168.10.0/24.

Figure 11

This menu option also allows you to activate pfSense’s DHCP server and define a range of IPv4 addresses for the server to use. In this example we’ve configured the DHCP address range to be 192.168.10.101 to 192.168.10.254 (See Figure 12)

Figure 12

Once the IPv4 address and DHCP server are configured, you’ll be asked if I want to revert to HTTP as the webConfigurator protocol (as opposed to using to using HTTPS). I recommend declining this option to improve login security. After these steps are completed you will be returned to the console menu.

Now, connect to the LAN interface, fire up your web browser, and navigate to IPv4 address you assign to the LAN interface to access the pfSense webConfigurator. The webConfigurator login is password protected – the default login is admin and the password is pfsense. The first time you login to a new installation of pfSense, you ne greeted with the pfSense setup wizard to perform an initial configuration (See Figure 13).

Figure 13

The setup wizard starts by asking you to define the hostname for your new pfSense system, the domain where it will reside, and primary and secondary DNS servers. You can use any hostname you’d like but be aware of the following constraints: the hostname you choose must start with a letter, and after that contain only letters, numbers or a hyphen (e.g., “firewall” or “firewall-1”). The “Domain” field can be filled in with any fully qualified domain (e.g., “mysite.org”) or a name of your choice (e.g., “homenet”). The hostname and domain fields are combined to create the fully qualified domain name of your pfSense box (e.g., “firewall.mysite.org” or “firewall.homenet”). If your service provider provisions your service using DHCP, then the DNS fields will be likely be filled in automatically when you connect to your provider. If you plan to use a static WAN IP address, or simply prefer to use alternative DNS providers, then you should provide at least a primary DNS address at this point (See Figure 14).

Figure 14

The next wizard screen is where a time server hostname and timezone are defined. I recommend using the default host 0.pfsense.pool.ntp.org, which results in a random server from a pool of known good NTP servers to be chosen automatically (See Figure 15).

Figure 15

Next, you’ll be taken to the WAN section of the setup wizard. If your service provider provisions your service using DHCP, then you simply need to select “DHCP” from drop-down list, otherwise chose the appropriate service type. The “MAC Address” field under “General configuration” can be used to enter a MAC address that will pose as the MAC address of your WAN interface NIC. The “Block RFC1918 Private Networks” and “Block bogon networks” sections are selected by default in order to block invalid traffic from entering your network. The remaining sections in this portion of the setup wizard are specific to WAN service type chosen (See Figure 16)

Figure 16

After the WAN section, you’ll encounter the final two sections of the setup wizard. These provide the opportunity to change, if desired, the LAN IP address as well as the default password for the admin user account. Note that this password also serves as the password for SSH access as well as the console menu (should you decide to password protect it).

At the conclusion of the setup wizard, you’ll select “Reload” and after a few moments be returned to the pfSense webConfigurator. At this point basic connection options are configured enough to allow the pfSense box to be safely connected to the service provider and LAN. However, before bringing pfSense online in your network there are a couple of optional changes to its configuration you may wish to consider.

Disable webConfigurator login autocomplete

By default login credentials for the webConfigurator may be saved by a web browser. Navigate to System->Advanced->Admin Access and select “Disable webConfigurator login autocomplete” to disable autocomplete on the login form so that browsers will not prompt to save credentials (Note that some browsers do not respect this option). When complete, select “Save”.

Password protect the console menu

While pfSense is managed almost entirely from its webConfigurator, it does allow some configuration management through its console menu (See Figure 10). By default, pfSense does not secure this menu, therefore, anyone who can physically connect a monitor to the pfSense machine will have root level shell access. To prevent this (or at least make it more difficult), navigate to System->Advanced->Admin Access and select “Password protect the console menu.” When complete, select “Save.” You’ll need to reboot the system for this change to take effect. Note that the user name for the console menu is always admin or root and the password will be “pfSense” by default, or the one you chose if you elected to change the default admin password when running the setup wizard. It’s also worth noting here that if you create a new user, this new user will only be allowed access to a command line prompt at the terminal, not the console menu itself, even if you add them to the system’s admins group (See System->User Manager).

NAT Reflection mode for port forwards

By default pfSense prevents hosts within the LAN from accessing your public IP addresses. This can be inconvenient at times, particular when testing port forwarding from within the LAN. To change this, navigate to System->Advanced->Firewall & NAT and, depending on your requirements, select either “NAT + proxy” or “Pure NAT” from among the options in the drop down list under “NAT Reflection mode for port forwards”. When complete, select “Save”. A reboot is not needed when selecting this option so you can use it on an as-needed basis if desired.

Packages

As mentioned, pfSense offers a fairly extensive package system allowing you to extend its capabilities. To find a list of packages that can be added, navigate to System->Package Manager->Available Packages to view the available software packages.

Firewall

Setting up NAT port forwarding and firewall rules in pfSense can be a bit daunting at first. Once you get the hang of it though you’ll realize just how flexible and powerful the system is. Options for configuring port forwarding and firewall rules can be found under Firewall->NAT and Firewall->Rules respectively. I recommend setting up any port forwarding rules you may have first. Then, for each port forwarding rule, you’ll need to set up an associated firewall rule. When complete, select “Save”, then “Apply changes”.

DHCP

Options for configuring the DHCP server on the LAN interface can be found under Services->DHCP server. If you’re deploying pfSense in a typical home network where the availability of IP addresses is not a concern, one option you may want to consider changing is the default lease time of 7200 seconds (two hours) in order to reduce the number of lease requests in the network. This is also the section where you can assign static IP addresses to hosts, if desired. For example, you may wish to assign static IP addresses to servers and network devices (managed switches, network printers, etc.), as well as to any hosts you intend to build long-term port forwarding rules for.

UPnP

If you have game consoles like Microsoft Xbox, you know what a pain it can be at times to get them to connect reliability to services like Xbox Live through your home network gateway/firewall. A common solution is to forward the necessary ports to these devices, but what if you have more than one? If you want one or more game consoles to have reliable access to their respective services, the only real solution is to use Universal Plug and Play (UPnP). Fortunately, pfSense’s UPnP service works remarkable well. To activate it, navigate to Services->UPnP & NAT PMP and select “Enable UPnP & NAT PMP” and “Allow UPnP Port Mapping” then ensure that the LAN interface is selected under “Interfaces”. When complete, select “Save”. That’s it. Your game consoles will discover pfSense’s UPnP server and the necessary port forwarding rules will be built automatically as needed. You can check which ports have been forwarded by navigating to Status->UPnP & NAT PMP.

Wake on LAN

The Wake on LAN in feature in pfSense allows you to instruct it to send the Wake on LAN “magic packet” to a network host you need to power up. To setup Wake on LAN, navigate to Services->Wake-on-LAN and select the “+ Add” icon. Select the LAN interface and enter the MAC addresses for the host you’d like to send magic packets to. When complete, select “Save”.

System Logs

You may wish to have log entries arranged so that the newest entries appear first. To do that, navigate to Status->System Logs->Settings and select “Show log entries in reverse order (newest entries on top)”. When complete, select “Save”.

Remote Access

pfSense’s webConfigurator uses HTTPS and port 443 by default, and accessing it remotely is simply a matter of navigating to your WAN address. Unfortunately, many ISPs block incoming port 443 traffic. You can chose an alternate incoming TCP port by navigating to System->Advanced->Admin Access and entering the port number in the “TCP port” field. When complete, select “Save”. You will also need to create a new firewall rule under Firewall->Rules that will allow a connection on the WAN interface to pass through to pfSense’s webConfigurator server on the port you specify. At a minimum, this rule should define following parameters:

Action: Pass
Interface: WAN
TCP/IP Version: IPv4
Protocol: TCP
Destination: WAN address
Destination port range: your alternate webConfigurator port selection
Description: web admin

pfSense’s SSH server may also be enabled to allow remote access to the console menu via an SSH client. To enable the SSH server, navigate to System->Advanced and select “Enable Secure Shell”. For improved security, I recommend using an incoming port other than 22 and a key-based login instead of a password. To use a key-based login, select “Disable password login for Secure Shell (RSA/DSA key only)” and select “Save”. Then navigate to System->User Manager and paste your public key into the “Authorized SSH Keys” field. When complete, select “Save”. Note that your public SSH key is stored in /root/.ssh/authorized_keys. Should you need help generating a public/private key pair please see my post Remote Access To Your Ubuntu Server Using PuTTY, Hamachi and SSH. Don’t forget to create a new firewall rule under Firewall->Rules that will allow a connection on the WAN interface to pass through to pfSense’s SSH server should you decide to use an alternate SSH port.

Conclusion

This concludes the post on how to install and configure pfSense on your home network. pfSense isn’t hard to configure nor complicated to manage, and proves to be a nice open source package for implementing a robust and scalable perimeter firewall and router.

Linux

Using The dd Command to Create Files of a Specific Size

Occasionally, the need arises for files of a specific size. Transferring said files between hosts, for example, can provide a quick indication of your network throughput. One easy way to build a file of a specific size is with the Data Description or dd command. The dd command is one of the original Unix utilities, used to perform low-level copying of a specified input file to the specified output file (standard input to standard output is the default) according to operands, while optionally performing conversions on the raw data. You’ll often see it used to create an image of a entire disk or the disk’s Master Boot Record, or to make a disk from an image.

Let’s open a terminal in Linux and create a file named “test-file” that’s one kilobyte (decimal units) in size:

mkdir ~/testfiles && cd ~/testfiles	
dd if=/dev/zero of=test-file bs=1KB count=1

1 2	mkdir ~/testfiles && cd ~/testfiles dd if=/dev/zero of=test-file bs=1KB count=1

You should see something that resembles the following output:

1+0 records in
1+0 records out
1000 bytes (1.0 kB) copied, .000145457 s, 6.9 MB/s

1+0 records in

1+0 records out

1000 bytes (1.0 kB) copied, .000145457 s, 6.9 MB/s

To create a larger file, say one megabyte or one gigabyte, replace the KB multiplicative suffix in the bs operand with MB or GB respectively:

dd if=/dev/zero of=test-file bs=1GB count=1

1	dd if=/dev/zero of=test-file bs=1GB count=1

How about a file that’s 1.5 gigabytes? You can accomplish this by adjusting the bs multiplicative suffix and the number of blocks in the count operand:

dd if=/dev/zero of=test-file bs=1MB count=1500

1	dd if=/dev/zero of=test-file bs=1MB count=1500

To use binary units (multiplication by a power of 2) instead of decimal units, simply drop the “B” in the bs multiplicative suffix. Let’s recreate our test file using binary units (one megabyte = 1048576 bytes):

dd if=/dev/zero of=test-file bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.002878 s, 364 MB/s

dd if=/dev/zero of=test-file bs=1M count=1

1+0 records in

1+0 records out

1048576 bytes (1.0 MB) copied, 0.002878 s, 364 MB/s

Note for users of FreeBSD (and possibly other Unix-like operating systems), the dd command supports binary units only. For example, attempting to use bs=1MB instead of bs=1M will result in an error.

There you have it. A nice simple way to create files of a specific size for network testing or whatever your needs might be. Leave comment if you have a favorite use for the dd command.

Networking

How to Install and Configure dnsmasq

This post will describe how to install and configure dnsmasq on a Linux- or Unix-based host. Once configured, you’ll be able to use dnsmasq to provide DNS and DHCP services in your home network.

So, why do you even need dnsmasq? Afterall, your ISP provides DNS and your home network gateway/router likely provides DHCP service for your network, right? Perhaps the best way to answer then is to explain the problem I was trying to solve. In my home network I would typically assign a static IP address to each host on my network, and then use its host file to resolve the host’s name to the IP address it was assigned. This approach allowed me to easily communicate between these hosts by simply typing their name rather than trying to remember their static IP address. However, as the number of hosts on my network started to grow, configuring static IP addresses and constantly updating the host files became unwieldy. dnsmasq solves this problem.

dnsmasq is a small, lightweight, and easy to configure caching DNS proxy and DHCP server targeted at small or home networks. It can serve the names of local hosts which are not in the global DNS, and its DHCP server integrates with its DNS server to allow hosts with DHCP-allocated addresses to appear in the DNS along with names configured either in each host or in its configuration file. dnsmasq supports static and dynamic DHCP leases and even BOOTP/TFTP for network booting of diskless hosts. dnsmasq is opensource software and is distributed under the terms of the GPL. Supported platforms include Linux, *BSD, Solaris and Mac OS X.

The versions for the software used in this post were as follows:

FreeBSD 7.2 RELEASE and dnsmasq v2.52,1

Fedora v12 and dnsmasq v2.51-1.fc12

Ubuntu server v9.10 and dnsmasq v2.47-3_all.deb

Download and Install

I chose to install dnsmasq on my Ubuntu server-based machine. However, any host on your network in which you can add one or more external nameservers to /etc/resolv.conf and some or all of your hosts in /etc/hosts, can easily be used for hosting dnsmasq.

To install dnsmasq on a Debian-based distribution like Ubuntu:

sudo apt-get install dnsmasq

1	sudo apt-get install dnsmasq

On Fedora-based distributions:

$ su
# yum install dnsmasq

1 2	$ su # yum install dnsmasq

And on *BSD, if you’ve installed the Ports collection:

$ cd /usr/ports/dns/dnsmasq/ 
$ su
# make install clean

$ cd /usr/ports/dns/dnsmasq/

$ su

# make install clean

Or, if you would prefer to add the package:

$ su
# pkg_add -r dnsmasq

1 2	$ su # pkg_add -r dnsmasq

The dnsmasq script will be installed in /etc/init.d, symlinked from runlevels 2-5, and start automatically in a Debian-based distribution like Ubuntu. In Fedora-based distributions, the dnsmasq script is installed in /etc/init.d; however, you will need to create a symbolic link to it from the appropriate runlevel directory in order for it to start automatically at boot time. This is typically done using chkconfig command as root. The following example shows how to add the dnsmasq script to runlevels 2-5 and start dnsmasq in Fedora:

$ su
# chkconfig dnsmasq on
# /etc/init.d/dnsmasq start

$ su

# chkconfig dnsmasq on

# /etc/init.d/dnsmasq start

Newer versions of Fedora, however, may require this set of commands instead:

$ su
# systemctl enable dnsmasq.service
# systemctl start dnsmasq.service

$ su

# systemctl enable dnsmasq.service

# systemctl start dnsmasq.service

In *BSD, the dnsmasq script will be installed in /usr/local/etc/rc.d. To get dnsmasq to start at boot time, add the following line to /etc/rc.conf:

dnsmasq_enable="YES"

1	dnsmasq_enable="YES"

Then start dnsmasq:

$ su
# /usr/local/etc/rc.d/dnsmasq start

1 2	$ su # /usr/local/etc/rc.d/dnsmasq start

Configure

Configuring dnsmasq is straightforward. The various DHCP and DNS options can be passed via command line when starting dnsmasq, or may be set via its configuration file, dnsmasq.conf. I generally prefer to use dnsmasq’s configuration file; it’s very well commented and easy to follow.

Let’s walk through the changes I made to the default configuration file in order to provision both DNS and DHCP service for my network. Make sure you create a backup copy of your default file before you begin.

To start, I uncommented the following two options to force dnsmasq to filter my local network DNS queries so they did not reach the public DNS servers.

# Never forward plain names (without a dot or domain part)

domain-needed

# Never forward addresses in the non-routed address spaces.

bogus-priv

# Never forward plain names (without a dot or domain part)

domain-needed

# Never forward addresses in the non-routed address spaces.

bogus-priv

By default, dnsmasq will send queries to any of the nameservers you define in /etc/resolv.conf, however, it will try to favor those it knows to be up. Uncommenting the following setting forces dnsmasq to use the nameservers listed in /etc/resolv.conf strictly in the order they appear. Since I had a pretty good sense of which DNS servers I wanted to use and in what order I uncommented this line:

strict-order

1	strict-order

By default dnsmasq will listen for DNS queries on all network interfaces. I have several interfaces on my server (Hamachi, eth0, eth1, etc.), but only one that is physically connected to my local network, so I uncommented the following line in order to force dnsmasq to listen for DHCP and DNS requests on that interface only – in my case eth0. Simply repeat the line with the another interface name if you have additional interfaces you would like dnsmasq to listen to.

interface=eth0

1	interface=eth0

The following two lines are optional; however, if used, dnsmasq will append the domain name you choose to the host names defined in dnsmasq.conf and/or /etc/hosts. I use these, but the only real benefit I saw in my network was that I was able to ping devices such as my game consoles based on the names I defined for them using the dhcp-host parameter (see below).

# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.

expand-hosts

# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
#     as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
#    domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"

domain=home.net

# Set this (and domain: see below) if you want to have a domain

# automatically added to simple names in a hosts-file.

expand-hosts

# Set the domain for dnsmasq. this is optional, but if it is set, it

# does the following things.

# 1) Allows DHCP hosts to have fully qualified domain names, as long

# as the domain part matches this setting.

# 2) Sets the "domain" DHCP option thereby potentially setting the

# domain of all systems configured by DHCP

# 3) Provides the domain part for "expand-hosts"

domain=home.net

To enable dnsmasq’s integrated DHCP server you’ll need to uncomment the following line and provide the range of addresses available for lease in your network, and optionally, a lease time.

dhcp-range=192.168.10.100,192.168.10.254,24h

1	dhcp-range=192.168.10.100,192.168.10.254,24h

If you have a host on your network that you’d like to have receive the same IP address every lease, then uncomment the following line and provide the host’s MAC address, as well as the preferred IP address – one from the dhcp-range you defined above. For example, I like to have the computer I use most often receive the same IP address. That way I can easily forward ports to it, etc. Alternatively, I could have simply given it a static IP address and defined the name/address combination in the /etc/hosts file of the machine hosting dnsmasq.

dhcp-host=00:27:0E:02:A8:AE,192.168.10.100

1	dhcp-host=00:27:0E:02:A8:AE,192.168.10.100

If your network is anything like mine you probably have devices that don’t have a host names associated with them the same way a computer does (e.g., Xbox 360). The following parameter will assign a name to these devices in dnsmasq. You’ll need to provide the devices’s MAC address and the name you’d like associated with it. Here’s an example of how I have this defined in my network:

dhcp-host=00:0B:E6:05:38:47,wii
dhcp-host=00:22:48:48:EE:37,xbox2
dhcp-host=00:12:5A:99:67:DE,xbox1
dhcp-host=00:04:5A:A5:26:B0,tivo1
dhcp-host=00:1D:7E:00:E5:58,tivo2

dhcp-host=00:0B:E6:05:38:47,wii

dhcp-host=00:22:48:48:EE:37,xbox2

dhcp-host=00:12:5A:99:67:DE,xbox1

dhcp-host=00:04:5A:A5:26:B0,tivo1

dhcp-host=00:1D:7E:00:E5:58,tivo2

By default dnsmasq assumes that host running dnsmasq is your gateway/router. That wasn’t the case in my network so I needed to specify the IP address of my Cisco gateway/router in the following line:

dhcp-option=3,192.168.10.1

1	dhcp-option=3,192.168.10.1

The DHCP server needs somewhere keep its lease database file. I simply retained the default location chosen by dnsmasq for my Ubuntu server install. Note that this default location will vary depending on which platform your using to host dnsmasq:

#dhcp-leasefile=/var/lib/misc/dnsmasq.leases

1	#dhcp-leasefile=/var/lib/misc/dnsmasq.leases

Finally, you can adjust the number of entries dnsmasq will keep in its DNS cache in the following line. I retained the default of 150.

#cache-size=150

1	#cache-size=150

That’s it for configuring dnsmasq.conf. Keep in mind though that the options described here really only scratch the surface. I would strongly urge you to read through dnsmasq.conf thoroughly as there are many more options available for fine-tuning dnsmasq’s numerious capapbilities. But for now let’s move on and consider two additional files, /etc/resolv.conf and /etc/hosts, that are important when configuring dnsmasq.

resolv.conf

dnsmasq will consult a several locations when going about the business of resolving your network’s DNS queries. These locations include its internal cache, for any queries it may have already resolved; /etc/hosts, for any static name/IP address combinations that may be defined there; and, if the DHCP server is being utilized, it will of course know from its configuration file and lease database file which IP addresses it has assigned to the hosts configured to use DHCP. When it can’t resolve DNS queries via these methods, dnsmasq will send queries to the nameservers defined in /etc/resolv.conf. You must have at least one public DNS server defined there and it’s typical to simply use the DNS server(s) provided by your ISP. Following is an example of how I have my /etc/resolv.conf file configured. Recall that I uncommented the strict-order line in dnsmasq.conf as described above so dnsmasq will utilize DNS servers in the order I have them listed here.

#Allow applications on the machine hosting dnsmasq to also use it too

nameserver 127.0.0.1

#Google DNS

nameserver 8.8.8.8

#OpenDNS

nameserver 208.67.222.222
nameserver 208.67.220.220

#Cox

nameserver 68.105.28.11
nameserver 68.105.29.11
nameserver 68.105.28.12

#An option to use my network gateway/router as the upstream DNS. Note that the #pubic DNS server addresses will need to be defined in the router.

#nameserver 192.168.10.1

#Allow applications on the machine hosting dnsmasq to also use it too

nameserver 127.0.0.1

#Google DNS

nameserver 8.8.8.8

#OpenDNS

nameserver 208.67.222.222

nameserver 208.67.220.220

#Cox

nameserver 68.105.28.11

nameserver 68.105.29.11

nameserver 68.105.28.12

#An option to use my network gateway/router as the upstream DNS. Note that the #pubic DNS server addresses will need to be defined in the router.

#nameserver 192.168.10.1

/etc/hosts

As I mentioned, dnsmasq will consult the /etc/hosts file on the host its running on when resolving DNS queries. This comes handy when there are hosts in your network that you have assigned, or would like to assign, static IP addresses to. In those cases the host name/IP address combinations can simply be added to /etc/hosts. In fact, if desired, you could elect not to use dnsmasq’s DHCP server at all and rely soley on dnsmasq’s use of /etc/hosts to resolve local IP addresses. In this respect, /etc/hosts is no different than any other host file resident on most computers except that now you only need to maintain the one file. Of course, the tradeoff is that you’ll need to configure static IP addresses on all your hosts. I settled on a hybrid approach for my network. I configured all client hosts (laptops, desktop PCs, game consoles, etc) to use dnsmasq’s DHCP server, and configured all servers and network equipment (access point, router, network printers, etc.) with static IP addresses. Here’s an example of my /etc/hosts file:

127.0.0.1       localhost
192.168.10.1    router
192.168.10.2    wap
192.168.10.4    server1
192.168.10.11   server2
192.168.10.51   print-hp
192.168.10.52   print-canon

127.0.0.1 localhost

192.168.10.1 router

192.168.10.2 wap

192.168.10.4 server1

192.168.10.11 server2

192.168.10.51 print-hp

192.168.10.52 print-canon

Final Steps

Once dnsmasq.conf, /etc/resolv.conf, and /etc/hosts are configured to your liking restart dnsmasq:

# /etc/init.d/dnsmasq restart

1	# /etc/init.d/dnsmasq restart

Or, if your using *BSD:

# /usr/local/etc/rc.d/dnsmasq restart

1	# /usr/local/etc/rc.d/dnsmasq restart

Make sure to disable any other DHCP servers that may be running in your network, then simply configure your hosts to use DHCP – they should recieve an IP address that’s in the range defined in dnsmasq.conf. If you’re planning on configuring some hosts with static IP addresses, set the IP address of the host running dnsmasq as the DNS server and IP address of the gateway/router as the gateway. You’ll also want to make sure to enter that host/IP address information in /etc/hosts on the host running dnsmasq. That’s it! You now have DNS and DHCP service up and running in your network.

Now let’s run a quick test to make sure dnsmasq is caching DNS queries. The simplest to do that is to use the dig utility:

$ dig iceflatline.com

1	$ dig iceflatline.com

When you look at the output from dig and find the line showing the query time. Note the time and run the command again. You should see a noticable improvement in response time indicating that dnsmasq is caching query results locally.

Conclusion

This concludes the article on how to install and configure dnsmasq on your Linux- or Unix-based host. As you can see, dnsmasq isn’t terribly complicated and proves to be a really nice open source package for implementing a small, lightweight caching DNS proxy and DHCP server. For a full list of all the configuration options and other information I encourage you to visit the dnsmasq web site.

References

http://www.thekelleys.org.uk/dnsmasq/docs/setup.html
http://www.thekelleys.org.uk/dnsmasq/docs/FAQ

BSD

Install and Configure Hamachi on FreeBSD

Update: Due to protocol changes instituted by LogMeIn on or around July 30 2012, the linux-hamachi client version referenced in the post can no longer be used to login to Hamachi servers. This post will be retained for archival purposes.

In this post I’ll discuss how to install and configure Hamachi and SSH on a machine running FreeBSD. If you’re not familiar with LogMeIn Hamachi (formerly known as just “Hamachi”), it is a hosted VPN service that is capable of establishing secure LAN-like links between computers, even if they’re behind Network Address Translation (NAT) devices. You can use it to create secure virtual networks on demand, across public or private networks.

In order for Hamachi to work, a “mediation server,” operated by the LogMeIn, is required. The mediation server stores machine nicknames, statically allocated 5.0.0.0/8 IP addresses and the associated authentication token of the user. Hamachi is free for non-commercial use. However, the Hamachi security implementation is closed source and as such is not available for review by the general public.

The versions for the software used in this post were as follows:

FreeBSD 9.0-RELEASE
linux-hamachi-0.9.9.9.20

Install Hamachi

Hamachi requires Linux binary compatibility which is not turned on by default in FreeBSD 8.2-RELEASE. The easiest way to enable this functionality is to load the linux KLD object (“Kernel Loadable Object”) by typing the following as root:

kldload linux

1	kldload linux

Then add the following line to /etc/rc.conf:

linux_enable="YES"

1	linux_enable="YES"

Now we’re ready to install Hamachi. If you’ve installed the FreeBSD ports collection then run the following as root to install the Hamachi port:

cd /usr/ports/security/hamachi/
make install clean

1 2	cd /usr/ports/security/hamachi/ make install clean

Otherwise you can grab the binary package and install it:

pkg_add -r linux-hamachi

1	pkg_add -r linux-hamachi

Now, let’s configure Hamachi and create our VPN. Hamachi requires the tap kernel driver to create and manage its virtual Ethernet network interface. No worries though, Hamachi adds the script /usr/local/etc/rc.d/hamachi that will automatically load the tap driver if_tap.ko. This driver must be loaded and running before starting Hamachi itself. You can have it load automatically when FreeBSD starts by adding the following line as root to /etc/rc.conf:

hamachi_enable="YES"

1	hamachi_enable="YES"

If you want only to run Hamachi periodically and not start the tap driver automatically at boot time, you can use forcestart/forcestop as root, which will ignore the setting in /etc/rc.conf:

/usr/local/etc/rc.d/hamachi forcestart

1	/usr/local/etc/rc.d/hamachi forcestart

Our next step generates the cryptographic key pair and creates a directory at ~/.hamachi where Hamachi will store these keys, as well as its configuration and state. This step only needs to be performed once per Hamachi install; however, it must be done for each user account that you plan to use Hamachi from, including root. Consequently, we’ll run the following commands from our user account:

hamachi-init

1	hamachi-init

Okay, now let’s start Hamachi. First, make sure the tap driver is loaded by rebooting the machine (assuming the hamachi_enable=”YES” line is in /etc/rc.conf as described above) or by using the forcestart command, then:

hamachi start

1	hamachi start

When Hamachi is run for the first time, the Hamachi daemon stays offline. Let’s bring it online:

hamachi login

1	hamachi login

Next, create a nickname for the FreeBSD machine so that we can identify it easily from another machine on your Hamachi VPN:

hamachi set-nick <nickname>

1	hamachi set-nick <nickname>

Now, let’s create our Hamachi VPN. In this step you’ll need to enter a unique name for your network as well as a password for it. If your network name is already in use somewhere you’ll need to keep trying until you land upon one that’s unique. If you’ve setup a Hamachi VPN previously and simply want to add your FreeBSD machine to it, then substitute join for create in the following command:

hamachi create <network> <password>

1	hamachi create <network> <password>

Now let’s put the FreeBSD machine online on the VPN:

hamachi go-online <network>

1	hamachi go-online <network>

That’s it. Your Hamachi VPN should now be up and running with your FreeBSD machine added as one of the hosts. What if we reboot, do all these commands need to be entered again? The answer is no. Once the Hamachi VPN is created/joined, the nickname established, and the machine added with the go-online command, should you need to reboot your box, you can simply restart the tap driver (assuming you elected not have it start automatically) and then start Hamachi, you’ll then be back online. However, you can also have Hamachi start automatically at boot time by adding a shell script in your system startup sequence. You will of course want to have the tap driver start automatically as well for this to be of any benefit. Here’s a generic version of the script I use:

#!/bin/sh
### START OF SCRIPT
USER=<your user name>
case "$1" in
start)
su - $USER -c "hamachi start"
;;
stop)
su - $USER -c "hamachi stop"
;;
reload)
/bin/su - $USER -c "hamachi stop"
/bin/su - $USER -c "hamachi start"
;;
*)
exit 1
;;
esac
exit 0
### END OF SCRIPT

#!/bin/sh

### START OF SCRIPT

USER=<your user name>

case "$1" in

start)

su - $USER -c "hamachi start"

;;

stop)

su - $USER -c "hamachi stop"

;;

reload)

/bin/su - $USER -c "hamachi stop"

/bin/su - $USER -c "hamachi start"

;;

exit 1

;;

esac

exit 0

### END OF SCRIPT

To use this script simply add your account user name, save it as hamachi_start.sh in /usr/local/etc/rc.d/ and make it executable. You’re free to choose a different name, however, note that scripts within /usr/local/etc/rc.d/ are executed in lexicographical order. Since it is desirable that the existing script hamachi start first in order to load the tap driver, you should name the hamachi start script something that will ensure it starts after hamachi. Numbers may be used as a prefix to the filename.

You can display the status of the Hamachi daemon at any time by running the command hamachi without any arguments:

hamachi
version  : hamachi-lnx-0.9.9.9-20
pid      : 846
status   : logged in
nickname : bsd

hamachi

version : hamachi-lnx-0.9.9.9-20

pid : 846

status : logged in

nickname : bsd

The following commands will retrieve the nicknames and print a list of the hosts that are currently members of your Hamachi VPN, as well as their Hamachi IP addresses (you will not see the machine you issued the command from listed):

hamachi get-nicks && hamachi list

1	hamachi get-nicks && hamachi list

And if needed, you can stop Hamachi with the command hamachi stop:

hamachi stop
Shutting down .. ok

1 2	hamachi stop Shutting down .. ok

Now then, to initiate a terminal session with another host on your Hamachi VPN:

ssh <hamachi-IP address-for-remote-host>

1	ssh <hamachi-IP address-for-remote-host>

If this is the first time connecting, you’ll likely receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. Accept by typing yes and you’ll be presented with the login and password prompt (this warning prompt will only occur once per machine). The public key from the remote host will be stored in ~/.ssh/known_hosts. If you don’t want to have to remember the Hamachi IP address each time you want to run a session with another host, simply add this IP address along with a name (e.g. home-server-ssh) to your hosts file (/etc/hosts). Next time you use Hamachi/SSH to connect to this host, use the name instead of the IP address and the host file will resolve the IP address for you.

SSH Server

Now that we’ve installed Hamachi, created or joined a VPN, and perhaps tested it by connecting to another host on the VPN. Let’s make sure there’s a running SSH server on our FreeBSD machine so that incoming SSH requests can be answered:

/etc/rc.d/sshd status
sshd is running as pid 811.

1 2	/etc/rc.d/sshd status sshd is running as pid 811.

Should you need to install sshd, type sysinstall. Select Configure ->Networking and select sshd from among the options. Make sure sshd enabled by checking the /etc/rc.conf file for the line sshd_enable=”YES”. This will load sshd the next time your system starts. You can also start sshd manually as root through the /etc/rc.d/sshd script:

/etc/rc.d/sshd start

1	/etc/rc.d/sshd start

Conclusion

This post described how to install and configure Hamachi on a machine running FreeBSD. The reason I like using LogMeIn Hamachi is that it allows me to connect via SSH, SCP or SFTP to my FreeBSD machine at home from essentially anywhere I have an internet connection without the need to make any changes to my router/gateway. To learn how to install and configure Hamachi on Linux or Windows machines, as well as how to improve the security of the connections over the Hamachi VPN using public key authentication, please see my previous post.

References

http://www.openssh.com/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/