So, what about Cisco WLAN controllers? They’re definitely not IOS, but they do speak TACACS+ for administrative access, as well as RADIUS.

This one was a little more difficult to get working, but not because of the config on the Ubuntu server. The difficulty was in putting (3) very important configurations together:

1. You must configure authentication and authorization on the WLC for your login to work. Authentication configured without authorization will appear to log your user in, but will send you quickly back to the login prompt.
2. You must configure the order for authentication–with TACACS+ at the top of the list. If you don’t, local accounts will be used first.
3. It doesn’t appear that the service configuration in the TACACS+ user WLC group can exist with the service configuration for an existing group, so nested groups may be required.

#1 should be pretty simple to understand: in your WLC, under Security > TACACS+, configure Authentication, Accounting, and Authorization each with the same servers and keys. I figured this out the easy way–asking Google if he knows of anyone else who got it working. Luckily for me, he knew of someone.

#2 is also pretty easy, but easy to miss. It stumped me for quite awhile, because though I had TACACS+ servers configured properly in my WLC, packet captures on my Ubuntu server showed no packets from the WLC when I tried to login. That’s a pretty good clue that the WLC isn’t even trying to TACACS+ with the server.

A quick shout-out to Linux: thank you for making it easy for me to troubleshoot with tcpdump, on-board by default. I love you!

#3, if you already know the answer, seems like a simple bit of code, but more that one concept is at work. The first that I can see, is from the required code itself: roles, not just permitted commands:

#
# WLC admins: the group 'l3_tacacs_users' is also a member of this group.
# Unfortunately, it has to be nested this way as users can only be
# members of ONE group.
#
group = wlc_admins {
        service = ciscowlc {
        role1 = ALL
        }
}

There are other roles available, but in my case, only the highest level engineer will have access to the WLC, so I saw no need to configure otherwise.

The second concept is nesting groups, because users cannot be a member of more than one group just by listing them, like member = group1, group2. In my case, I wanted WLC administrators to come from the members of the l3_tacacs_users group, so I made that group a member of the wlc_admins group:

group = l3_tacacs_users {
        default service = permit
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
                priv-lvl = 15
                }
        member = wlc_admins
}

The last concept is one we’ve seen before: order matters. At least in my testing, my configuration would not work if the wlc_admins groups didn’t come before the l3_tacacs_users group. It makes sense, how can you refer to a group that you don’t know about yet?

Once I had all of those things in place, AAA logins to my WLC worked as desired. I just wish more was in the accounting log…

What it’s really about is the Puppet server management system deployed to keep general server Linux settings synchronized–stuff like NTP servers and user accounts. Puppet is extremely powerful, but this will only be an introduction to what it can do, as I’m learning as I go.

It may seem a little backward to start with the client configuration, but this really seems like the easiest part to me: tell the client who the server is, sign some certificates, and wait for the updates. The puppet master server is where all the heavy lifting is done.

Once the puppet master server is created and configured with manifests and such (take for granted that they exist already), it’s time to configure your client and get it registered.

STEP 1: INSTALL THE AGENT

me@new-server:~$ sudo aptitude install puppet

An Ubuntu server will tell you all of the packages that must be installed and will give you the option to continue. If you choose to continue, Ubuntu will install all of the packages then warn you that it could not start the puppet agent

 * Starting puppet agent

puppet not configured to start, please edit /etc/default/puppet to enable
   ...done.

which means you need to edit the file the message refers to. So, sudo nano /etc/default/puppet, change

# Start puppet on boot?
START=no

to

# Start puppet on boot?
START=yes

and save the file. Once saved, sudo service puppet start.

STEP 2: AUTHENTICATE THE CLIENT

Puppet uses certificates for authentication, so the master is basically a CA who signs certificates from the clients. Unless you tell the client otherwise, it’ll assume that the puppetmaster’s name is puppet, so you either have to handle that with DNS or by editing the client’s puppet.conf. I took the first route, which seemed easier to me.

On the client, we tell it to send it’s certificate to be signed by the puppetmaster by telling it to test:

me@new-server:~$ sudo puppet agent --test
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled
me@new-server:~$

Once that’s done, we have the puppetmaster approve the client’s certificate:

me@puppet:/etc/puppet$ sudo puppetca --list
  new-server.local (6F:47:D1:6B:F3:B0:4B:94:00:92:5E:F7:E5:38:7C:C9)
me@puppet:/etc/puppet$

me@puppet:/etc/puppet$ sudo puppetca --sign new-server.local
notice: Signed certificate request for new-server.local
notice: Removing file Puppet::SSL::CertificateRequest new-server.local at '/var/lib/puppet/ssl/ca/requests/new-server.local.pem'
me@puppet:/etc/puppet$

After the client certificate is signed, it’s no longer in the server’s pending list.

me@puppet:/etc/puppet$ sudo puppetca --list
me@puppet:/etc/puppet$M

At this stage, the client is essentially configured. Within the next 30 minutes, it will contact the puppet master to see if any new or changed catalog items exist for it–if they do, the client will make the changes. If you’re impatient like me, you can force the client to check in by forcing another test:

me@new-server:~$ sudo puppet agent --test
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for new-server.local
info: Caching certificate_revocation_list for ca
info: Caching catalog for new-server.local
info: Applying configuration version '1330636935'
notice: /Stage[main]//Package[ntp]/ensure: ensure changed 'purged' to 'present'
--- /etc/ntp.conf       2011-09-02 18:42:40.000000000 +0000

Keep in mind that it’s possible that some of the client’s catalog cannot be completed while your user is logged in, depending on what the changes are. For instance, if the catalog for that client changes your user’s UID or GID, you’ll receive an error until your user is no longer logged in.

To be sure that your client is checking in on it’s own, just take a look at it’s syslog:

me@new-server:~$ sudo more /var/log/syslog | grep puppet-agent

Next time, we’ll take a look at the files that make up a “catalog”.

So, here’s the deal: Cisco 99xx and 79xx phones out on the internet somewhere connecting back to an ASA over an SSL tunnel to register with an internal network’s Call Manager, using only self-signed certificates. To me, this is the best option, rather than having users try to type usernames and passwords into the phone interface. For some users, that really is just too much to ask. This method makes it easy on them, and still gives the ASA administrator and Call Manager administrator the ability to prevent a stolen or misused phone from connecting to the network.

This configuration absolutely depends on a few things:

• Working Call Manager that supports VPN configurations for phones. I have no idea what licenses or versions are required.
• Working ASA, with it’s outside interface connected to the internet. This doesn’t work without internet access.
• ASA is licensed specifically for “AnyConnect for phone”. show version, as well as some other commands, will tell you which features are enabled.

Once those items are out of the way, the configuration for the ASA is pretty simple, as long as you understand the basics. This configuration is for code version 8.4, but 8.0+ is very similar. There are a few keywords that are different, so type slowly, rather than just bulk copy-and-paste.

A few things are happening here:

• generating keys to generate a self-signed certificate to share with the Call Manager
• configuring a webvpn group-policy and tunnel-group that will allow the phone to connect to a very specific URL and present certificates for authentication
• importing two certificates from Call Manager into the ASA

If you read through the configuration example, my notes should explain each step. I also refer to a couple of Cisco documents that were very helpful.

! based on this cisco.com ASA AnyConnect for Phone configuration example:
! https://supportforums.cisco.com/docs/DOC-9124
! http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808efbd2.shtml

! generate crypto keypair for ASA
crypto key generate rsa label ssl_vpn_key modulus 1024

! create trustpoint and enroll with the self-signed key above
crypto ca trustpoint phone_ssl_vpn_trustpoint
 enrollment self
 fqdn ac-phone.your-domain-here.com
 subject-name CN=ac-phone.your-domain-here.com
 keypair ssl_vpn_key
 exit

crypto ca enroll phone_ssl_vpn_trustpoint noconfirm
ssl trust-point phone_ssl_vpn_trustpoint outside

! export the certificate trustpoint to import into CallManager
crypto ca export phone_ssl_vpn_trustpoint identity-certificate

! copy the anyconnect client to the ASA
copy tftp://<tftp_server>/anyconnect-win-3.0.5080-k9.pkg flash

! enable webvpn and select an image
webvpn
anyconnect image disk0:/anyconnect-win-3.0.5080-k9.pkg 1
enable outside
anyconnect enable

! create an IP pool not already in use and assign
ip local pool ac_phone_ip_pool_01 10.0.242.1-10.0.242.255 mask 255.255.255.0

! create group policy for phones
group-policy gp_anyconnect_phone internal
group-policy gp_anyconnect_phone attributes
 dns-server value 10.10.41.183 10.10.41.4
 vpn-tunnel-protocol ssl-client
 default-domain < value your-domain-here.com >
 address-pools value ac_phone_ip_pool_01

! permit interface ACL bypass for IPSec and SSL clients globally
sysopt connection permit-vpn

! create a certificate map to map the 'ac-phone' certificate to a specific
! tunnel-group: 'tg_anyconnect_phone' --> 10
! this will be the cert the phone presents as a part of it's authentication.
! when presented, it'll trigger the use of the tunnel-group below.
crypto ca certificate map cm_anyconnect_phone 10
subject-name co ac-phone

! create a tunnel group and URL alias
tunnel-group tg_anyconnect_phone type remote-access
tunnel-group tg_anyconnect_phone general-attributes
 default-group-policy gp_anyconnect_phone
  username-from-certificate CN

tunnel-group tg_anyconnect_phone webvpn-attributes
 authentication certificate
 group-alias anyconnect-phone enable
 ! this URL has to exactly match what's in the CallManager config
 group-url https://name-or-ip-of-outside-int-of-asa/anyconnect-phone enable
 ! permit rules to determine which tunnel-group is used
 tunnel-group-map enable rules
 ! match the certificate map to the tunnel-group
 tunnel-group-map cm_anyconnect_phone 10 tg_anyconnect_phone

! configure nat exemption (no nat, nat 0) for phone address pool, version 8.3 and above
! https://supportforums.cisco.com/docs/DOC-11639, bug is fixed in later version of 8.3, 8.4
! http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtf89372
object network obj_ac_phone_ip_pool_01
 ! subnet <ac_phone_ip_pool_network> <ac_phone_ip_pool_netmask>
 subnet 10.0.242.0 255.255.255.0

nat (INSIDE,OUTSIDE) source static any any destination static obj_ac_phone_ip_pool_01 obj_ac_phone_ip_pool_01

! create new trustpoints and import CallManager certificates
!
! IP phones that have MICs: 99xx
crypto ca trustpoint Cisco_Manufacturing_CA
 enrollment terminal
crypto ca authenticate Cisco_Manufacturing_CA
! < paste Cisco_Manufacturing_CA pem >

! IP phones that have CAPFs: 79xx
crypto ca trustpoint CAPF
 enrollment terminal
crypto ca authenticate CAPF
! < paste Cisco_Manufacturing_CA pem >

All of the configuration words that have underscores are my own and can be changed to anything you choose–as long as you’re consistent with them. I’ve tried to make a habit of using underscores for my configuration variables, since Cisco doesn’t use them in configuration keywords. I also like to use gp_, tg_, and other similar abbreviations so it’s really clear in my configurations which items are which based on their names alone.

This configuration absolutely works. In fact, we have our phones configured with a primary and secondary “concentrator” (ASA); if the primary doesn’t answer, the phone will automatically try to connect to the secondary.

I am leaning on Ubuntu as my new server platform at work, however, since it’s so much easier to count on than CentOS. And as I wrote last, TACACS+ authentication for network device administration is one of my current projects.

There are several pieces to that project,

• setting up two servers
• configuring them the same
• configuring TACACS+ user accounts that can’t login to the server
• sync-ing the TACACS+ user accounts between servers, with one as primary
• sync-ing the TACACS+ config file between servers

but this post is only going to focus on getting TACACS+ installed on Ubuntu 11.10 server (64-bit) and the configuration file. In a later post, we’ll take a look at IOS, ASA, and NX OS configurations for AAA that I’ve found to work well. As always, “your mileage may vary”, but I’d love to know of any tricks or tips others might have. I’m definitely not claiming to have invented this stuff.

On to the installation!

With Ubuntu 11.10, the command line installation process is extremely complicated:

me@tacacs-server-1:~$ sudo aptitude install tacacs+

Ubuntu will install any required dependencies and will create a sample config file, /etc/tacacs+/tac_plus.conf. Generally speaking, I like to copy the original config file for safe keeping before I make any changes to it, so let’s do that before we move on.

me@tacacs-server-1:~$ sudo cp /etc/tacacs+/tac_plus.conf /etc/tacacs+/tac_plus.conf.orig

Whew! It felt good to be so responsible!

It’s also important to know that many Ubuntu servers/services have “config” files in /etc/default that set values or start-up parameters, so if we take a look there, we see that a file does exist for TACACS+ and it states which config file to use when the service starts:

me@tacacs-server-1:~$ more /etc/default/tacacs+
# This is the configuration file for /etc/init.d/tacacs+
# You can overwrite default arguments passed to the daemon here.
# See man(8) tac_plus

DAEMON_OPTS="-C /etc/tacacs+/tac_plus.conf"
me@tacacs-server-1:~$

The default config file location is good with me, so I’ll leave that file as it is. It’s also important to know that root is the only user who can do anything with the TACACS+ config file, which is a critical part of securing this service.

me@tacacs-server-1:~$ ls -la /etc/tacacs+/
total 16
drwxr-xr-x 2 root root 4096 2012-01-18 14:25 .
drwxr-xr-x 83 root root 4096 2012-02-05 23:19 ..
-rw------- 1 root root 3348 2012-02-05 23:12 tac_plus.conf
-rw------- 1 root root 1413 2012-01-18 14:25 tac_plus.conf.orig
me@tacacs-server-1:~$

My goal, when configuring these servers, is to have user accounts that are local Linux accounts–so all user accounts can be administered in one place–but I don’t want those Linux users to be able to login to the server locally or via ssh. The config file below reflects Linux accounts, though you should note that it’s possible to create user accounts in a separate config file, that are not Linux user accounts. That wasn’t a part of my plan, so I’m not going to cover it.

Here’s my config file:

# Created by Henry-Nicolas Tourneur(henry.nicolas@tourneur.be)
# See man(5) tac_plus.conf for more details

# Define where to log accounting data, this is the default.
#
accounting file = /var/log/tac_plus_acct.log

# This is the key that clients have to use to access Tacacs+
#
key = your_secret_key_here

# Use /etc/passwd file to do authentication
#
default authentication = file /etc/passwd

#
# ACLs that may be used to restrict users' access to certain hosts
#
acl = switch01_users_acl {
        # allow access to only one device, switch01
        permit = 10.10.10.10
}

#
# These tacacs+ user groups are not actually tied to the local
# Linux groups, but we'll use the same names here.
#
#
# "level 3" users, with no restrictions
#
group = l3_tacacs_users {
        default service = permit
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
                priv-lvl = 15
                }
}

#
# "level 2" users who cannot "debug" or "config"
#
group = l2_tacacs_users {
        default service = permit
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
                priv-lvl = 15
                }
        cmd = configure {
                deny "."
                }
        cmd = debug {
                deny "."
                }
}

#
# "level 1" users permitted to "show", "ping", "telnet",
# "exit", and "quit"
#
group = l1_tacacs_users {
        default service = deny
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
                priv-lvl = 15
                }
        cmd = show {
                permit "."
        }
        cmd = ping {
                permit "."
        }
        cmd = telnet {
                permit "."
        }
        cmd = exit {
                permit "^(<cr>)?$"
        }
        cmd = quit {
                permit "^(<cr>)?$"
        }
}

#
# Users outside of Net-Ops group, probably restricted to specific hosts
# and specific commands.
#
group = switch01_users {
        default service = permit
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
                priv-lvl = 15
                }
        cmd = show {
                permit "."
        }
        cmd = ping {
                permit "."
        }
        cmd = exit {
                permit "^(<cr>)?$"
        }
        cmd = quit {
                permit "^(<cr>)?$"
        }
        acl = switch01_users_acl
}

#
# Assign Linux users to tacacs+ groups
#
user = dave {
        member = l3_tacacs_users
}

user = simon {
        member = l2_tacacs_users
}

user = theodore {
        member = l1_tacacs_users
}

user = alvin {
        member = switch01_users
}

# You can use feature like per host key with different enable passwords
#host = 127.0.0.1 {
#        key = test
#        type = cisco
#        enable = <des|cleartext> enablepass
#        prompt = "Welcome XXX ISP Access Router \n\nUsername:"
#}

# We also can define local users and specify a file where data is stored.
# That file may be filled using tac_pwd
#user = test1 {
#    name = "Test User"
#    member = staff
#    login = file /etc/tacacs/tacacs_passwords
#}

# We can also specify rules valid per group of users.
#group = group1 {
#       cmd = conf {
#               deny
#       }
#}

# Another example : forbid configure command for some hosts
# for a define range of clients
#group = group1 {
#       login = PAM
#       service = ppp
#       protocol = ip {
#               addr = 10.10.0.0/24
#       }
#       cmd = conf {
#               deny .*
#       }
#}

user = DEFAULT {
        login = PAM
        service = ppp protocol = ip {}
}

# Much more features are available, like ACL, more service compatibilities,
# commands authorization, scripting authorization.
# See the man page for those features.

If you read through the comments, you can get a pretty good idea of what my goals are:

• modularity
• at least 4 levels of user–level-3, level-2, level-1, and special cases
• use the local Linux user database, rather than another config file with either clear-text passwords, or passwords I’d have to encrypt with tac_pwd

Though I’m not 100% positive, I believe that they order of the sections is very important. During my testing with ACLs, it seemed that ACLs had to come first, then groups, then users. I also didn’t have any luck with not assigning a user to a group and trying to assign an ACL to him.

This is a working config, though, tested on real Cisco equipment–IOS, ASA, and NX OS. And it’s free. Well, you do have to have internet access to read it, so not completely free, unless you’ve hacked your neighbor’s wireless, though you didn’t learn that from me.

As you can see from my other posts about virtualization, I’m a big fan of Virtualbox, but this post is about VMware Fusion, which was provided to me with my MacBook.

On to the tips…

I’ve been creating a testing environment for tacacs+ servers for a Cisco networking environment as well as Puppet server management, and I’m horrible with remembering IP addresses, unless there’s a very distinct pattern. When you use NAT in Fusion, addresses are assigned to guests VMs via DHCP in an automatically generated scope. The problem is, every time you boot your server you may get a new DHCP address! That sucks.

What to do?

You could create reservations, like this post and this post suggest, but since I’m eventually going to import the VMS I create into an ESXi host, it doesn’t hurt me to configure the guest’s network statically, as long as I know the range I can use for my guests.

If I look at my Mac’s dhcp.conf,

macbook:~ me$ more /Library/Preferences/VMware\ Fusion/vmnet8/dhcpd.conf

I see:

subnet 172.16.237.0 netmask 255.255.255.0 {
range 172.16.237.128 172.16.237.254;
option broadcast-address 172.16.237.255;
option domain-name-servers 172.16.237.2;
option domain-name localdomain;
default-lease-time 1800; # default is 30 minutes
max-lease-time 7200; # default is 2 hours
option netbios-name-servers 172.16.237.2;
option routers 172.16.237.2;
}

I see that the DHCP scope for my NAT network doesn’t completely consume the whole /24 network–it only uses the “bottom” half. So, if I statically assign my guests addresses in the “top” half of the /24 network, my guests will still be on the same network.

So, if I configure my Ubuntu guest’s /etc/network/interfaces like this

iface eth0 inet static
address 172.16.237.100
netmask 255.255.255.0
gateway 172.16.237.2

and add an entry to my MacBook’s /etc/hosts like this

# my local VMs
172.16.237.100 guest01

my MacBook knows how to find guest01 by name, not just IP address!

macbook:~ me$ ping guest01
PING guest01 (172.16.237.100): 56 data bytes
64 bytes from 172.16.237.100: icmp_seq=0 ttl=64 time=0.345 ms
64 bytes from 172.16.237.100: icmp_seq=1 ttl=64 time=0.233 ms
^C
--- guest01 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.233/0.289/0.345/0.056 ms

When I’m ready to import/convert my Fusion guest into our ESXi host, I just need to edit the guest’s /etc/network/interfaces again with the new IP address information.

Booyah!

I haven’t had a lot of time to kick the tires yet, but one of the best features I’ve found in the latest, 4.0, version is an easy method to export virtual machines that you’ve built. There were ways to do it before, but now it’s easy.

Once you’ve installed/upgraded to version 4.0, simply choose Export Appliance from the File menu of the Virtualbox Manager. The first one I did took less than 10 minutes from start to finish, all wrapped-up in a single file.

Like I said: good stuff.

1. Use the Fast Web Installer app to register your device with AppBrain.
2. Login to the AppBrain website from any computer with internet access, and go shopping for the app(s) you want to install.

In a few moments, you should see a notification on your phone that your app(s) has been installed!

inactive

I’ve used it quite a bit with my HTPC, and frankly prefer it to my Streamzap remote. Another bonus is that now I don’t have to copy my custom Lircmap.xml over every time XMBC is updated.

What I wanted to do: I have a Dish Network DVR in my living room that has an ethernet card in it, but I don’t have any ethernet wiring where it is. What I do have is an Ubuntu XBMC HTPC with an on-board ethernet card and a Linksys WUSB600N v1 (the version number is important here, I think), connected to a Linksys WAP610N AP (configured for 5GHz 802.11N only), so it stands to reason that I should be able to share the HTPC’s internet connection with the Dish DVR, right?

Ok, so it wasn’t. Twice. Once for Ubuntu 9.10 (Karmic) and once for 10.04 (Lucid).

The first thing all good Linux users have to learn is just because it works auto-magically in Windows, doesn’t mean it works the same in Linux. It stings a little, but it’s true. The good news is that there are lots of Linux super-geniuses out there to help and most believe in writing stuff down. If you’re willing to do some Google-ing, most Linux questions/problems can be answered relatively quickly. I had to do a bunch of that.

Task #1: Get 5GHz 802.11n wireless working
When I first plugged my new WUSB600N into my Ubuntu HTPC, Ubuntu recognized it right away, though it couldn’t “see” my 5GHz network (WAP610N). It could see and connect to my 2.4GHz network (WRT54GL) with no problem, so I knew it was time to Google. I found all kinds of stuff–using Windows drivers with NDIS, blacklisting, modprobe–and I tried them all, to the point of complete frustration. Nothing seemed to work, so I decided to install Wicd (and remove Network Manager), because I’d had some luck with it in the past.

Unfortunately, Wicd wasn’t the complete answer: it couldn’t see my 5GHz network, either, so I knew there was more I wasn’t doing. After looking through the logs in /var/log/messages and fumbling through more Google searches for wusb600n ubuntu 11n, I happened across some posts like this one that said I needed to blacklist the rt2800usb driver. Once I’d done that, there were different log messages in /var/log/messages, this time saying that /etc/Wireless/RT3070STA/RT3070STA.dat couldn’t be read. So, I looked for it–the directory didn’t even exist! Now, I’m on to something!

Back to Google again, and it looks like I’m definitely on the right track. I took the example file from this post, and edited it for my network, including the SSID and PSK. Reboot, fingers crossed. Wait a sec…what’s that? Is that a 5GHz network? Yessssssssss! One thing I still don’t understand is that even though I specified all of that stuff in RT3070STA.dat, I still had to do the same in Wicd. I may look into that more later, but for now, it’s time to move on to Task #2.

Task #2: Figure out how to give eth1 an IP address
Unlike Network-Manager (built-in with Ubuntu, Gnome), it didn’t seem like Wicd has a facility to have two interfaces up at once, so I had to figure out a way to give it an IP address outside of Wicd. I could have used /etc/network/interfaces, but since Wicd has the ability to let you run scripts before and after network connections are established, it seemed like a good idea to write a script with ifconfig commands in it to assign eth1′s address:

me@htpc:~$ more /etc/router_script
#! /bin/sh

# This script is run by the Wicd daemon after the PC boots
# and connects the the WLAN using wlan0. Once run, eth1
# has an IP address on another subnet and provides DHCP
# addresses for that subnet. All packets are routed from
# eth1 through wlan0.

# give ethernet interface an IP address
ifconfig eth1 172.16.5.1 netmask 255.255.255.252

I made my script executable

me@htpc:~$ sudo chmod 755 /etc/router_script

and after a reboot, I could see that both interfaces were up and had IP addresses.

Task #3: Figure out how to give my DVR an IP address
Unfortunately for me, I can’t manually assign an IP address to my DVR, so I have to provide it one using DHCP. My router is already running dhcpd, but the request would have to go through my HTPC to get there, much like an ethernet-to-wireless bridge or wireless game adapter; the problem is that I need for my HTPC to still be able to actively participate on my wireless network, not just bridge for my DVR.

I Google’d a bunch about this topic, too, and read and tried a bunch of stuff with bridge-utils, but could never make it work. Instead, I started thinking about my HTPC as more of a router, which made it a lot easier for me to find stuff about Linux routers and providing DHCP addresses. Turns out, it was really easy to set up a second DHCP server on my HTPC that only serves addresses from eth1–that means only devices connected to that interface (my DVR) will ever get addresses. I read a good bit about using firestarter, and even tried it successfully, but I soon realized that for my purposes, it was over-kill. More on that later.

All I had to do to set up my new DHCP server in Ubuntu was
me@htpc:~$ sudo aptitude install dhcp3-server

After my install, I edited /etc/default/dhcp3-server to choose DHCP for only eth1, then edited /etc/dhcp3/dhcpd.conf for the network settings I wanted:
me@htpc:~$ more /etc/dhcp3/dhcpd.conf
# DHCP configuration
ddns-update-style interim;
ignore client-updates;

subnet 172.16.5.0 netmask 255.255.255.252 {
option routers 172.16.5.1;
option subnet-mask 255.255.255.252;
option domain-name-servers 172.16.4.1;
option ip-forwarding off;
range dynamic-bootp 172.16.5.2 172.16.5.3;
default-lease-time 21600;
max-lease-time 43200;
}

Note that I purposely picked a really small network mask, since I just needed a couple of usable IP addresses for that network. It would do no harm to pick something larger, like 255.255.255.0.

Since the DHCP server’s assigning a default router, I need to be sure that the router exists before dhcpd tries to hand out addresses. Calling the dhcp3-server init script again from my router_script is a good way to do that, so I added to it:

# restart the DHCP server
/etc/init.d/dhcp3-server restart

With the configuration done, I restarted the DHCP daemon and connected my DVR to my HTPC with a cross-over cable, then ran the broadband utility to see if it could get an address from dhcpd. Cool! That worked, but it says it’s not connected (to the Dish Network servers). Hmmm…guess there’s a Task #4, then.

Task #4: Give the DVR access to the interwebs
Though the DVR has an address and a default gateway/router, that doesn’t mean that the HTPC is willing to let it’s traffic pass through it. For that, I need to get some help from iptables. As I mentioned a bit earlier, I actually installed firestarter during this process because it has internet connection sharing built-in, and can work with dhcpd’s scripts. What I didn’t like about it was that it seemed like “too much”, since all I really wanted to do was pass all traffic from one interface to another–I didn’t really want to restrict anything. So, I removed it and tried to do the same thing with ufw. After fumbling around with that for awhile, it seemed again, that I was wasting my energy–ufw is really just an interface for iptables, so why not just learn enough iptables to do what I want?

By default, the Linux kernel doesn’t allow the forwarding of packets from one interface to another, but you can tell it to allow it using /etc/sysctl.conf. Change one value and reboot.

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

Now that the kernel will let us forward packets from one interface to another (eth1 to wlan0), we need to tell iptables to accept the traffic into eth1 (filter table), as well as the return traffic to wlan0, back through to eth1 (nat table) Basically, wlan0 is a NAT interface for whatever is behind eth1. We add to those two tables like this:

me@htpc:~$ sudo iptables --table nat --append POSTROUTING --out-interface wlan0 -j MASQUERADE
me@htpc:~$ sudo iptables --append FORWARD --in-interface eth1 -j ACCEPT

Ok, cool: iptables is all set up, so I rebooted and checked to see if my DVR could find the interwebs. “Not so fast, my friend!” Why doesn’t it work? The DVR has an address and I can ping it from the HTPC…gotta be something with iptables, then, so I checked using the command iptables –list.

me@htpc:~$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

My masquerade and forwarding are gone. If I run my two iptables commands again, iptables –list looks like this:

me@htpc:~$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

And if I “print” to STDOUT, I can see both:

me@htpc:~$ sudo iptables-save
# Generated by iptables-save v1.4.4 on Sat Jul 10 19:16:47 2010
*filter
:INPUT ACCEPT [57221:27498502]
:FORWARD ACCEPT [1163:76309]
:OUTPUT ACCEPT [61462:49085429]
COMMIT
# Completed on Sat Jul 10 19:16:47 2010
# Generated by iptables-save v1.4.4 on Sat Jul 10 19:16:47 2010
*nat
:PREROUTING ACCEPT [852:112868]
:POSTROUTING ACCEPT [10:571]
:OUTPUT ACCEPT [112:7142]
-A POSTROUTING -o wlan0 -j MASQUERADE
COMMIT
# Completed on Sat Jul 10 19:16:47 2010

Seems to me that if I’ve already got this super-awesome script that Wicd calls once wlan0 connects, I should just be able to add my iptables stuff to it, so that every time my HTPC is booted the right rules will be in-place. The final version of my router_script looks like this:

e@htpc:~$ more /etc/router_script
#! /bin/sh

# This script is run by the Wicd daemon after the PC boots and connects
# the the WLAN using wlan0. Once run, eth1 has an IP address on another
# subnet and provides DHCP addresses for that subnet. All packets are
# routed from eth1 through wlan0.

# give ethernet interface an IP address
ifconfig eth1 172.16.5.1 netmask 255.255.255.252

# restart the DHCP server
/etc/init.d/dhcp3-server restart

# add needed rules to iptables
iptables --table nat --append POSTROUTING --out-interface wlan0 -j MASQUERADE
iptables --append FORWARD --in-interface eth1 -j ACCEPT

One last time, I checked my DVR: woo-hoo! It says “connected online” and I can manage it from the dish.sling.com website.

Now what? Guess I need to get a DVR with Slingbox built-in, or buy one of the add-ons. Donations will certainly be accepted.

If you’re a Google Chrome user, there’s a browser extension called goo.gl URL Shortener that will reach out to Google’s URL shortener API to create a short URL for you on the fly. Sadly, I don’t think the web interface for goo.gl is available otherwise. Once you have a goo.gl short URL, all you have to do to get the corresponding QR code for that URL is add .qr to the end of it, like so:

http://goo.gl/EFj6 becomes http://goo.gl/EFj6.qr

When wrapped in image tags, it looks like this:

And here’s the HTML:

<img src="http://goo.gl/EFj6.qr" alt="QR code for eison.net" />