Another motivating factor is my desire to start contributing to the open source community and build some great applications that run in Linux and BSD, especially ones that run in great environments like Gnome, KDE, Xfce, etc.

So I started trying to find a starting point. Loading up main.cpp in vi is an option, and works well, but I want an IDE. Not to mention my only goal isn’t just to bust out daemons and console based tools, I want to create some user friendly software too.

That landed me at the GTK / Qt decision. Knowing that I’ll need the C++ background anyway, which toolkit do I really want to use? I love Gnome (2 that is), and KDE is pretty awesome, so I loaded up Glade and Qt Creator, and Qt Creator sold me instantly. Not only is it a nice IDE to build straight up C++ applications, but it has an awesome form based builder with the power of the Qt SDK, which is eventually where I want to go.

Qt Creator installed like a gem on both my Gentoo Linux system (emerge dev-util/qt-creator) as well as my FreeBSD 9.0 workstation (/usr/ports/devel/qtcreator).

Again I was left with where to start. A quick Google search of “C++ Tutorial for Beginners” brought me to cprogramming.com, which has some great tutorials to get me addicted to the adventure. Digging a bit deeper, I found out the creator, Alex Allain, has a book called Jumping into C++ for 20 bucks which is immediately available for download, which is just what I was looking for. Import it into iBooks on your iPad and it’s awesome. He even recommends a series of books to read if you really want to be an expert which is available at http://www.cprogramming.com/books.html.

I’m off to continue my adventure, it won’t be a super quick one I’m sure. I’ll post back some of my challenges and successes.

Mozilla’s products have revolutionized the way we browse the web and read E-mail in all varieties of operating systems. Their commitment to open source free software is amazing, and more than that, they are all about giving people what they truly want, the power of the web.

A list of Mozilla’s official mirrors can be found at:

http://www.mozilla.org/community/mirrors.html

You can visit our Mozilla mirror directly at:

http://mirror.sdunix.com/mozilla

Nothing screams open source free software louder than GNU and being a part of distributing their software that we all use and love is hopefully a token of how much we appreciate it. I encourage everyone to go to their website to learn more about the software they provide as their hard work often goes unnoticed or gets called by a different name.

Also, it’s pronounced g’noo. GNU stands for “GNU’s Not Unix!”.

Our mirror is listed on the GNU Mirror List at:

http://www.gnu.org/prep/ftp.html

To access the mirror directly, visit:

http://mirror.sdunix.com/gnu

http://mirror.sdunix.com/apache

Being a part of distributing software from the Apache Software Foundation is an honor. Knowing that I’m helping distribute software that powers a large percent of websites all around the world is something I’m proud to be apart of.

A full listing of mirrors for the Apache Software Foundation can be found at http://www.apache.org/mirrors.

Learn more about the Apache Software Foundation at http://www.apache.org.

Today, I don’t have native IPv6 connectivity, but using Hurricane Electric’s Tunnel Broker service, my networks talk to IPv6 hosts seamlessly and performance and stability is impressive.

The setup I detail here was performed on a FreeBSD 9.0-RC2 installation with a standard residential cable modem connection.

Educate Yourself

The first thing you should do is read all about IPv6. There are tons of good articles and resources on the web that help you understand all about it. There are LOTS of great resources at tunnelbroker.net and they also have a FREE certification program that tests what you have learned and lets you ensure your IPv6 connectivity is implemented properly. The FreeBSD handbook also has a nice IPv6 which is available at:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html

I suggest you do a lot of reading and get comfortable with the concepts. As you setup your tunnel in FreeBSD, it will all come together.

Create a Tunnel Broker Account

The first thing you need to do is create an account at tunnelbroker.net. Registration is quick and free. You can setup up to 5 tunnels each with a routed /64 and /48.

Create a New Regular Tunnel

You’ll need to create a new tunnel once you have logged into tunnelbroker.net. On the left hand menu, you’ll see an option to “Create Regular Tunnel”. The first thing you will need to enter is your FreeBSD router’s public IP address, which must be reachable via ICMP. Once you put in your public IP address, it will run a check to make sure it is reachable and eligible to be a tunnel endpoint. If ICMP is being blocked, it will inform you of which remote address requires the ability to reach your public IP address via ICMP so that you may configure your firewall appropriately. It will also automatically recommend a remote endpoint for your tunnel based on your location.

Once your tunnel is created, you’ll be able to see both endpoints configuration as well as the /64 that was assigned to you. A /48 isn’t automatically assigned, so if you require this, click on “Assign /48″. Here is what my tunnel configuration looks like at tunnelbroker.net:

The server and client addresses are used in the FreeBSD GIF(4) tunnel that you will create, and the routed /64 are the addresses that you will be able to assign out to devices on your network.

Configure the Tunnel in FreeBSD

Now that the tunnel is created at tunnelbroker.net, you can configure the GIF(4) interface on your FreeBSD router. Of course, you don’t have to configure the tunnel at the router, but it’s the easiest place to configure it and extend the IPv6 connectivity to the rest of your network. Here is what I added to /etc/rc.conf which will enable IPv6 and configure the gif0 interface at boot:

ipv6_activate_all_interfaces=”YES”
ipv6_gateway_enable=”YES”
gifconfig_gif0=”68.228.214.44 66.220.18.42″
ifconfig_gif0_ipv6=”inet6 2001:470:c:12f4::2 2001:470:c:12f4::1 prefixlen 128″
ipv6_defaultrouter=”2001:470:c:12f4::1″

After rebooting, you will see a newly create interface called gif0 that should look something like:

gif0: flags=8051metric 0 mtu 1280
tunnel inet 68.228.214.44 –> 66.220.18.42
inet6 fe80::222:3fff:fef1:ee91%gif0 prefixlen 64 scopeid 0xb
inet6 2001:470:c:12f4::2 –> 2001:470:c:12f4::1 prefixlen 128
nd6 options=21 options=1

Firewall Configuration

My first instinct was to ping the remote endpoint’s IPv6 address using ping6 to see if its working, but it timed out. I quickly realized I needed to allow the new setup through my firewall before it would function. IPv6 traffic will need to be configured in the firewall just as IPv4 does. I utilize PF for my firewall and added the following to /etc/pf.conf, which enables ICMP on the new gif0 interface so I can test connectivity using ping6:

pass quick on gif0 proto icmp6 all keep state

After issuing a pfctl -f /etc/pf.conf to reload my rules, I was able to use ping6 to ping the remote endpoint’s IPv6 address:

PING6(56=40+8+8 bytes) 2001:470:c:12f4::2 –> 2001:470:c:12f4::1
16 bytes from 2001:470:c:12f4::1, icmp_seq=0 hlim=64 time=25.047 ms
16 bytes from 2001:470:c:12f4::1, icmp_seq=1 hlim=64 time=22.629 ms
16 bytes from 2001:470:c:12f4::1, icmp_seq=2 hlim=64 time=21.922 ms

— 2001:470:c:12f4::1 ping6 statistics —
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 21.922/23.199/25.047/1.338 ms

I also used ping6 to ping www.freebsd.org and ipv6.google.com and was also successful. At this stage, your router will have connectivity to the IPv6 world.

Enable IPv6 Connectivity on Entire Network

Now that your router is IPv6 aware, you can extend IPv6 connectivity to your entire network. Each device on your network can be configured with an address in your routed /64 and then talk to other IPv6 hosts. This is where you have to start thinking outside of the box. We’re all used to DHCP and NAT, but IPv6 doesn’t necessarily work the same way. While DHCP can still be used with IPv6, it doesn’t have to be, and NAT doesn’t need to be used because addresses assigned from your /64 to devices on your network are publicly routed addresses. For this reason, you should ensure you firewall is filtering traffic according to your security policies so that devices obtaining IPv6 addresses aren’t all of a sudden open on the Internet. Based on the PF rule we defined above, only ICMP would be enabled on any device behind the router that receives an IPv6 address.

The first thing you need to do is configure your internal network interface with an IPv6 address from your routed /64. This enables devices that are behind the router to connect through the internal network interface, and then through gif0. The address you assign to the internal interface becomes the default gateway for IPv6 hosts behind the router. My internal interface is re1, and I added the following to /etc/rc.conf:

ifconfig_re1_ipv6=”inet6 2001:470:d:12f4::1″

Now you have two options… You can statically assign IPv6 configurations to your devices that are behind the router, or you can configure your devices to automatically get its IPv6 configuration by configuring the router to advertise available IPv6 addresses using rtadvd. To do so, add the following to /etc/rc.conf:

rtadvd_enable=”YES”
rtadvd_interfaces=”re1″

You can start the rtadvd daemon by issuing the command /etc/rc.d/rtadvd start. When bringing up an IPv6 enabled device on your network, it should be automatically configured with IPv6 connectivity. You can test IPv6 connectivity on your hosts being using ICMP, or by visiting websites that are only IPv6 enabled, such as ipv6.google.com. Other sites, like ipv6.he.net, will show you the remote address that is being used. If a host is configured with both an IPv4 and IPv6 address, IPv6 will usually be used first, and then IPv4 if that fails. That behavior is dependent on the client, but is generally followed.

Conclusion

At this point you should have an IPv6 enabled router that allows network devices behind it to communicate with IPv6 hosts on the Internet. I challenge you to make this only the start of your IPv6 adventure. Complete the IPv6 certification which will force you to learn about DNS, Reverse DNS, and utilizing IPv6 in real life scenarios. Contact your local ISP and find out when IPv6 connectivity will be available. Learn how IPv6 should be secured in your firewall. After your done, you’ll feel good knowing your prepared for the IPv6 era.

The FreeBSD handbook also has some good information about this setup and can be found at the following link:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html

Also notice that I’ve got one endpoint running a production release of FreeBSD, and another running a release candidate version. I did this intentionally to catch and variances that could possibly exist between then two major releases, and didn’t find anything specific.

NOTE: Anytime there are FreeBSD options that are the same for both endpoints, I will only show the examples once. For configuration items that are different on each endpoint, I will show examples for each endpoint.

Initial IP-IP Tunnel Configuration

Before worrying about the IPsec component, I needed to make sure that raw unencrypted connectivity was in place. The easiest way to do this was to setup an IP-IP tunnel using the GIF(4) interface. I’ve detailed the setup of both endpoints below. The 192.168.0.0 network will be used to represent public IP addresses, and the 172.16.0.0 network will be used to represent internal IP addresses. You’ll also notice I’ve included the static routes that need to be in place so that each endpoint can access the other endpoint’s network. I’ve configured this in /etc/rc.conf which will persist the configuration after a reboot.

Endpoint 1 – FreeBSD 9.0-RC2

ifconfig_re0=”inet 192.168.1.1  netmask 255.255.255.0″ # PUBLIC ADDRESS
ifconfig_re1=”inet 172.16.1.1 netmask 255.255.255.0″ # INTERNAL ADDRESS
gif_interfaces=”gif0″
gifconfig_gif0=”192.168.1.1 192.168.2.1″
ifconfig_gif0=”inet 172.16.1.1 172.16.2.1 netmask 255.255.255.0″
static_routes=”vpnroute”
route_vpnroute=”-net 172.16.2.0/24 172.16.2.1″

Endpoint 2 – FreeBSD 8.2-RELEASE-p4

ifconfig_re0=”inet 192.168.2.1 netmask 255.255.255.0″ # PUBLIC ADDRESS
ifconfig_re1=”inet 172.16.2.1 netmask 255.255.255.0″ # INTERNAL ADDRESS
gif_interfaces=”gif0″
gifconfig_gif0=”192.168.2.1 192.168.1.1″
ifconfig_gif0=”inet 172.16.2.1 172.16.1.1 netmask 255.255.255.0″
static_routes=”vpnroute”
route_vpnroute=”-net 172.16.1.0/24 172.16.1.1″

After configuring the above and rebooting, the gif0 interfaces were created. I tried pinging endpoint 1 from endpoint 2 without success, which was expected as I hadn’t yet allowed the traffic through the firewall.

Configuring the Firewall

I implement a “block all by default” firewall, so by default the traffic wasn’t allowed, including ICMP. The configuration below was pulled directly out of the VPN over IPsec handbook page. I use PF for my firewall, you’ll need to adapt this to your setup. Note that the rules below not only apply to the IP-IP tunnel, but also the IPsec implementation.

pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto ipencap from any to any
pass in quick proto udp from any port = 500 to any port = 500
pass in quick on gif0 from any to any
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto ipencap from any to any
pass out quick proto udp from any port = 500 to any port = 500
pass out quick on gif0 from any to any

After reloading my firewall rules on both endpoints, I was able to successfully ping each endpoint’s internal IP address.

Securing the Tunnel w/ IPsec and Racoon

Now that we have created a network configuration that enables connectivity between the endpoint’s internal networks, we must encrypt the traffic. Skipping this step would mean that all traffic crossing the tunnel would be insecure (unless secured by other means). FreeBSD implements IPsec in its kernel, and along with the security/ipsec-tools port, you can encrypt all traffic that is sent through the tunnel.

Kernel Configuration

IPsec must be configured into the FreeBSD’s kernel configuration file, and he kernel must be rebuilt. I added the following option and device to my kernel’s configuration file, rebuilt, installed, and rebooted.

options   IPSEC        #IP security
device    crypto

The FreeBSD handbook also mentions the use of the IPSEC_DEBUG option, but I chose not to compile this into the kernel.

Security Policies

IPsec security policies must be defined and set to load into the Security Policy Database (SPD). This enables FreeBSD and racoon to encrypt / decrypt traffic between the two endpoints. The rules can be defined in a text file, then loaded at boot. I kept my policies in /usr/local/etc/racoon/setkey.conf and the file contained the following:

Endpoint 1:

flush;
spdflush;
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec esp/tunnel/192.168.1.1-192.168.2.1/use;
spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/192.168.2.1-192.168.1.1/use;

Endpoint 2:

flush;
spdflush;
spdadd 172.16.2.0/24 172.16.1.0/24 any -P out ipsec esp/tunnel/192.168.2.1-192.168.1.1/use;
spdadd 172.16.1.0/24 172.16.2.0/24 any -P in ipsec esp/tunnel/192.168.1.1-192.168.2.1/use;

I added the following to my /etc/rc.conf on each endpoint which tells FreeBSD to enable IPsec and load the policies into the SPD:

ipsec_enable=”YES”
ipsec_file=”/usr/local/etc/racoon/setkey.conf”

After running /etc/rc.d/ipsec start, I could view the SPD  by issuing the setkey -DP command to ensure the policies were loaded properly.

Configuring Racoon

At this stage, we have IP-IP connectivity configured and tested, IPsec has been compiled into the kernel, and the IPsec security policy database contains the policies loaded from the setkey.conf file. Now we must configure the racoon IKE key management daemon. First, you’ll need to make sure your ports are up to date and install security/ipsec-tools:

cd /usr/ports/security/ipsec-tools
make install clean

After the port installs, you’ll first want to copy the racoon sample configuration file into place, and create a psk.txt file that will contain the pre-shared key that will be used during racoon’s negotiation process, and set the owner / permissions appropriately:

cp /usr/local/share/examples/ipsec-tools/racoon.conf.sample /usr/local/etc/racoon/racoon.conf
touch /usr/local/etc/racoon/psk.txt
chown root:wheel /usr/local/etc/racoon/psk.txt
chmod 600 /usr/local/etc/racoon/psk.txt

Edit the /usr/local/etc/racoon/psk.txt file. It should contain the remote endpoint’s public IP address and a unique password:

Endpoint 1:

192.168.2.1 SomeMadeUpPassword

Endpoint 2:

192.168.1.1 SomeMadeUpPassword

Next, the racoon.conf file needs to be edited. There are many options to this file, and it’s probably best to learn all about it via the racoon.conf(5) man page. That being said, the one below is based on a lot of what I’ve found on the web, and works really nicely for me.

Endpoint 1:

# $KAME: racoon.conf.sample,v 1.28 2002/10/18 14:33:28 itojun Exp $

path include “/usr/local/etc/racoon” ;
path pre_shared_key “/usr/local/etc/racoon/psk.txt” ;
log debug;

padding # options are not to be changed
{
maximum_length 20; # maximum padding length
randomize off; # enable randomize length
strict_check off; # enable strict check
exclusive_tail off; # extract last one octet
}

listen # address [port] that racoon will listening on
{
isakmp 192.168.1.1 [500];
}

timer # timing options. change as needed
{
counter 5; # maximum trying count to send
interval 20 sec; # maximum interval to resend
persend 1; # the number of packets per a send
phase1 60 sec;
phase2 25 sec;
}

remote 192.168.2.1 [500]
{
exchange_mode aggressive,main;
doi ipsec_doi;
situation identity_only;
lifetime time 8 hour;
initial_contact on;
passive off;
proposal_check obey;
generate_policy off;

proposal {
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 5;
}

}

sainfo anonymous
{
pfs_group 5;
lifetime time 12 hour ;
encryption_algorithm blowfish,3des,des;
# authentication_algorithm hmac_md5,hmac_sha1;
authentication_algorithm hmac_sha1;
compression_algorithm deflate ;
}

Endpoint 2:

# $KAME: racoon.conf.sample,v 1.28 2002/10/18 14:33:28 itojun Exp $

path include “/usr/local/etc/racoon” ;
path pre_shared_key “/usr/local/etc/racoon/psk.txt” ;
log debug;

padding # options are not to be changed
{
maximum_length 20; # maximum padding length
randomize off; # enable randomize length
strict_check off; # enable strict check
exclusive_tail off; # extract last one octet
}

listen # address [port] that racoon will listening on
{
isakmp 192.168.2.1 [500];
}

timer # timing options. change as needed
{
counter 5; # maximum trying count to send
interval 20 sec; # maximum interval to resend
persend 1; # the number of packets per a send
phase1 60 sec;
phase2 25 sec;
}

remote 192.168.1.1 [500]
{
exchange_mode aggressive,main;
doi ipsec_doi;
situation identity_only;
lifetime time 8 hour;
initial_contact on;
passive off;
proposal_check obey;
generate_policy off;

proposal {
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 5;
}

}

sainfo anonymous
{
pfs_group 5;
lifetime time 12 hour ;
encryption_algorithm blowfish,3des,des;
# authentication_algorithm hmac_md5,hmac_sha1;
authentication_algorithm hmac_sha1;
compression_algorithm deflate ;
}

Starting Racoon

Now that everything is in place, you’ll want to add racoon to start at boot in /etc/rc.conf, and then start it on both sides to and check to make sure the negotiation was successful. I found the best way to do this is to add the configuration lines to each endpoint’s /etc/rc.conf, then start racoon and review the SAD tables and racoon log files. First add the lines to /etc/rc.conf:

racoon_enable=”yes”
racoon_flags=”-l /var/log/racoon.log”

Start racoon on each host:

/usr/local/etc/rc.d/racoon start

After starting racoon, ping endpoint 2′s internal IP address from endpoint 1, this will get the negotiation process under way if it’s not already. There are two ways to validate that the negotiation was successful. The first is to review the /var/log/racoon.log file and check for signs of success. You should see something like:

2011-11-21 12:15:16: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.1[500]->192.168.2.1[500] spi=56832670(0x363329e)

The other way is to use setkey to dump the SAD tables, which will only exist if the IPsec negotiation was successful:

setkey -D

You should see output displaying the encryption algorithms that are being used, as well as other information.

Validating Encryption

Before you can sleep at night knowing your VPN is secure, you should run some simple tests to make sure traffic is being encrypted. tcpdump is a good way to do this. On one endpoint, or both, use tcpdump to dump the public interface’s traffic and look to make sure you see ESP records:

tcpdump -n -i re0 host 192.168.1.1 and dst 192.168.2.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:51:29.800977 IP 192.168.1.1 > 192.168.2.1: ESP(spi=0x0693d993,seq=0×7), length 116
18:51:31.713245 IP 192.168.1.1 > 192.168.2.1: ESP(spi=0x0693d993,seq=0×8), length 116

If encryption isn’t working place, you’ll see something more along the lines of:

18:56:47.315538 IP 192.168.1.1.63035 > 192.168.2.1.22: Flags [F.], seq 0, ack 41, win 913, options [nop,nop,TS val 160362725 ecr 375854087], length 0

Conclusion

If everything has gone to plane, you should have a secure IPsec VPN tunnel between to FreeBSD endpoints. Though this setup is slightly more complex, I prefer it over other VPN methods when it’s relating to a permanent VPN.

Once nice thing about the tunnel method is the interface that the tunnel is created on, in our case gif0, can be worked with just like any other interface. Traffic graphs can be generated showing just VPN traffic using SNMP and Cacti. Firewall rules can clearly be defined at the interface level. Best of all, everything can be automated at boot using standard rc.conf variables.