Even for the extremely ungeeky, having WiFi available throughout your house is pretty much standard these days. And while the next logical step of securing that network via encryption (WEP is for n00bs — those in the know use WPA2-AES) may not be standard, it really should be. Assuming you do have a WiFi password at your house, the notion of freely sharing your WiFi password anyone who shows up at your house is so 2009. If you truly want to bring your geeky hospitality to a whole new level, it’s time to consider setting up a “guest-only” network for your wireless router.

A number of modern wireless routers come with out-of-the-box support for guest networks, but still limit the amount of control you have in configuring them. As a long-time user of “hacked” third-party open source router firmware (such as Tomato and DD-WRT), the ability to run those firmwares is an essential requirement when I purchase a router, and the installation of an open source firmware is the first thing I do when I take it out of the box.

Doing the things I’m describing in this post requires that a semi-recent build of DD-WRT be running on your wireless router. If you don’t know what DD-WRT is, find your resident geek and ask them if installing it on your router is even an option (it will only work on certain hardware). Keep in mind that installing third-party firmware improperly and/or on unsupported hardware can “brick” your router (i.e. make it as useful as a brick), so rookies should study up big time by reading the appropriate wiki entries and threads on the DD-WRT website before trying it for the very first time. Seriously. Please don’t comment on this article that “I” ruined your router because you didn’t RTFM. So now that my conscience is clear, let’s proceed. 🙂

Rather than re-post the instructions for getting a 2nd WiFi network running at your house, I’ll simply refer you to the instructions on the DD-WRT website. The process is called setting up a 2nd WLAN (Wireless Local Area Network).

Setting up multiple WLANs in DD-WRT

At our house, I set up a “private” WiFi network for immediate family members only, which requires a password that we don’t share with anyone else. This allows family members to access shared network resources (both wired and wireless) in the house, such as printers, NAS media storage devices, security cameras, DVRs, home automation tools, AirPlay-capable audio devices, AppleTV, etc.

Additionally, I’ve set up a “public” WiFi network for guests to use, and which doesn’t require any password. With two separate networks, I can configure separate sets of rules to make things more usable and secure across both networks. For example, I’ve configured QoS (Quality of Service) settings that give bandwidth priority to the private network — meaning that if I’m trying to watch something on Netflix at the same time one of my guests is trying to download a huge file, my Netflix experience is unaffected while they’ll have to wait a bit longer for their file. I’ve also applied a number of firewall rules to my guest network so that guests can’t access the network resources on my private network, nor than they run network scans to try and discover the IP addresses or MAC addresses of network devices. Want to try that the next time you’re connected to a public network? Download the free Fing app onto your iPhone or Android device and see what kind of data you can collect at the click of a button. It’s downright scary.

But perhaps the ability I appreciate the most is the option to to block access to certain remote resources for those on the guest network, such as Skype. As an example, let’s take a completely hypothetical situation. Let’s assume that your wife’s sister’s family, who recently moved from Seattle to Casper, Wyoming, is driving to meet you at your vacation home in Utah, where four adults and eight kids will all spend their Christmas and New Year’s vacation together. Let’s also assume that your 17-year old nephew has his very first girlfriend, but that she still lives back in Seattle, and that those crazy kids spend hour… after hour… after hour… on their smart phones logged in to Skype — and sometimes they just stare at each other and don’t even talk. It’s hypothetically creepy. Then again, let’s assume that sometimes they do talk… for hours… and hours… even past midnight when the nephew should be sleeping, and let’s further assume that he’s sharing your son’s bedroom, which is directly below yours, and that his late night Skype marathons are keeping you, your wife, and your son awake late into the night, which makes you grumpy in the morning. Like I said — completely hypothetical.

With most applications, the solution would be easy. Just go into your router’s firewall and shut down the ports used by the application that you want to block. But because Skype uses ports 80 and 443, which are the standard ports used by nearly every website on the Internet, shutting those ports down would essentially mean shutting down access to the entire web for all users on the guest network… which kind of defeats the purpose of having a guest network in the first place. To make matters worse, Skype is a “peer to peer” (P2P) service, meaning that Skype users connect directly to one another, usually on remote dynamic addresses (which change often), meaning there’s no way to predict and block the IP address of the remote user.

Web searching for a solution uncovered a number of extremely complex potential anwers, most of which involved the use of proxy servers, deep packet inspection, and a bunch of other stuff that I really didn’t want to get into. Er… I mean, things I wouldn’t want to get into were this something other than a completely hypothetical scenario.

However, there is a small chink in Skype’s armor… its Achilles Heel, if you will. Prior to establishing a peer-to-peer connection with another Skype user, you first need to sign in to one of Skype’s authentication servers with your username and password. The authentication servers store your contact list, your chat history, and serve as the launching pad for all Skype chats. Best of all, finding a list of Skype’s authentication server IP addresses only took a few seconds with search engine.

With Skype’s authentication server IP addresses in hand, blocking access to them becomes as simple as writing a Linux firewall script to restrict access to them from the guest network. Again, this technically doesn’t shut down the ability for the chat to take place, it shuts down the ability to start the chat, but it accomplishes the same goal. Here’s what such a firewall command would look like, hypothetically, of course:

iptables -I FORWARD -i br1 -d 111.221.74.0/24 -j DROP

In English, that means that you want to insert (-I) a FORWARD chain rule that says any traffic coming in to the router (-i) from the guest network bridge (br1) that tries to go to any destination (-d) IP address that starts with the numbers 111.221.74 should be ignored (-j DROP).

Therefore, adding one of these lines to your firewall script for each of Skype’s subnets would hypothetically do the trick. Of course, if a marathon Skype chat was already underway, this wouldn’t end it — this approach only stops new chats from starting. So to stop a chat that’s already progress, you’d hypothetically have to briefly shut off the guest WiFi network for a couple of seconds and then turn it back on, temporarily dropping all network access, would would hypothetically frustrate your nephew when he tries to re-initiate a Skype chat with his girlfriend. But you’d hypothetically be able to finally get some decent sleep during your Christmas vacation, which would hypothetically be worth the trouble.

So, if you wanted a list of firewall rules for your router that could hypothetically secure your guest network and shut down access to all the Skype authentication servers, here’s what that script would look like, with comments embedded to help you understand what each line is doing:

Feel free to borrow and edit that file to your liking, just in case you ever need it. Hypothetically, of course.