IPSec VPNs are great for creating secure point-to-point connections between sites over the Internet. Whether you’re working at home, connected over your broadband link, using a wireless connection in the local coffee shop, or making use of a guest Internet connection in a customer’s or partner’s site, you can build a secure tunnel for your data to keep it safe from eavesdroppers.

However, IPSec has one drawback that comes to light mainly when you want to use it for securely connecting more or less permanent sites, such as small offices that can also be best served using Internet connectivity with IPSec - it doesn’t support multicast traffic.

The purists among you here will point out that the Security Associations (SAs) that form the basis of IPSec VPNs do in fact cater for multicast (or broadcast) destination IP addresses. That’s true; however since key management for multipoint SAs has not been addressed, IPSec does not currently work with multicasts or broadcast IP datagrams.

Why Do You Need It?
Is this a big issue? A couple of years ago, probably not; however more and more applications are becoming mainstream that rely on multicast: software distribution, video or audio streaming, or the wealth of real-time asset management solutions from companies such as Tibco, which provide software to help in everything from package tracking to energy trading.

And, of course, every dynamic routing protocol, with the exception of BGP, relies on multicast too.

So what’s the answer? Of course you don’t have to use the Internet for your connectivity. Put in a traditional leased line or get a point to point LES service from your provider and you don’t have to worry about IPSec. But if the Internet option is a good one based on cost, can we get round this restriction?

The answer is yes. Sort of. But before you start, you need to be aware of the implications and how much work you might be letting yourself in for.

GRE (Generic Route Encapsulation) tunnels are the way to get round the lack of multicast support. GRE tunnels do support transporting IP multicast and broadcast packets to the other end of the GRE tunnel. And since a GRE tunnel packet is an IP unicast packet, so the GRE packet can be encrypted using IPsec.

So far, so good. However, when you configure a GRE tunnel between two routers, the IP addresses for each endpoint of the tunnel must be known by the other endpoint and must be routable over the Internet. This means that the routers must have static non-private IP addresses - something to be aware of when setting up a DSL connection with the provider for your branch office, as you’ll have to ask for static addresses. Not an issue: they’ll all offer it, but something to remember.

Room for Growth
The other, more significant issue may be one of scalability. You need to build these tunnels in a point to point arrangement - the most used design is a hub and spoke arrangement, with remote sites connecting back to head office. This has traditionally suited pretty well, with most traffic flowing from central to remote sites anyway. However if you need spoke to spoke connectivity, traffic will have to flow from spoke to hub, be taken out of one tunnel, put into another and sent to the next spoke. This will cause latency delays - depending on your applications this may or may not be a problem.

If you have a few sites connected like this it’s maybe no big deal. But try connecting a hundred or so to one hub router and you’ll see its config file grow. Each tunnel needs its own config, and you could end up with something so big you’ve trouble fitting it into the NVRAM of your router, and a nightmare to read through if you’re troubleshooting. And you’ll need a pretty powerful router, too, to do all this processing.

The alternative to this is obviously to build a full mesh of tunnels between all remote sites that might want to communicate, but again this way leads to a very tangled conglomeration of configured links.

Future Improvements?
For many companies, this is a perfectly feasible solution, for a few sites, if you just keep an eye on things like router utilisation. To get round the scaling issues, it looks like proprietary workarounds will be the only thing on offer for the foreseeable future.
Cisco has developed its Dynamic Multipoint IPSec VPN (DMVPN) solution (See white paper here) using something termed Multipoint GRE, which allows for the dynamic creation and tear down of GRE tunnels, initiated by the spoke sites (to get round the need for static addresses). This is pretty new, but is supported on most router platforms. Nortel has a solution specifically for routing protocol support in its Contivity Secure IP Services Gateways. Apart from that: better start typing your GRE commands.