Introduction
Updated 6/19/2007: Corrected PPTP information
The Park City Marriott, one day before the opening of The Sundance Film Festival:
Sheila was tall, pretty, and expensive-looking. “So what do YOU do for a living?” she asked.
“Nothing interesting,” I replied.
Scoff if you will my brethren, but on a scale from “One” to “Boring,” our noble profession ranks just above “Collectible Stamp Salesman” to these strange denizens of the Film Circuit. To prove my theory, I present an alternate line of dialogue:
“Well, I had three weeks to create a mixed-environment network of around 200 machines connected to what I have been told was an unreasonable amount of very expensive switches which linked to each other using STP…” I said.
“Stone Temple Pilots?” she asked.
“No. Spanning Tree Protocol,” I replied.
To Sheila, this would not have gone over well; nor would my purgatorial debate over whether to use PPTP or IPsec.
I had pretty much hit the home stretch in the days leading up to the festival opening. The network was in place, with both the Media editors and the Office personnel functioning at acceptable levels. Productivity was up, and there were few complaints. All that remained was to implement the rest of the wireless network, and to create a VPN tunnel to their corporate headquarters, so that the massive amounts of information that were now being generated in ever-increasing volumes could be shared and archived back in California.
By this point, I knew that I would never be entirely satisfied with the network; no true network engineer ever should. Standards are approved, and new
methods and protocols invented, on an almost-daily basis. Failing that, there are always about six thousand ways to do any one thing. You’ll never have a
network that’s the end-all and be-all, because network development is a never-ending story. The best you can do is adapt your techniques to the situation at hand while keeping a sharp eye on the available technology
The VPN network had been in the back of my mind since the day I accepted the job. I made every decision regarding the construction of the network with the established protocols and policies of their home network in mind, so that my job would be much easier when it came time to establish the VPN tunnel.
VPN
Figure 1: An Elementary explanation of VPN.
A Virtual Private Network is basically a means of sharing data between a private network and a client over public space. Typical methods of connecting a VPN include using a modem to dial-in to the VPN server (Dial-Up VPN), where the phone line represents the vulnerable public space, and connecting to the VPN Server through the Internet. Once connected to the VPN, the client has access to all of the network resources they would if they were physically connected to the LAN.
There are many… many different types of VPN (and more are invented daily), but we shall focus on the two most-often used: PPTP and IPsec.
Figure 2: A PPTP Client is included on all current Windows releases.
PPTP (Point-to-Point Tunneling Protocol) is by far the most popular and widely used implementation of VPN. Chances are, if you own a Windows-based machine that’s less than twelve years old, YOU have a PPTP client built in—they’ve been featured in every release since Windows 95.
PPTP is run with two connections:
a Point-to-Point Protocol (PPP) session using the Generic Routing Encapsulation (GRE) protocol to connect the client, and another connection to initiate and manage that session. The advantage of using PPTP is
obvious: everyone has it and it is easy to configure. This also plays into its disadvantage: it’s very common, and therefore easy to hack. (Not to mention the fact that PPTP authentication methods such as MS-CHAP are a potential weak link.)
IPsec is a set of protocols used for authentication and encryption. Basic IPsec doesn’t bother to emulate a point-to-point private connection and therefore only supports routable protocols such as TCP/IP. However, many IPSEC implementations (especially for PC client remote access) implement some kind of layer-2 emulation via encapsulation for maximum flexibility and compatibility.
For our present application of connecting one network to another (using IPsec “Tunnel” mode as opposed to its “Transport” mode), IPsec would be more secure. However, the complexity of that security will come at the cost of processing power and bandwidth.
VPN – more
Both VPN types have their advantages and disadvantages. The decision about which VPN type to use was ultimately not up to me, since the VPN server was
created and maintained in California. In order to understand their choice, you have to look back at the network to which I would eventually apply one of them. This incredibly expensive (and now lavishly decorated—from the outside chassis to the desktop themes) network was a temporary one. The project could continue for up to two or three months after the festival, but in all probability, the whole building would be emptied and its contents placed on a series of trucks and shipped back to the west from whence they had come. There were no Ethernet ports drilled into the wall. There were no
paintings hanging. There was a lot of furniture and exotic drapery, but with enough movers, all that could be wrapped up and hauled away in a matter of minutes.
Maximum security was not a high priority. Speed and practicality were. Things were happening NOW. Even today, looking back on it years later, I think of how everything hinged on the passing moment. Under these circumstances, I chose PPTP. (This will completely contradict my rationale in choosing a wireless encryption method, but as with everything I’ve written in this series, there was a method to my madness.)
Figure 3: The VPN Server Role.
As shown in Figure 3, it would have been possible to add a VPN Server to the Domain Controller/DHCP Server by assigning it a Remote Access Server role. The company headquarters had already created the PPTP Server in California, so it was my job to create the PPTP Client. The PPTP VPN connection had
to be established in such a way that their Domain Controller and ours would trust each other through our respective firewalls. Their tech was responsible for properly configuring the Remote Access Server Policies, and I was responsible for completing the tunnel.
On the HQ end, their technician had to set up, not only a VPN Server, but also a WINS server, which is used to allow VPN clients to browse the remote network.
The goal on my end was threefold: establish a link between the network I constructed and the HQ network in California, set up the Pix 525 so that the link could function correctly, and ensure that the VPN Client used NetBIOS to send its name and IP Address to the WINS server. As opposed to having each Client establish VPN to HQ individually, a VPN connection was established from the Domain Controller.
Setup of PPTP through the PIX firewall (i.e. to let a VPN client within the network pass through the firewall to access network resources on a remote
VPN server, as opposed to PPTP to the PIX firewall, in which case the VPN server would be located in Utah and not the HQ in California), differs depending
on which version of the firewall you are running. (A list of setups by firewall version can be found at Cisco’s site.)
Since I was using version 6.2, it was necessary to define a static map containing the inside IP address of the Domain Controller and the outside IP address.
pixfirewall(config)#static (inside,outside) 163.198.1.4 192.168.1.27 netmask 255.255.255.255 0 0
As mentioned earlier, once a GRE session has been sent from the client to the server, a second session is sent from the server to the client to manage the first one. So the next step is to configure the Access Control List to allow the connection from the VPN server through the PIX firewall:
pixfirewall(config)#access-list acl-out permit gre host 163.198.1.20 host 163.198.1.4
…and apply it.
pixfirewall(config)#access-group acl-out in interface outside
What basically happens on the client side is that they’ll make a request for a server or other machine that’s not part of our Utah Network Range. Any request to an IP address outside of our network range gets sent to the Domain Controller, which acts as a gateway between the Clients and HQ, now that a VPN connection has been established between the HQ and Sundance network.
Mary from Marketing, for example, would attempt to access the HQ Marketing fileserver, which exists outside of our network range. That request, just like an Internet request, gets forwarded to the Domain Controller, which then sends it to HQ.
Figure 4: VPN Client Setup.
This is where sharing the same User Database, Domain structure, and Group policies as the company HQ saved about a thousand hours worth of work. Under the Remote Access Policy for the VPN Server at HQ, Clients maintained the same privileges they have on our Utah network… which were the same privileges they had at HQ. So when Mary, from Marketing (for example) accesses the Remote Marketing File Server, she has access to all the files and folders she would if she were still back in California; and this with a bare minimum of effort on my part.
Wireless
The last shoe to drop was the Wireless setup. I had been hanging an AP off of one of the switches to cover the needs of the few “for the time being.” Now that the festival began, and all hands were on deck, I decided the network needed as much flexibility as possible. (There was no telling who would show up at any given moment. Maybe Clint “The Man with No Name” Eastwood would stroll in with a wireless PowerMac and start getting pushy…)
There are two major types of wireless encryption: WEP and WPA.
At the time I was creating the network, WEP typically came in 64-bit 10 hex digit or 128-bit 26 hex digit configurations. WEP, like PPTP, became very popular because of its low processing/bandwidth overhead and its widespread availability. Unlike PPTP, however, there is no modern advantage to its availability, because WPA is just as commonly used.
There are two types of WPA (Wi-Fi Protected Access) authentication: one in which a group of Clients, such as those in our network, can be given one Pre-Shared Key (PSK)
that is identical and will work for all Wireless Clients; and the other, in which a server assigns an individual key for each client.
While having a single PSK for an entire group of users opens the Wireless network to the same type of vulnerability as WEP, TKIP (Temporal Key Integrity Protocol) is far superior, in that the keys are randomly changed while in use.
I decided to go with WPA TKIP PSK, as opposed to the less popular (from a security point of view) WEP, while simultaneously defending HQ’s choice of the less-secure PPTP VPN setup. The reason was that nobody really knew, or could guess, of the existence of the VPN tunnel we had created—or a network of the magnitude I’d created
at all; however, just about everybody in town would be snooping around for a free Internet connection. Even if the SSID wasn’t broadcast, there were bound to be endless users running around with Netstumbler looking for their chance to check up on Friendster. WEP was too common and easy a nut to crack.
It wasn’t worth the time and effort of setting up or connecting to a RADIUS server. Your average Wi-Fi roamer would be easily dissuaded by strong TKIP encryption. So it simply became a matter of choosing the best physical layout for the access points, sharing the key, and letting the users loose.
Figure 5: The AP Layout.
Our final chart shows the layout of Cisco APs for the Wireless Network. I placed one in each of the four corners of the room, as well as a central
point in the middle of the server farm. DHCP was disabled on all the access points, as all DHCP tasks were being handled by the Domain
Controller/DHCP Server. I merely assigned a static IP Address to the access points, enabled WPA TKIP encryption, and shared the key with the people who required it.
At some point, during the height of the festival, I took the added step of filtering the Clients through their MAC addresses… just to be
on the safe side. For those who have the Comments box open and are ready to flame, I should point out that, yes, I am aware that it’s very easy to spoof MAC addresses; however, my only intention was to discourage “doorknob rattlers”. A properly-equipped war driver can have a WEP key cracked in minutes. But when they see a strongly encrypted wireless network with both TKIP PSK and MAC filtering, they are more likely to keep looking for a WEP or “Open” network.
Conclusion
The next couple of weeks can only be described as a dizzying circus. The build-up before the festival was nothing compared to the spiraling maelstrom of activity that occurred during it. Productivity rose ten-fold as distribution deals were made, films were re-cut and edited, and the marketing and design teams went into full effect—soliciting actors and directors alike, along with the journalists that had come to weigh in on all these hundreds of would-be “next-big-things.”
On the networking front, there was a temporary outage because of an electrical grounding problem. The servers held because they
were connected to backup power supplies, but some of the client machines were not so lucky. The access points were plugged into outlets on the ceiling lights, which were connected, most fortunately, to an old backup generator that looked like something out of Rocketman. This meant the battery powered laptop users didn’t miss a beat, while the Media clients were out half a day’s work (the other half being available on the Media backup server).
There was the occasional problem of a user not being able to access resources over the VPN (mostly due to changes in the Remote Access Service policy on the HQ end). Every hung-over morning someone would forget his or her password. By and large, however, the network held. My weekend trip up to the mountains had been a success.
The Media and Office teams kept working for another month after the festival. There was a lot of work to be done. Films that had been signed to distribution
deals had to have the intro and credits altered. Some of them required additional editing. Contracts had to be drawn up, sent out, received, and archived
by the legal department. There was constant traffic between the HQ and Utah accounting departments… But for the most part, the lion’s share of my own work had been completed thirty days earlier.
I remember staring out the big glass windows of my room at the Park City Marriott. Thousands of trees were angling their way up the side of what looked like the largest mountain in the universe from where I stood on the third floor of the hotel at the bottom of it. I imagined half of the executive staff calling in sick and taking one more dash down the slaloms. I knew for a fact that the Marketing team would have to work three times as hard.
“What’s this mountain called, anyway?” I asked.
Mary was still towel drying her hair as she squinted out the windows. “I think it’s Pike’s Peak,” she said.
On a normal day, Pike’s Peak is in Colorado. Today, I was more than happy for it to be wherever the Marketing Director wanted it to be.