It's official, I am failing at my New Year's resolutions.  I was supposed to blog and tweet more while simulaneously posting on Facebook less often.  It turns out I've been neglecting them all fairly equally, unfortunately.  Anyway, a few topics and updates are below!

Networking Virtualzation

Over the past several months I've been using VirtualBox more extensively, specifically VBoxHeadless.  I first started using it because it seems to be the only hypervisor for FreeBSD that can take advantage of hardware acceleration with VT-x/AMD-V.  I've now got four virtual machines running on dax, including a Cisco ASA (it runs great!) so I can play with some stuff.  On other systems where I have the option of KVM or VMware, I've started using VirtualBox due to the multitude of system and networking options (the VBoxManage syntax seems to go on without end!).

I also recently converted part of my lab network to VirtualBox from VMware Server 2.0.  I only converted my end hosts and an x86 RouterOS box, the rest of the IOS and Junos instances stayed the same (Dynamips and KVM, respectively).  Anyway, it was certainly an upgrade I was long due for.  VMware Server was really a pain in the rear since the console requires the use of a web browser running on Windows.  I ended up flattening the VMDK files first and then converting them to VDI files using the clonehd function of VBoxManage.

The only snag I've found so far with VirtualBox is its lack of coexistance with KVM.  VirtualBox just doesn't work with KVM, where VMware Server did just fine.  Sure, I could use Qemu with KVM but it's dog slow.  A sufficient workaround is to disable hardware virtualization for the VirtualBox instances so it won't conflict with KVM.  I did this with the following:

VBoxManage modifyvm myvn --hwvirtex off

This doesn't really slow things down too much.  In fact, I haven't really noticed it at all.  One thing it does do is prevent the use of 64-bit guests, which is a bummer.  I had to reinstall one of my FreeBSD VMs, as a result.

IPv6 Multicast Issues

I've finally started to nail down a weird IPv6 Wi-Fi issue I've been having for several months (maybe years?) with at least three different WAPs.

All IPv6 address configuration on my home network is SLAAC, at the moment, and Wi-Fi authentication is WPA2-PSK.  Over time Wi-Fi clients will randomly lose their IPv6 default route or EUI-64 addresses.  This happens across a variety of operating systems, it's not limited to one particular OS or platform.  On Linux I have tried using the rdisc6 (part of the ndisc6 package in Debian and Ubuntu distributions) to force the upstream router to send a router advertisment message.  This would never work after the problem started happening and the solution is always to bounce the Wi-Fi interface on the client, which seems to work every time.

Today I ran some tcpdumps and verified that the router advertisement messages were being seen by wired clients on the same VLAN, but not the Wi-Fi clients.  On my Cisco 1142 WAP I started clearing things until I got to "clear interface dot11radio*" and things started working again.  It appears the wireless interfaces on my WAP are eating IPv6 neighbor advertisement messages (sent to ff02::1 - all clients, with a multicast MAC of 33:33:00:00:00:01) but NOT neighbor solicitation messages (sent to ff02::2 - all routers, with a multicast MAC of 33:33:00:00:00:02).  I'd initially say that this is a Cisco bug related to the IOS version that's on the WAP, currently 12.4(23c)JA, but since this problem has been exhibited on two other WAPs (a Cisco 1200 and a NETGEAR WAG102) over time, I'm now wondering if it's a WPA2 group re-key issue or something like that since it only seems to affect multicast.  It's very specific about the addresses though, which is puzzling.

More research is obviously needed, but I figured I'd throw this out there just in case anyone has the same issue.  At least I can remotely coax clients back online via IPv6 by just SSHing to the WAP and issuing clear commands.  I suppose I could setup a script to just clear the interfaces every morning at 04:00, although that reminds me of a story about some systems guys somewhere rebooting SMTP servers nightly due to a memory leak in sendmail.  Yuck.

IPv6 and NAT

I need to dedicate a whole blog entry for this, I think.  Essentially, I'm sick of folks being violently opposed to NAT and PAT implementations for IPv6.  I'm also starting to think that NAT and PAT can be classified as security tools.

Warning, don't take the below text too seriously.  Well, you can, because I am mostly serious about it, but do so at your own risk!

NAT and PAT are mostly used for IPv4 because hardly anyone has enough public IPv4 space for all of their internal networks.  In this case, NAT and PAT are used for Internet access.  They're also used for things like server load balancing, back-end business to business connectivity, and numerous cases where changing routing is just not possible.  Some of these same situations exist in IPv6 and I believe NAT and PAT can also be applied in these situations.  Should they be the first thing on the list?  No, but their use should not be discounted for some silly religious purity.  They are a tool, nothing more.  Folks can choose to use them if they want, or not use them if they can make do without them.

Let's take a simple case.  Verizon Wireless provides an IPv6 /64 along with an IPv4 NET-10 address to each client on their LTE network.  The Mi-Fi devices and Internet connection sharing software on handsets usually use NAT and PAT to share the IPv4 connectivity (ultimately double natted due to CGN).  The IPv6 /64 is not well suited to Internet connection sharing because it exists on the cellular interface, not on the Wi-Fi interface (or whatever medium is used for client connectivity).  There are a few options for this including NPTv6 and PAT.  I have heard folks specifically say they would rather wait and petition Verizon Wireless to support PD than use any type of NAT over IPv6.  Yeah, like that's going to happen any day.  Really, it sounds like using NAT for IPv6 in this situation might cause widespread famine and disease.  It's a little silly.

Now, let's talk about NAT as a security tool.  Very simply, it's not a security tool, but it can assist in securing networks and provide some security through obscurity.  For example, take a residential router that runs a single iptables command on Linux:

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

If you know iptables, this is a simple one.  The above command causes iptables to translate all packets sourced from 192.168.1.0/24 and routed out eth0 to whatever IPv4 interface is bound to eth0.  It activates NAT and PAT.  Now, assume the rest of the iptables chains in the filter table (INPUT, OUTPUT, and FORWARD) are all set to their defaults, which is ACCEPT.  We now have a router performing NAT and PAT (with connection tracking) but no actual firewalling.  The box is wide open.  However, this does provide some security, because folks on the Internet can't easily establish a new TCP connection with a Linux box at 192.168.1.100 on port 22 (SSH).  Why?  192.168.1.0/24 is not routed on the Internet.  Can you perform other tricks to get this type of access?  Sure, but it takes more effort.  NAT and PAT here provide a little bit of security.  Although, maybe one can say that the security is there to begin with (in the form of routing, or lack there of).  NAT and PAT just allow connectivity in one direction where no connectivity exists without them.

Now, how about security through obscurity?  It's simple.  Hiding a bunch of IPv4 or IPv6 addresses behind one single address, using NAT and PAT to translate all connections.. it obscures the real addresses!  Sure, RFC 4941 obscures source addresses, too, and so do proxy servers.  NAT and PAT used together is just another option for this and does, in my opinion, provide this type of protection (if you want to call it protection).  Semantics?  Maybe!

Unfortunately, this is not the first time I've talked about IPv6 and NAT.  I did it first back in early 2011.  I didn't really mention its use as a security tool, though.

What do you think?  Drop a comment, but be nice.

New comments are currently disabled for this entry.