Setting up a Linux based DNS server with BIND

April 29, 2012August 31, 2015 Josh Reichardt 7 Comments

As my home lab continues to grow and becomes increasingly complicated I need an easy way to access my servers and network resources by their name rather than their addresses on the network. By using DNS I can quickly and efficiently access these network resources by their given host names, not having to worry about the growing complexity of the network. I looked into a few different options for accomplishing this task but ultimately decided to go with the tried and true Linux BIND implementation. The installation and configuration isn’t all that complicated to get up and running, so in this post I will go through some of the high points of my experience in standing up this service. Let’s get going.

First, we need to install the proper packages. By the way I was using a Debain 6.0 minimal VM for my server in this project. So to install this stuff you need to update your repos to look for the packages.

apt-get update

Then the necessary packages

apt-get install bind9 dnsutils resolvconf

We need to configure the correct files to make our DNS function properly. Everything that we need to configure (for Debian distros) should be located in /etc/bind. So the first thing to change is the named.conf.local file to create the zones for our local network. We need a zone for resolving names to IP addresses as well as a zone reverse DNS. If you don’t know what that is, you can find more here. In my configuration psa.local is my local domain so any hostname will resolve to hostname.psa.local in DNS. Here is what my named.conf.local configuration file looks like:

Next, we need to set up our zones to point to the correct hosts. The easiest way is to use the db.local as a template and copy it to a new file. cp /etc/bind/db.local /etc/bind/db.psa.local Here is what my db.psa.local file looks like:

We need to do the same thing with our reverse records. For me, his file is located in db.192 and we will use db.127 as the template for this file. cp /etc/bind/db.127 /etc/bind/db.192. If you are using a different type of network layout adjust accordingly. For example if your network is a 172.x.x.x network just name the file as db.172 or whatever the network is. Here is what the configuration looks like, it is similar to our forward lookup zone.

Now we should be able to resolve host names (both forward and reverse) to the entries we’ve added to these configuration files. Next we need to edit our resolv.conf file to get our host name resolution to work smoothly. So edit /etc/resolv.conf with your favorite text editor and make the necessary changes. Here is what mine looks like after the necesary tweaks. NOTE I haven’t figured out why yet, but every time you restart your bind service it wipes this config out, I will update this when I figure out how to make these changes persistent.

Finally, and most importantly, here is my final named.conf.options file, with all the troubleshooting done. This file tells bind where to forward DNS queries externally as well as other important configuration options. You can adjust the forwarders to whichever public DNS server you choose. I chose two well known DNS servers. There are a few things to note here. If you are having issues with anything check the log files 🙂 At first I had strange resolution errors for anything that was external to my domain. The logs helped me pinpoint where the problems were and to make the necessary changes. The most important iformation for troubleshooting is located in /var/log/syslog.

The last few entires in this file are very important for getting external DNS to resolve and is not part of the default configuration file. You will have to add these in yourself.

allow-recursion { any; };
21 allow-query { any; };
22 allow-query-cache { any; };

Start/restart your DNS service for these configuration files to get loaded in. /etc/init.d/bind9 restart and you should be able to ping your newly added entries by host name.

That’s it. You can test these settings for yourself, host -l psa.local will list the hosts in your zone file. I should also note, machines that were already on the network will need to have their DNS configurations adjusted to point to the new DNS server by editing the /etc/resolv.conf file like we did on the server itself. Piece of cake. With local DNS in place it makes things much easier for me to remember, just don’t forget to add new network devices to your zone files when bringing them onto your network.

Setting up an L2TP VPN with pfSense

April 21, 2012August 31, 2015 Josh Reichardt 1 Comment

UPDATE: I think it is important that I inform readers that this guide is strictly for setting up and using L2TP. It has come to my attention that many of you are are looking for a L2TP/IPSec solution, which is currently not supported in PFSense as of the version I am using (2.0.1). I will update this post with full L2TP/IPSec instructions once this functionality has been added in new versions of PFSense.

I’ve been toying around with setting up a home VPN for about a week or so now, which has progressively improved. At first, I had a working VPN implementation with PPTP and life was good. But apparently PPTP is known to be less secure than other methods. So that got me thinking about beefing up my security. Here’s a quick summary I found.

PPTP has been the subject of many security analyses and serious security vulnerabilities have been found in the protocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of the MPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.

After discovering this information I decided to poke around for a little bit to decide what would work the best for me. There were pretty much two options when it came down to setting up my VPN server the way I wanted it. L2TP and OpenVPN. They are both considered secure and from what I’ve read OpenVPN is considered slightly better. The reason I chose L2TP is becuase it is built in to the VPN client on pretty much every OS these days, making client set up and configuration fairly quick and painless (I’m sure its not difficult to set up and use OpenVPN either but I didn’t get that far, maybe I will experiment with it in the future).

There isn’t really all that much to getting things up and going. Open up the pfSense management interface and navigate to the L2TP VPN settings. VPN -> L2TP

Next, we have to configure our settings.

Server address – Use an ip address that doesn’t fall into the subnet that the VPN clients connect to. I used my external IP address to make things easier.
Remote address range – This will be the subnet that VPN clients connect to. I am using the 192.168.2.0/24 subnet.
Subnet mask – I am using the entire subnet so I chose /24.
Number of L2TP users – pretty self explanatory, I have 10 right now for testing purposes.

>I left everything else as the default initially. Here is what the configuration page looked like for me when I got everything working. Remember to change these values accordingly.

Next we need to throw up some user accounts.

So far so good. Now we need to set up some traffic rules for our L2TP clients that connect. This is the absolute most basic method you can go with, so if you have restraints here you will need to adjust these settings.

The last and most important piece to get this working is setting up the firewall rules for the WAN interface. I got stuck at this part and didn’t realize there were two sets of ports that I needed to allow through for things to work correctly. Port 500 for Internet Key Exchange (IKE) UDP traffic and port 1701 for L2TP UDP traffic. Here’s what the rules look like.

That should be it. Try connecting to your VPN server with an endpoint client. I was testing this with my Android phone and had no problems after creating the two firewall rules. Happy VPNing!

Updating Ubuntu (10.04 and up) to use Sun Java

April 14, 2012August 31, 2015 Josh Reichardt 17 Comments

I am in the middle of a home project to build a virtual environment using Proxmox and running into Java issues. Since Proxmox uses java as a VNC console it is necessary to use the correct version (of Java) to access VM’s. By using the wrong version you can cause instability issues and thus bad things to happen.

This is not just a problem with Proxmox either, there are a few other programs and apps that behave poorly with this version of Java, notably for me, Minecraft. Apparently newer versions of Ubuntu have shipped with the OpenJDK version as their default version and in this post I will discuss how to use to the Sun Java 6 version.

Switch to the appropriate directory, in my case I used my home directory and either punch these commands in or copy/past them to get get Ubuntu to see the correct repos.

cd ~/
wget https://raw.github.com/flexiondotorg/oab-java6/master/oab-java6.sh -O oab-java6.sh
chmod +x oab-java6.sh
sudo ./oab-java6.sh

Once this script goes through and does its thing you should have access to the old sun-java6 repos. So to install the correct pieces for Proxmox use apt-get to install the appropriate packages.

sudo apt-get install sun-java6-jre sun-java6-fonts sun-java6-plugin

To set system settings to prefer Sun Java over the OpenJDK version type the following commands:

sudo update-alternatives --set java /usr/lib/jvm/java-6-sun/jre/bin/java
sudo update-alternatives --set javaws /usr/lib/jvm/java-6-sun/jre/bin/javaws
sudo update-alternatives --set mozilla-javaplugin.so /usr/lib/jvm/java-6-sun/jre/lib/*/libnpjp2.so

Now you should have a much more stable experience using Proxmox and the console to take a look at your VM’s! I can’t take the credit for this but I can ease the burden for anybody that comes across this post.

References:
https://github.com/flexiondotorg/oab-java6
http://pve.proxmox.com/wiki/Java_Console_(Ubuntu)