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) 18.104.22.168 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 22.214.171.124 host 126.96.36.199
...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.