Low cost devices to hook up to your Asterisk system

If you're considering setting up an Asterisk PBX (or any other type of VoIP PBX for that matter) you've probably asked yourself what's involved. Obviously you need a computer to run the PBX on, but you're probably interested in knowing how you hook that PBX up to your phone system, and to the phone system.

Well, the good news is that the sudden interest in VoIP means that a lot of the equipment you need that used to cost a fortune is now available at consumer prices. Let's go through it.


Hooking up to the PSTN

The PSTN - public switched telephone network - is the name for the international telephone network we know and love. You'll want to route calls in from it, and out to it. You might even want to play around with a number of different systems to get the best value for money.

If you already have an existing telephone line, and want to use it, the easiest method is to use something called an FXO. An FXO connects to a telephone line and routes calls to and from it to your PBX. Any recommendations? Well, I haven't tried it, but the Grandstream Handy Tone 503 is a low cost device that includes both an FXO and an FXS in one package. What's an FXS? We'll get to that in a moment. The HT503 routes calls from the phone system to your Asterisk PBX via your Ethernet network, and uses the industry standard SIP protocol, which is Asterisk's second language (after IAX.) The HT-503 costs around $60 at the time of writing. Another option is the Cisco SPA3102 which has roughly the same capabilities.

If you don't already have an existing telephone line, or you'd like to migrate to an entirely all-IP network and get rid of your phone line, you also have a number of options.

One ultra cheap, but not quite ready for prime-time, system is Google Voice. Google Voice offers VoIP using a system called Jingle, and Asterisk includes native support both for Jingle, and for Google Voice's version, which includes a few quirks. I've not had problems calling out using Google Voice, but incoming calls are proving to be a problem, so bear that in mind. Until I can tell you exactly how to make it work, I'm not going to cover this... yet. Be aware that if you're going to go down that route, you need Asterisk 1.6 or better. I recommend Asterisk 1.8. There are numerous guides on the Internet to how to do this, but the only version I found that worked was, well, the official Asterisk documentation.

You can also use Google Voice using an intermediary. IPKall offers a free incoming phone number, one based in Seattle. You can configure Google Voice to call that number, and also configure Asterisk to both accept calls via that number, and when an outgoing call needs to be made, have Google Voice call the number and route it via that. You can use this system if you use an older version of Asterisk. The entire system is transparent, but it's somewhat ugly, and I'd question whether anyone wanting a reliable phone service should use this system. Still, configured correctly, you can have a phone service that works just like a regular phone system, but one that costs no more than your existing Internet connection.

Free is free, and it always comes with some health warnings. In particular, bear in mind that you don't get 911 service with the above system. So if you're planning to go the free route, make sure there's other options. A prepaid cellphone will do the job.

Talking of cellphones, you can also use a cellphone that has Bluetooth capabilities with Asterisk. Calls can be routed via the cellphone, and received via the cellphone, as long as it's within range of your PBX, and you've compiled and installed the necessary add-ins to Asterisk (and, naturally, you have Bluetooth on the computer that runs Asterisk.) I'm wary of this route, as Bluetooth is great in theory, but often leaves a lot to be desired in terms of reliability, but it's certainly an option. If you have a family plan with unlimited calling, you could add a line, and use that.

For paid VoIP services, there are many, many, VoIP providers. Expect to pay around $10 per month, sometimes less, sometimes more, for a provider that offers SIP. Be very aware that there are a lot of frauds out there, companies that exist solely to rip off the big telcos, and while you might not be concerned about AT&T's bottom line, being disconnected and without phone service unexpectedly can be a major problem.

For a relatively trustworthy source of recommendations, I suggest BroadbandReports.com. Be careful, as a lot of websites that promote themselves as unbiased are actually run by the providers themselves.

What do I do? Well, I signed up with a company that offers SIP phone service, and I route my US calls via them. My international calls are routed out using Google Voice.


Hooking up your own phones

So that deals with the outside world, what about actually hooking up your own phones to the Asterisk server? You have a variety of options. The option most people start out using is a so-called "Soft phone", a SIP client that runs on their PC, but nobody wants to have to sit at their PC when they make and receive phone calls.

You have at least four low-cost options when it comes to hooking up phones to your network, you can use any or all of them. We just mentioned Soft phones, but what are the other options?

The most obvious is an "FXS", a device that hooks up a regular telephone - with an RJ-11 jack - to your network. There are many options here, all of which provide one or more RJ-11 jacks, each individually configurable to act as a SIP client as far as your PBX is concerned.

• The Grandstream HandyTone 502 is a very low cost VoIP adapter that's proven to be immensely popular, not least with VoIP providers themselves. Expect to pay well under $50 for this device. Grandstream also offers the HandyTone HT286 which only has a single port, it's a little cheaper if your needs are more modest. And as I said above, the Grandstream Handy Tone 503 is another option that combines an FXO and FXS in one box.
• Cisco/Linksys offers a range of FXSes including the Cisco SPA2102 and the Cisco PAP2T. And, as I said above, the Cisco SPA3102 combines a single FXS and an FXO. Expect to pay between $50 and $70 for these devices.

There's not a lot to differentiate between the HT502, SPA2102, and PAP2T, so check the reviews and prices and go from there. I've been using two HT502s - one supplied by my VoIP provider - without problems.

All of the above devices are configured using a web interface, and do not need special software installed on a PC or anything like that.

Option three: use a phone system that supports VoIP out of the box. Siemens offers two DECT cordless phone base stations that support SIP directly - as in you plug it in to your network, bring up a web browser, enter the details of up to six SIP accounts, tell the device which handset uses what and when, and then, well, it just works. I recommend the Siemens Gigaset A580IP based upon my own experience with it, it's very low cost for what it is, and works well with most of Siemens' other DECT handsets.

Option four: Android. Android Gingerbread includes a SIP client built-in, and prior versions of Android can have a third party SIP client, like Linphone, installed. While trying to make this work over your cellular connection may, ultimately, not be worth the effort, you can effectively turn any Android cellphone into a cordless extension phone when it's on Wifi in your own home.

And not just Android cellphones. Android is becoming a standard operating system for MP3 players, most of which are open enough to support the installation of SIP clients.

In fact, any tablet or portable media device that is capable of running a SIP client, that has a microphone and speaker, and has a Wifi connection, is capable of being an extension on your phone network. Useful to know if you have an old Nokia tablet running Maemo, for example.

Something I invite you to look into: The Archos 28 4 GB Internet Tablet (Black) is $80, and in theory has the spec necessary to make it into a very cool cordless phone. I'll be curious to hear your experiences using it.

What are your experiences of the above devices? Did I miss anything you think is worth recommending?





(All of the above links are Amazon Affiliate links, I get a small kick-back if you buy from there, but this only factored in to my decision to link to Amazon, not in my choice of products! And I'm sure you wanted to know where to buy these from anyway!)

Android Gingerbread and Asterisk PBX

(This article has been heavily revised since it was originally written to include some how-to advice)

One of the nice features of Blogger is it has some monitoring software built in that allows you to learn how many people are reading your blog, and, to a certain extent, why. The "Why" is generally 'This guy searched for 'why are my underpants green?' or 'what elephants eat bamboo shoots?' - as in, someone searched for those phrases on Google, and found my site in the search results.

No sooner had I posted my article today about a particular Asterisk PBX error message, than someone landed on my site on that very article - but, alas, they were searching for information about why they were having problems getting the Android Gingerbread client to talk to their Asterisk server.

Well, that's a good topic because I'd been researching just that. Let's talk about this in more detail.

Android Gingerbread (2.3) contains a built-in, fully integrated, SIP client. It's fairly clean, configures itself properly, and - I think quite intentionally - has very few configuration features.

Asterisk supports SIP natively. If someone has a SIP client, and you let them use it, they can make calls via your Asterisk PBX.

So, if Gingerbread supports SIP, and Asterisk does, this means the two ought to work OK, right? Well, it's hit and miss.

Gingerbread, Asterisk, and NAT

Let's first of all cut to the most likely reason why you're reading this article. You've configured your Gingerbread Android phone to use your Asterisk server. You're hoping it'll work, because you want to make Voice over IP calls over the cellular data network. Or perhaps you're OK with only making calls when you have Wifi coverage, but you're not having a lot of luck making calls from, say, coffee shops.

If your phone is behind NAT (and if you're on a mobile network, the chances are you are), then you'll find real problems getting the audio to work. The phone will happily register, you'll even hear ringing when you phone extensions over the SIP client, but once the phone's answered, you'll not hear anything. What's going on?

OK, here's the problem: Android's implementation of SIP is excellent. It's a clean implementation that does exactly what a SIP client should do.

So the issue's with Asterisk, right? Well, no, Asterisk's implementation of SIP is excellent. It's a clean implementation that does exactly what a SIP client should do, and then some.

Well, if it's not Asterisk and it's not Android, then where's the problem? Well, it's neither: it's the Internet. The Internet sucks.

To be precise, it's today's Internet that sucks. When we finally move over to IPv6, many of these problems will be resolved. But not yet.

To understand why, let's talk a little about SIP. SIP is designed to efficiently route a voice over IP call (actually it can do more than that, but VoIP is its primary use these days.) Generally speaking, there are three parties involved in a typical SIP call, a registration server, the caller, and the callee. In some cases, the registration server and the caller or callee is the same (at least from the point of view of either), but that's a topic for another time.

Now, how it's supposed to work is this. The caller places a SIP call. They start with the address of the callee, in the form sip:account@domain (eg sip:paul@sip.harritronics.com) The caller's client looks up "domain", figures out where the SIP service is associated with it, and then sends what's called an INVITE to that server for "account".

Prior to this, the callee has registered with the server. When the server gets the INVITE message, it checks the callee ("account") is registered, and if so sends an INVITE to the callee.

The callee then either accepts or declines the call. If they accept it, what generally then should happen is the registration server should ask both callee and caller's SIP clients how to contact one another, send each other the other's information, and then back out of the way. Or, if that's awkward, the server can act as an intermediary, but either way the server will need to know how each party wants to receive audio, either to tell the other party, or to route the audio itself.

Note - I know that's complicated, so let's explain it using two examples.

You make a call to party b@bsip.com. Your SIP client contacts your SIP proxy, and says it wants to make a call to b@bsip.com, which it does by sending an INVITE message. The SIP proxy finds the SIP server associated with bsip.com, and forwards the request. bsip.com, in turn, tells b@bsip.com that it has an incoming call.

Example 1: If your proxy wants to route the call manually, it'll ask your client where to send the audio from b@bsip.com. It'll then receive audio from b@bsip.com, and forward that audio to where your client asked it to be sent.

Example 2: If your proxy, and bsip.com, doesn't want to route the call, your proxy will ask your client where to send the audio from b@bsip.com. It'll then pass that information to bsip.com, which in turn will pass that information to b@bsip.com. b@bsip.com's client will then send audio directly to where your client asked it to be sent.

And herein lies the problem. Android's Gingerbread client gets the request, looks up its own Internet address, and says "Send it to me at this address." It sends the details to the server, and the server tries to send audio to that address.

But that address is, on a mobile network, almost always an Intranet address. (Just to add insult to injury, T-Mobile - for reasons I cannot fathom - has chosen to eschew the standard Intranet blocks and use some IP addresses allocated to the Department of Defence instead. I'm not making this up.) So when the server sends the address to the other party (or tries to send audio to it itself), it gets lost in the Internet.

OK, you may well ask, well, why not ignore the IP address the client sends, and just use the address the message came from? Well, because that would break SIP. Imagine, for a moment, if one of the "parties" involved is actually forwarding their calls. Maybe they're doing it directly, perhaps paul@sip.harritronics.com maps to paul@sip.stuart-office.harritronics.com; maybe they're doing it indirectly - a company that offers VoIP phone service might forward a call through a range of servers before it gets to you.

SIP's designers took this into account. The messages involved in setting up the call are forwarded, so that in the end the two clients will still end up having a direct connection (which is reliable and has little latency) rather than one where every packet is going through a hundred intermediate servers (which is inefficient, unreliable, and raises the latency.) If the intermediate server were to deliberately ignore the address (which is of the client involved) and put in the address the request came from (which might just be another server), then that would break everything.

So it's Gingerbread's fault for doing everything as it should. And it's Asterisk's fault for doing everything it should. And it's SIP's fault for being designed to be efficient. Or, well, it's the Internet's fault for sucking.

Why does the Internet suck? Because there aren't enough IP addresses, and so most people have to use NAT to get online. And NAT is a one way protocol, you can reach people outside of NAT, but you can't reach them within.

All of this said, is there a solution (beyond us moving over to IPv6)? Well, SIP is frequently used together with a protocol called STUN. STUN helps a SIP client determine what the IP address is that it's traffic is really going out on, and using some dirty tricks that many routers support, the SIP client can determine a configuration that might work for SIP.

It's dirty, it's not the way to do things, and that's probably why Gingerbread doesn't use STUN.

Asterisk and NAT

Now, at this point you're probably wondering if there's a workaround. After all, Asterisk's developers can't be happy that their system doesn't work with NAT. Well, Asterisk has some NAT workarounds, but they're imperfect. Asterisk is reluctant to assume that an IP address it's told to send data to is wrong, and it generally assumes that the client will make some sort of effort to get around NAT itself, meeting it in the middle. So while Asterisk even supports a "nat=" option in sip.conf, both universally and for each individual client, unless the client makes some kind of effort to present proper IP addresses itself (or by happy accident it works anyway) this will not be enough to make a client work from behind NAT.

Workarounds

There are very few workarounds that'll get Gingerbread working with Asterisk over NAT. Some things you should consider when trying to solve the problem yourself.

• Have you considered a different protocol? Asterisk supports IAX, a "dumb" protocol that sacrifices efficiency for easier routability.  IAX clients exist for Android.
• Likewise, SIP clients that are generally better at routing around NAT, and cooperating with Asterisk, are available, although I'll be honest with you and tell you I haven't had much luck with any of them.
• Finally, you can use VPNs to give yourself direct access to the network running your Asterisk server. My only comment on this is that VPNs are a little messy in Android, they don't stay up for very long, and you generally have to reauthenticate yourself every time you connect to one. VPNs do work, however, they can be used to route SIP.

Using your Gingerbread device on your own network with Asterisk

OK, now we have the question you wanted answered answered in a way you probably didn't want, let's ask the related question "What are the settings I need to make it work at all?"

ie:

• You're OK with it only working when directly connected to your network
• You understand it'll probably not work when at a coffee shop
• You understand it'll almost certainly never work when on cellular data
• Although... that VPN thing will make it work too.

Here's the settings.

From my own sip.conf:

ignoreregexpire=yes

[paulscellphone]

type=friend                     ; Pretty much all devices that make both incoming and outgoing calls are "friends"

secret=password123       ; This is the password

host=dynamic                 ; We're not going to care what IP address the cellphone is using, but this is an area you can lock things down with

nat=yes                           ; nat=yes virtually never breaks anything, there's no reason not to have it on

directmedia=no               ; Because we're behind NAT we want the server to take care of audio routing

callerid=Paul's Cellphone <102> ; The caller ID we want to show internally 

context=harritronics-internal   ; "harritronics-internal" is the context I use for my office.

disallow=all                    ; Default - reject codec

allow=gsm                      ; Accept the GSM codec

allow=alaw                     ; Accept G.711 aLaw

allow=ulaw                     ; Accept G.711 uLaw

caninvite=no                   ; These settings confirm we want the PBX handling the audio

canreinvite=no

qualify=yes                    

The only two settings there that are unusual for the Gingerbread client are "qualify=yes" and "ignoreregexpire=yes". They cover the fact the Android Gingerbread SIP client doesn't renew its registration when you'd expect it to, and so Asterisk thinks it's fallen offline after a few minutes. 

Conclusion

So, that's the answer. You can use Gingerbread's SIP client as long as the client (and the Asterisk server) both have real IP addresses, or are both connected to the same network, without any problems. However, if the Gingerbread device is behind NAT, and not on the same network as the Asterisk server, then you're unlikely to get anything to work.

I hope that helps someone out there too.

Asterisk tip: handle_request_invite: Call from '' to extension 's' rejected because extension not found

So you have your Asterisk PBX system all set up, and things look like they're configured exactly as they're meant to be, but for some reason incoming calls keep being rejected. When you run Asterisk in verbose mode (type sudo asterisk -r from a shell prompt on the server to enter the CLI, and then "core set verbose 999" at the command line), you see this message whenever there's an incoming call:

handle_request_invite: Call from '' to extension 's' rejected because extension not found

Now, at this point, obviously, you should make sure that your sip.conf entry for the peer that you're receiving calls from has a "context" set to one in extensions.conf that has an entry for s, eg:

register => 7726780680:1234@mysipprovider

[mysipprovider-in]
type=peer
qualify=yes
insecure=port,invite
disallow=all
allow=ulaw
context=incoming

[mysipprovider]
type=peer
secret=1234
username=7726780680
fromuser=7726780680
fromdomain=sip.example.com
host=sip.example.com
outboundproxy=sip.example.com
nat=yes
context=incoming
caninvite=no        ; Appears to be required for outgoing audio
canreinvite=no        ; Appears to be required for outgoing audio
disallow=all
allow=ulaw,alaw

And in extensions.conf:

[incoming]
exten => s,1,NoOp(Call from MySipProvider)
exten => s,n,Dial(SIP/exampleext&SIP/anotherexten&SIP/yetanotherone, 20)


Now, I see you reading this going "I did all this! Why is it not working!? It all looks right, and I added 's' to everything else, and it STILL doesn't work!"

Welcome to my world yesterday. Well, here's what's probably going on. Somewhere in your sip.conf you probably have something like:

domain=blahblah.mydomain.com
allowexternaldomains=no

(the latter line might even be commented out, as it's the default)

And that's fine, that's what you're supposed to do. Except... well, what seems to happen with some setups is that the messages from your SIP provider do not come with blahblah.mydomain.com (or something anonymous), they come for sip:s@<some IP address> (where <some IP address> is unrelated to anything on your network.

When that happens, you get the above error message. It doesn't mean that the configured context doesn't have 's' in it, it means that s@<some IP address> is the extension it can't find, because as far as it's concerned, the <some IP address> thing has nothing to do with it.

What are your fixes? Well, there are two possibilities.

The first - and probably preferable option - is you can use the SIP debugging tool built into Asterisk to work out who the messages are addressed to. Simply type "sip set debug" at the Asterisk CLI, and call yourself from a cellphone. You'll get a massive dump of messages like this:

INVITE sip:s@192.168.1.5:6080 SIP/2.0
Record-Route: ...
Record-Route: ...
Via: ...
Via: ..
branch=...
Via: ...
f: "PAUL - Cell" <sip:7725550168@192.168.2.3>;...
t: <sip:+17726780680@...>
{etc}

When you're done, type "sip set debug off", and make sure you're using a terminal that has a very large scroll back buffer!

Anyway, take a look at the INVITE message. What Asterisk is looking for is "INVITE <something>@blahblah.mydomain.com", and s@192.168.1.5 is not an example of that, so as far as it's concerned it's not a valid extension and it rejects it.

Solution - add "domain 192.168.1.5" to your sip.conf.

If that doesn't work, option (b) - which is less nice - is to put in

allowexternaldomains=yes

Despite the name, that line does not mean "allow anyone to route their calls through you", it means "Just ignore the domain, treat everything as local".

More recent versions of Asterisk apparently have this switched on, but not the LTS 1.4 release.

I hope this helps someone out there.

Primer: IPsec

Let's talk about a standard home or small office network. The typical components of such a network are:

• Some Ethernet cables
• Computers attached to Ethernet cables
• Routers, switches, and hubs attached to Ethernet cables
• A wireless router (also hooked up to Ethernet cables...)
• Computers "attached" to the network via the wireless router
• A router that's hooked up to the actual Internet connection (ie the modem - DSL, cable, or whatever...), which is also hooked up to the Ethernet cables.

In a typical network today, the router that's hooked up to the Internet does a number of different tasks. Primarily, it's responsible for giving computers on  your network access to the Internet, but it's generally also tasked - rightly or wrongly - with preventing outsiders from gaining access to your network. The general assumption is that as long as someone on the outside can't access your computers, those computers are safe.

Now, is this right? Are your computers protected by merely having a router block access to them? Well, yes and no. The practical upshot is that a large number of security breaches will be prevented, and many people will never experience a security breach as a result. But security professionals will tell you no, for the same reason that the same professionals will tell you that, say, running Ubuntu as your desktop operating system is no protection against hackers - as a security policy, it's flawed. Let's look at why:

• Your computers are still accessing the Internet. They might unwittingly initiate a transfer of something bad to themselves. For example, you might be browsing the web, and click on a link that, unknown to you, links to a page that exploits a security flaw in your web browser.
• Inevitably, for all but the simplest networks, you will have to open up some connections to allow outsiders in. Typically, you'd enable something like "Let users of this game access this computer that plays this game", or "Let people who want to call me using an Internet phone access this computer". The procedure is called "port forwarding", and each port you open inevitably creates a hole that might be exploitable if there's a flaw in any of the software on your side that services those systems.
• Very few people have all of their computers connected permanently to one network. Anyone with a laptop might, for example, take that laptop to a hotel or coffee shop and use the Internet connection there. Likewise, you might let a friend or colleague use your network with their laptop to access the Internet. If such such systems are compromised when they're out of the network, then they're compromised.
• Once you have a compromised device on your network, regardless of which of the above scenarios best described the cause, the router no longer provides any real protection against it. If that compromised device wants to compromise the other computers on your network, then you can't rely on your router.

The situation gets considerably worse once you factor in IPv6. In IPv6, every device on the Internet is supposed to be able to "see" every other device on the Internet. That doesn't mean that every device can access all of the services of another device, but it does mean that if, say, two computers want to engage in, say, a voice over IP session, those computers should be able to do so if the administrators of both machines are happy with that. In such circumstances, having a router manage security is completely inappropriate. A router doesn't know why two computers are communicating, and the likely result of it managing security is that it will allow communications it shouldn't, while blocking communications it should.

So, what's the right way to manage a network?


Making computers responsible for their own security

When IPv6 was being developed, the questions on security came up, and as a result, a certain amount of work was put in to making sure that the protocol would bring security with it. Two devices ought to be able to guarantee the following:

• Devices should be able to decide who to have a conversation with
• The device they're having a conversation with is the device they think they're having a conversation with.
• That compromised devices that can "see" the traffic between the two cannot spy on the conversation.

The solution would require a mix of different technologies.  Some of these would exist outside of the realm of standardization - for example, so-called "software firewalls", where an operating system decides which applications are allowed to access the network and which aren't, and when they do what systems they can communicate with - were clearly operating system specific, and beyond the scope of the protocol.

Others however were created to ensure the security above was implementable. The major technology that was mandated was IPsec.


What IPsec is, and what it isn't.

IPsec is a low level protocol that encrypts the connection between any two devices on the Internet. Those devices can be in the same room, or on different sides of the planet, and they can be running any application, not just applications that were specially written to support encryption.

And that's pretty much it. IPsec is extremely lightweight. It assumes that two computers have identified one another, that they have found a way to securely exchange encryption keys with one another, and so on. But if two computers have actually been set up to use IPsec to communicate with one another, then they already can ensure that connections between the two are secure. Nothing can eavesdrop on the conversations between them, and nothing can send messages to one pretending to be the other.

To support IPsec, a number of other protocols have been created. The IKE system is used to exchange keys, and the master keys for each device can be stored in DNS in a secure, standard, way, secured using a system called DNSSEC. Unfortunately, at the time of writing, these technologies are only half implemented - most operating systems ignore the information in DNS by default, and most domain registrars do not actually allow domain owners to set up DNSSEC, but I expect both problems to be resolved in time.

By itself, IPsec isn't very useful, but combined with IKE and DNS, IPsec can be used by operating systems to ensure a large number of security measures are taken:

• Connections between computers can be secured so no eavesdropping is possible. IPsec encrypts the connection.
• Individual applications can be firewalled, using a software firewall, to only communicate with specific devices on the Internet. IPsec ensures that the devices on the Internet are identifiable and virtually impossible to impersonate
• "Opportunistic encryption" becomes easier, making it harder for data thieves to intercept communications even between devices that are unrelated to one another.

IPsec with IPv4

While IPsec was originally intended as an IPv6 technology, it ended up being used on IPv4 networks, frequently for a slightly different purpose. The lack of devices with real Internet addresses, and the immature state of DNSSEC, meant that IPsec's intended role in the existant Internet was not terribly viable. However, the concept of IPsec "tunnels", used to implement VPNs, has become relatively popular.

Of course, there's little to stop you from running IPsec on your own network even if you assume that your computers will not be able to use it for communications over the Internet, and in many ways it's preferable to do so. As noted above, IPsec, combined with its support technologies, makes it much easier to secure each individual PC. If you would allow friends and colleagues to use your network, then it makes sense to implement a system that secures your computers against their's. The downside is increased complexity - nobody's making this particularly easy right now!

Support for IPsec

IPsec is supported by virtually all major operating systems (as is IPv6), and if you plan to use IPv6, I strongly advise you to investigate IPsec ensure it forms part of your strategy for rolling out IPv6 within your network. A roll-out of IPv6 implies opening your infrastructure to the outside world, and that makes security much more important.

IPsec does not, by itself, secure a network, but it is a mandatory component of a secure network. A properly set-up network that uses IPsec as part of its security will always be more secure than a network secured using a router - and it'll be one that works.

Primer: Authentication - RADIUS, Kerberos, and LDAP

When someone "logs in" to a computer, typically a number of different systems play different roles in the process. You'd think it'd be simple - just have a server somewhere accept usernames and passwords, and respond accordingly. Reality is more complicated than that:

• People hate logging in over and over again
• Users have more to them than usernames and passwords
• A server that authenticates people needs to be trusted, and it needs to make sure that it can trust people using it.

Different applications require different approaches. Here's some typical services that require authentication:

• Logging into a PC in the morning, to verify you're the real owner of the machine so you can access the files stored under your name.
• Using network resources from your PC, such as email.
• Securely connecting your PC to the network via a less secure network (such as via a VPN, or just your office's wireless system.)

Now, depending on the network, one or more of these might be set up separately. The accounts on the PC, for example, might be manually set up by the PC's owner, the network resources such as the email system might be an entirely different set of accounts, and accessing, say, your wireless router, might require a single, shared, password. Your home network is probably set up this way. But as you add users and computers, you get a steadily more and more complicated network, and it becomes much more difficult to manage the system unless you have some centralization to the authentication systems.

Three technologies in particular make up the majority of authentication systems. These are LDAP, Kerberos, and RADIUS. Let's talk about how these work together and the roles each technology plays.


LDAP - The Who, What, and How

LDAP is what's called a Directory System. It's a database system, essentially, used to store information about the various entities on your network. On a typical network, it stores:

• Usernames
• Passwords associated with usernames
• Rights associated with usernames (eg. "This user can administer his PC")
• Configuration information (eg. "This user's name is Fred")
• Devices hooked up to the network (eg. "FredsPC")
• Configuration information that the devices hooked up to the network can use to configure themselves.

When you log into your PC in the morning, typically the PC does a number of things. Once it's verified you are who you say you are (it'll usually indirectly use LDAP for this), it'll download information from LDAP about you,  to set you up with the correct rights and permissions.

LDAP is typically the core of the authentication system. Everything else uses the information from LDAP, so that only one system needs to be kept up to date.


Kerberos - I'm Really Who I Say I am

While LDAP stores the information about you, Kerberos is responsible for telling services on the network who you are. When you log into your PC in the morning, the Kerberos system is responsible for verifying your username and password, and getting what's called a "Ticket" that can be used to identify you in the future. This system means that if, say, your email system needs to verify you really are who you say you are before giving you access to your email, all your PC needs to do is send the ticket behind the scenes to the email server, and the email server will know it's you.

Now, you might ask, why? Rather than get a ticket, why not have the PC send your login credentials and the mail server can verify that the credentials are correct by looking them up in LDAP? Well, two reasons:

1. Sending login credentials and checking them against LDAP creates more load, and more opportunities to break, for the LDAP server. If the LDAP server is down for a minute, all network services will shut down as soon as they require any kind of authentication. By comparisons, the tickets issued by Kerberos can be checked without going back to any other servers - using a system called cryptographic signatures.
2. Sending login credentials is inherently insecure. What if your PC sent your username and password to a computer masquerading as the email server, but run by someone trying to hack into your network? Kerberos's tickets don't contain any secure information, they expire after a certain period of time, and they can only be used for network services delivered to the computer that they were issued to.

Kerberos is typically implemented by having it read LDAP for information about the available users. Kerberos doesn't store anything other than usernames, passwords, and "keys", used to identify network services.

To expand on the "What happens when you log in in the morning" example above, here's how Kerberos fits into the picture.

1. You enter your username and password
2. Kerberos is used to obtain a ticket for the username and password, if they're valid. If they're not, then you're told you can't log in.
3. Your computer now obtains information about you from LDAP and ensures your account is set up correctly.
4. You get a desktop, and you double click on your email icon.
5. The email client sends the Kerberos ticket associated with your session to the email server. The email server sees that the ticket is for you, and verifies that the ticket was issued to your computer and that it hasn't expired. All this information is in the ticket, together with a signature that proves the ticket hasn't been forged or tampered with.
6. Your email client opens up and shows you the email on the server.

So, LDAP stores information about users, and Kerberos is one way of authenticating those users. But what if you can't authenticate someone using Kerberos, and you don't trust the device sending you authentication information?

RADIUS - He's with me, let him in

Unless a device is actually on the network, it can't use Kerberos (or LDAP) to authenticate itself. But your network would hardly be secure if you allowed anyone to connect to it without authenticating themselves first. This Catch-22 has been solved using a system called RADIUS. RADIUS is used to authenticate devices at the time that they're trying to connect to a "private" network. It's most often used by ISPs to ensure only customers can connect to their dial up systems, but the chances are your Wireless Access Point also supports RADIUS as a way to let authorized users connect securely - and keep unauthorized users out.

RADIUS was originally used by dial-up ISPs but over time became more advanced as the needs of those using it grew. It became necessary, for example, to ensure that the device needing to access the network never actually sent a password. Why? Well, suppose you have three parties.

• A user
• A dial-up ISP
• AOL (yeah, America Online)

The user is a customer of AOL. AOL has an agreement with the ISP allowing AOL's customers to access AOL via the ISP.

So the user needs to dial into the ISP, and log in using their AOL credentials. If the user sends her username and password, the ISP could log the information and use it to log in as that user. So instead, a system where AOL's RADIUS server sends information back to the user's PC saying things like "If I turn your password into a string of numbers, multiply them, add three, and divide by the fifth letter, what answer do you get?" This way, anything in between, like the ISP's dial-in server, never gets to see the user's credentials.

How is this relevant to your network? Well, RADIUS is no longer just a technology used by ISPs. It's also used on VPNs and on modern wireless routers (although it's surprising how few wireless routers are configured to use it!) The same concepts that made RADIUS work for ISPs with complex authentication requirements also make it extremely good for integrating an authentication system for devices that need to access your network.

As always, in a modern environment, the RADIUS server still uses the LDAP server for the master copy of the authentication information.

Between them, LDAP, Kerberos, and RADIUS generally cover all of the authentication requirements of a modern internal network.

Other authentication technologies are also creeping in as the world becomes steadily more web oriented, such as oAuth and OpenID. These technologies are designed under the assumption you'll need to access a network's resources from an arbitrary web browser, that might be on a user's PC, or a tablet, or smartphone. Unlike the above technologies, they don't assume integration with the operating system, but they're not designed for an environment where every device is managed centrally.


Trying them out

The technologies above constitute what's commonly referred to as domain security. If you're a member of one of the various Microsoft programs that allows you unlimited access to its technologies, an extremely good starting point towards learning this system is to use Active Directory. AD is a strong domain security system put together by people who obviously understood the concepts.

On the GNU/Linux side, the options are there (all of these technologies started off as open standards, built upon open source, and fostered within Unix environments), but there's a lack of expertise. Still, two systems you can seriously consider installing and setting up are Apache's ApacheDS and the FreeRADIUS project. ApacheDS is a combined LDAP/Kerberos server (so you don't have to worry about the details of how to connect the two), and FreeRADIUS, as the name implies, is an open source implementation of the RADIUS system. GNU/Linux supports PAM and NSS to integrate LDAP and Kerberos into the log in process.

I'll be posting a HOWTO shortly on how to set up domain security for a network comprised of Ubuntu machines. Stay tuned!

Were you prepared for IPv6 day?

For computers to talk to one another on the Internet, each needs an IP address, an identifier used to determine which device needs to receive a message.

Officially, the jury is out on whether we've run out of IP addresses for the Internet's existing infrastructure (IPv4), in reality we ran out of them in practical terms a decade ago, with ISPs and users using rationing techniques varying from "NAT" (Network Address Translation - a way to have multiple computers share a single address) to "dynamic IP addresses" to manage the severe shortage of addresses compared to the numbers of devices people want attached to the Internet.

The solution, IPv6, is something I've written on before. IPv6 increases the number of IP addresses exponentially, creating enough that every connectible device on the planet could conceivably have 18,446,744,073,709,551,616 addresses by itself (and that's just using the proposed, best practices, number planning system! OK, the real number is somewhat less given the number of reserved networks, but we're still talking about being within an order of magnitude of that number.)

Also important, IPv6 updates the Internet's security model so that the bodges people have relied upon for so many decades to try to keep their machines secure are no longer necessary.

Great, huh? Well, IPv6 isn't compatible with IPv4 - the two can co-exist on the same network, but applications have to explicitly support it, and you don't have an IPv6 network and connection to the Internet unless you've explicitly set it up.

To that end, Wednesday was IPv6 day. IPv6 day gave everyone a chance to check a number of things:

• That if they configured their services to be available to IPv6 users, that IPv6 users would be able to use them.
• That if they configured their services to be available to IPv6 users, it wouldn't affect people who only had IPv4 access.
• To make sure they could use other people's IPv6 services.
• To make sure there were no major holes in the system that caused a rise in the amount of hacking.

By all accounts, IPv6 day was largely a success. Some users experienced glitches, but for the most part, everything worked this time.

But were you ready? Well, moving over to IPv6 is not as scary or difficult as you might imagine, with the exception of one thing. I'll cover that in a moment.

How to upgrade to IPv6

1. Get a broadband connection

And it has to be "real" broadband, the kind that's usually delivered over a cable (telephone, cable TV) to your house. Some wireless broadband services may work, but you're unlikely to find anything designed for mobile use will work at all. This is because your connection needs to be a proper Internet connection, and mobile links are typically hampered by firewalls and proxies that make using them for anything other than web access extremely difficult.

2. Get the right router

For your home or small office, you probably connect to the Internet via two devices, a "router" and a "modem". The modem - cable or DSL - connects to your ISP's physical network, and the "router" is what allows you to share your connection with all of the computers on your network. Wireless routers are increasingly popular these days, but you may have bought a non-wireless router for security reasons.

Well, the router is the major thing you need to check and possibly upgrade. Newer routers support IPv6 natively, and do so even if your ISP doesn't. One inexpensive router is the D-Link DIR-615 (sponsored link) although I use the slightly more advanced dual band D-Link DIR-815 (also sponsored.) I've used both routers personally, and the two support IPv6 natively, even if your ISP doesn't.

3. Set up your IPv6 connection

You have three options as far as getting an IPv6 connection goes. In order of most preferred to least, they are:

1. A direct connection from your ISP
2. 6to4
3. A tunneled connection from a Tunnel Broker.

All of these options are available for free if they're available, and they all provide the same thing: a block of 18,446,744,073,709,551,616 IPv6 addresses for use as you see fit. Yes, it's that number again, but I'm using it in a slightly different context. Anyway, the point is all three systems give you what's called a "Prefix", which is a huge block of addresses that should cover every single device you could possibly connect to your network, no matter whether it's a single PC or an entire corporation.

Let's discuss each and I'm going to explain how to see if you have them available if you have one of the routers linked to above (or a similar D-Link router) - but if you have another router that supports IPv6, my instructions should be easy to transfer to that one.

A direct connection to your ISP is obviously the preferred way to access the Internet, but be aware there are a few gotchas as far as this route goes. The major issues are:

• ISPs that offer IPv6 often don't actually offer it as a direct connection, instead providing some kind of tunnel. The reason for this is that many ISPs are still experimenting, and their IPv6 services reflect the fact they're experimenting.
• Many ISPs don't allow you to configure something called reverse DNS. Reverse DNS is part of the process of identifying computers, and many of the technologies that are used to implement IPv6's IPsec security system require reverse DNS to be working. Right now, that's not a top priority, but it's something that needs to be addressed in the near future.

How can you tell if your ISP provides you with native IPv6 connectivity? For the D-Link routers specified above, do the following:

• Make sure your router is set up and that your router, not your modem, is managing your Internet connection. For cable modems, that's pretty much the default anyway. For DSL modems, you may have to put your modem into "bridged mode". How to do this is beyond the scope of this article, but if you're confused then your ISP should be able to help.
• Log in to your router using the web configuration system
• Go to the Advanced tab
• Go to the IPv6 page using the menu on the left.
• Choose "Autoconfiguration" from the "My connection is" drop down.
• Save the changes.
• You should discover fairly shortly whether you have a live connection. Go to the Status tab, and select the IPv6 page from the menu on the left. If nothing comes up as the "WAN IPv6 address", and you're using DSL, try changing the type to "PPPoE", and save the changes.
• If you don't get anything showing up as the "WAN IPv6 address" after a few minutes, this isn't working, and your ISP is not providing native IPv6 connectivity. So, it's time for plan B.
• If you did get things up and running, go back to that IPv6 configuration page (Advanced->IPv6), and under "LAN ADDRESS AUTOCONFIGURATION SETTINGS", ensure "Enable autoconfiguration" is set, and make sure "Autoconfiguration type" is "stateless". Save the settings, and try IPv6!

If things didn't work, then the next thing to try is 6to4. 6to4 connectivity provides an automatic tunnel through the IPv4 part of the Internet. Your IPv4 address is used to create a range of IPv6 addresses, and anything addressed to those IPv6 addresses gets routed to your router. In theory, the system works with all real Internet connections - as long as you have real, direct, IPv4 connectivity to your router, and your router has a real IPv4 address, you should be able to use it.

In practice, some ISPs are being bloody minded about this (AT&T's Fastaccess system springs to mind - you SEE why I don't want AT&T to take over T-Mobile? AT&T hates innovation, or at least they act is if they do) and they prevent you from using 6to4 by cutting off access to the gateways that make it work. But if you can get it, it's a cheap, easy to set up, efficient way of using IPv6. There's virtually no downside compared to native access from your ISP save for slightly less efficient use of bandwidth. You might even find it works better than native access from your ISP!

So, how do you check if it's available? Well, the procedure is slightly more complicated. First of all, I want you to make sure your own computer supports IPv6. Exactly how you configure that will depend upon your choice of operating system, but I need you to make sure you've done that before you continue with these instructions.

Now you're set up, go back to your router's admin page, log in, and go to Advanced -> IPv6, as you did previously.

• Change the "My IPv6 connection is" setting to 6to4.
• Leave everything in the "WAN IPv6 ADDRESS SETTINGS" section blank, even the stuff that looks mandatory.
• Under "LAN ADDRESS AUTOCONFIGURATION SETTINGS", ensure "Enable autoconfiguration" is set, and make sure "Autoconfiguration type" is "stateless".
• Save settings
• Make sure things are set up properly by giving it a minute, and going to Status -> IPv6. If you don't get anything coming up under WAN IPv6 Address, then keep trying, and if nothing's up after five minutes, well, it's just not going to work.

This is half the battle. The other half is making sure you really do have IPv6 connectivity. The problem is that, as I said, some ISPs block certain gateways needed for 6to4 to work, and you need to make sure your ISP isn't one of the. So, if you successfully completed the above steps, do the following:

• Make sure your PC has an IPv6 address. How you do this is operating system dependent, but in essence you need to make sure you have an address beginning with 2002:. On a PC, open a DOS window, and type "ipconfig | more". On a GNU/Linux box, or a Mac, you can use "ifconfig | more" to do much the same thing. If one of your "interfaces" is listing as having an address looking like 2002:xxxx:yyyy:...(etc) (where xxxx and yyyy are strings of digits and letters) then you have the address. If you don't get one, and you're sure your PC is set up correctly, try rebooting.
• Once you're sure you have an IPv6 address, open a web browser, and visit http://ipv6.google.com. If Google comes up, your 6to4 system is working!

If things didn't work, then plan C is the way to go. Specifically, getting a connection from a Tunnel Broker.

Now, what is a Tunnel Broker? A Tunnel Broker provides an IPv6 connection over what, in some ways, resembles a VPN (except your router handles the connection part.) Just as with 6to4 and native ISP support, you still get a proper block of IPv6 addresses (a prefix), but unlike the other options, all of your traffic needs to go to and from the broker, which is somewhat inefficient, to put it mildly.

Tunnels are available for free, and one of the most popular is Hurricane Electric's "tunnelbroker.net" service. Just go to that address, sign up for an account, and after you've followed the instructions, configure your router thusly:

• I know you're about sick of it by now, but log back into your router, and go to Advanced -> IPv6
• Select "IPv6 over IPv4 tunnel"
• Under "IPv6 over IPv4 TUNNEL SETTINGS", enter the information TunnelBroker.net gave you.
• Save the changes
• Check the status, and wait for everything to work.

By now, one of these three methods should have given you an IPv6 connection.

4. That's it!

Those three steps should have given you an IPv6 network to use. You can, at least, test IPv6 using this, but remember, there's more to IPv6 than a lot more addresses. You also need to think about your network's security, but that's for another article!