IPv6 might not be quite here yet, but it's coming; here's how to get ahead of the familiarity curve now by building your own lab Note: This is part one of two; the second part will be posted next week. No matter what your position in IT might be, you’re probably pretty darn familiar with IPv4. You can’t configure the first thing on a network today without at least having some basic idea how subnet masks, default gateways, and DNS allow the network to function. If you’re tasked with day-to-day management of a larger network, you may be very familiar with a whole slew of deeper info, such as how to set up DHCP to autonumber workstations, perform more complex subnetting, and configure dynamic routing protocols. For better or for worse, everything you’ve learned about IP throughout your career is about to change. The IANA issued its last /8 block of IPv4 addresses earlier this month. The Regional Internet Registries are on pace to run out of smaller blocks to assign to ISPs and corporations within a year or so. Many ISPs have done a good job planning ahead and have a lot of space on hand, but it can’t last forever. It’s not an issue of whether IPv4 address space exhaustion will force you to get on the IPv6 bandwagon, but when. If you haven’t yet, there’s no time like the present to start getting your feet wet. Wrapping your mind around IPv6 now is the best defense against being caught flat-footed before it’s inevitably crammed down your throat. One of the cheapest and most educational ways to do this is to build yourself a lab with free software and cheap discarded hardware. Here’s how I recently built an IPv6-capable router/firewall in a few hours with junk lying around my office. What you’ll need to get started First off, you’ll need a piece of hardware. Anything with a pair of network interfaces will do. In my case, I had an old P4 pizza box-style server with a single hard drive kicking around that fits the bill, but you can get by with just about anything that has 4GB of drive space and a pulse (a CD-ROM drive will make things easier, but isn’t strictly necessary). For my purposes, I wanted something I could easily attach directly to a subscriber-grade Internet connection, so I didn’t pursue using a VMware host, but that’s also an option if you have one available to you. Next, you’ll need a good operating system. There are lots and lots of ways to do this. In my case, I chose to use Vyatta Core (the free, community supported version of Vyatta Enterprise). Vyatta is a commercially maintained Linux distribution (based on Debian Linux) that draws together a raft of different open source networking packages and unites them under a common management framework. One of the features that makes Vyatta a great choice for a lab/educational tool is its thorough support for IPv6 and a wide variety of routing protocols, including OSPF and BGP. To be sure, you can do everything that Vyatta does with pretty much any major Linux distribution, but Vyatta has already done a lot of the work for you. Getting Vyatta installed In my case, getting Vyatta installed was a bit more complicated than it might be for most. Vyatta is distributed in a few different formats, including a Live CD image that you can burn to a disc and a ready-made VMware appliance. Unfortunately, I’m not using VMware, and the box I wanted to install Vyatta on doesn’t have a CD-ROM. However, it’s fairly easy to slap together an installer that will run off a USB thumb drive. If you’re in that boat, there are some old but still accurate instructions on the Vyatta forums (a great resource if you get stuck). Once you have your boot media — either a CD-ROM or a flash drive — ready to go, you can boot up your machine and get started. It’s important to realize that what you’re actually booting isn’t strictly an installer — it’s a fully functional Vyatta environment. To burn that environment onto permanent storage, such as a hard drive or a CompactFlash card, so that you can save your configuration easily, you’ll need to log in (both the username and password are “vyatta”) and run the install-system command. That will run you through a few basic options about whether to enable software RAID (if you have more than one hard drive you want to mirror) and what disk configuration to use. If you’re not sure, you can generally accept the defaults on just about everything. Once the installer has done its job, you can shut down the machine, remove the media, and turn it back on. If all went well, you should be presented with another login prompt. Covering the basics To get into configuration mode, you’ll need to enter the configure command. When you’re done inputting a series of commands, you’ll tell Vyatta you want to actually make them active by running commit. If you want to make them permanent, you can type save. Once you’re done with configure mode, you can type exit to drop you back out to where you can run commands like show configuration cmds, which will dump out the entire saved configuration so you can review it. The first thing I did was get the Vyatta router configured so that I could access it over the network. As I am lazy, typing into a CLI from a real console with no copy and paste is a real drag for me. To that end, there are a few things you’ll probably want to do right off the bat. IPv4 on the inside First, you’ll want to give your router an IPv4 address on its inside interface. In my case, I had two Ethernet interfaces: One that I wanted to use for my outside (eth0) connection, and one that I wanted to use on the inside (eth1). Setting up the outside comes later once we have some firewall rules in place to protect it: set interfaces ethernet eth1 address '192.168.1.1/24' I also wanted to enable SSH (console) and access to the HTTPS Web interface: set service 'https' set service ssh port '22' set service ssh protocol-version 'v2' And set a hostname for the system: set system host-name 'ipv6-test-router' set system domain-name '<your domain name>' As I was attaching this router to its own switch, I also needed to configure a DHCP server so that I’d be able to get an IP when I plugged a laptop in. This block will turn on the IPv4 DHCP service on the inside interface and configure it to advertise itself as the default router and DNS server: set service dhcp-server disabled 'false' set service dhcp-server shared-network-name POOL1 authoritative 'disable' set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 default-router '192.168.1.1' set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 dns-server '192.168.1.1' set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 domain-name '<your domain name>' set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 lease '86400' set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 start 192.168.1.100 stop '192.168.1.199' After you’ve committed and saved that, you should be able to attach the inside interface to a switch, plug in a workstation, and get an IP. It might take a bit of trial and error to figure out which physical NIC on the machine is eth1 — using the the show interfaces ethernet command can help with figuring out which link Vyatta believes is plugged in. Once you have an IP, you can fire up a Web browser or SSH client and connect to the eth1 IP address. In my case, I used the CLI for the whole thing, so firing up PuTTY from my aged Windows XP laptop was the easiest way to get it done. IPv4 on the outside The next job is to get access to the IPv4 Internet. In my case, the Internet connection was a fairly standard subscriber-grade cable Internet connection that uses DHCP for address assignment. If you’re using a DSL connection that uses PPPoE, you’ll need a slightly different config (check the Vyatta forums for examples). The next few blocks of configuration deal heavily with securing the router from the Internet. I can’t stress enough how careful you should be with this if you intend to have real systems behind this firewall. If you choose this route, make sure you understand what every command I use here does so that you know the implications of setting them. Vyatta is tremendously flexible, allowing you to set firewall rules that only trigger at certain times of day, perform traffic shaping, and support fairly complex zone-based firewalling configurations. This config reflects the simplest of the simple. If you want to learn more about what you can do, check out the Vyatta documentation. First is a rule set that will allow return traffic initiated from the router itself to return to it. It will also allow ICMP ping requests to come into the router’s outside interface (you’ll need that ability later when you configure an IPv6 tunnel): set firewall name out-local default-action 'drop' set firewall name out-local description 'IPv4 Traffic To Router' set firewall name out-local rule 10 action 'accept' set firewall name out-local rule 10 description 'Accept Established-Related' set firewall name out-local rule 10 state established 'enable' set firewall name out-local rule 10 state related 'enable' set firewall name out-local rule 15 action 'accept' set firewall name out-local rule 15 description 'Accept ICMP Echo' set firewall name out-local rule 15 icmp type '8' set firewall name out-local rule 15 protocol 'icmp' Next, pretty much the same rule that will apply to return traffic that originated from the inside network: set firewall name out-in default-action 'drop' set firewall name out-in description 'IPv4 Traffic To Internal' set firewall name out-in rule 10 action 'accept' set firewall name out-in rule 10 description 'Accept Established-Related' set firewall name out-in rule 10 state established 'enable' set firewall name out-in rule 10 state related 'enable' Now, apply both of those rules to the eth0 (outside) interface: set interfaces ethernet eth0 firewall in name 'out-in' set interfaces ethernet eth0 firewall local name 'out-local' Throw in some fairly standard global firewall configuration (allowing the router to respond to ICMP pings and disabling some commonly abused and/or unnecessary IP features): set firewall all-ping 'enable' set firewall broadcast-ping 'disable' set firewall conntrack-tcp-loose 'enable' set firewall ip-src-route 'disable' set firewall ipv6-receive-redirects 'disable' set firewall ipv6-src-route 'disable' set firewall log-martians 'enable' set firewall receive-redirects 'disable' set firewall send-redirects 'enable' set firewall source-validation 'disable' set firewall syn-cookies 'enable' Then configure NAT to translate the inside addresses on the eth1 interface to the interface address of the outside interface: set service nat rule 10 outbound-interface 'eth0' set service nat rule 10 source address '192.168.1.0/24' set service nat rule 10 type 'masquerade' Next up, configure the router to proxy DNS requests to an internet-based DNS server (in this case, I’ve used Google Public DNS services because my ISP fiddles with their DNS servers to deliver ads more than I like, but you can use any public DNS service, such as OpenDNS, if you’re not a fan of Google): set service dns forwarding cache-size '150' set service dns forwarding listen-on 'eth1' set service dns forwarding name-server '8.8.8.8' set service dns forwarding name-server '8.8.4.4' Configure DNS for the router itself (so that you can ping things by name): set system name-server '8.8.8.8' set system name-server '8.8.4.4' Finally, configure the outside interface to grab an IP from the ISP: set interfaces ethernet eth0 address 'dhcp' Once you’ve committed all of that, you should be able to browse the Web from your workstation. Hooray! Now that we have IPv4 working, it’s time to move on to IPv6! This article, “Build your own IPv6 lab on the cheap, part 1,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter. Technology IndustryApp Testing