• Centralized management over several to many access-points.
• Unified access policies.
• Ease of deployment.
• Rogue AP scanning for PCI/DSS compliance.

Debugging what is going wrong with a VPN setup is difficult. The IKE protocol is “chatty”, and negotiates back and forth between the two ends for several rounds. The GUI offers not much help, it is either  UP or Down. Most of the real debugging happens inside the CLI.

One problem in particular that has always bugged me is that you need access to the end machines involved to initiate traffic across the link. The network admin typically doesn’t have direct access on the computers on either side of the VPN in order to initiate that traffic. I’ll show you a method that can be used to initiate traffic from that network as well.

Here are some basic steps to troubleshoot VPNs for FortiGate.

In IKE/IPSec, there are two phases to establish the tunnel. Phase1 is the basic setup and getting the two ends talking. Then IKE takes  over in Phase2 to negotiate the shared key with periodic key rotation as well as dealing with NAT-T (NAT tunnelling), and all the other “higher-end” parameters.

The first trouble shooting step is to verify your parameters are all correct and matching.

For Phase1, is the end gateway dynamic or static? Fortigate to Fortigate can use both Main and Aggressive modes for dynamic connections, but many other brands can not. In general, if you are supporting a dynamic IP client end, you will have to use Aggressive mode Phase1, so make sure that mode is set for dynamic clients. If this a static config, you should use Main mode for Phase1, which is a bit more secure on the initial handshake.

For Phase2, are both sides setup to use PFS? Replay Detection? Dead-peer detection? While most VPN setups include a set of encryption and hash algorithms, you only need one that are the same. The reason for the set is to offer many choices. In practice, just pick one that your base client supports and go from there. Now-a-days, AES256/SHA1 is probably supported across the board, and that is all I ever use. You don’t have to match the set of them exactly, each side just needs a common one to talk.

After that all checks out, we need to see what IKE is doing that is failing.

So SSH or console into the CLI.

If this is debugging a VDOM
(like in this case), you may have to switch into the root VDOM if you
are the system admin of the firewall as opposed to a VDOM admin.

fgt300C-fw # config vdom
fgt300C-fw # edit root
current vf=root:0

fgt300C-fw (root) #

as the diag commands are only available in the individual VDOMs or from the root VDOM for the system admin.

To enable debug logging on the console (should be default) do

fgt300C-fw (root) # diagnose debug console

To enable debugging output

fgt300C-fw (root) # diagnose debug enable

Phase1 debugging isn’t too useful. IKE/Phase2 debugging is where the problem almost always is. Lets turn on full debugging logs there.

fgt300C-fw (root) # diagnose debug application ike -1

Now, the problem I’ve always run up against is getting the tunnel to trigger to open up with traffic running on the link. You either have to conference in somebody with access to help you, or use this nifty trick…

Open another SSH connection to the FW CLI.  (If this is a VDOM, you’ll have to ‘conf vdom; edit “vdom3″ to get into
the VDOM context where the network is you want to troubleshoot).

Set the ping source IP address to be in the inside network of the host you are trying to troubleshoot..

fgt300C-fw (vdom3) # execute ping-options source 172.30.3.254

And now, ping away from the CLI in order to bring up the tunnel interface

fgt300C-fw (vdom3) # execute ping 192.168.0.1

(assuming 192.168.0.1 is an existing host only reachable via the VPN tunnel, and the ping service is allowed through the tunnel).

fgt300C-fw (vdom3) # execute ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=46.9 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=47.3 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=45.5 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=66.3 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=45.7 ms

--- 192.168.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 45.5/50.3/66.3 ms

The trick here is that you are source as the network you are setting up, which should trigger the tunnel to come up if it isn’t up already, and you can see real live traffic. I don’t know how many times I’ve been stuck on a conference call waiting for whoever had access to do something to get around to doing the test I asked of them.

Back in the first debug window, you should see a whole bunch of IPSec and IKE messages fly past on the screen.

You have to learn to pick out the lines that are important, and zone in on them as everything is flying by. Learn to pause the display (or do a quick ‘diag debug dis’ to stop the output). Scrolling back and zeroing in on the one error out of 100 lines is going to be your key skill here.

If all is well, you should get something about the SA being established with the SPI value (not important).

ike 3:MyVPN_GW:18690:MyVPN:49143: added IPsec SA: SPIs=939fc892/b54d030

and of course, if it is configured for SNMP, something like

ike 3:MyVPN_GW:18690:MyVPN:49143: sending SNMP tunnel UP trap

is a nice confirmation that all is well with the VPN.

If you are seeing a lot of errors repeating with Phase1, and you see messages like

ike 3:MyVPN_GW:18698: sent IKE msg (P1_RETRANSMIT): ....

Most likely the problem is a mismatch preshare key for the VPN tunnel, as it isn’t passing out of P1 (which doesn’t have much to negotiate).

Also check again if this is dynamic client (generally requiring Aggressive mode) or a static connection that probably should be set to Main mode, but could be using Aggressive Mode.

If you don’t have a common encryption alg/hash, you should see some errors like..

ike 3:MyVPN_GW:18707: no SA proposal chosen

As it can’t find a matching SA between the two ends using the same encryption algorithm/hash combo to encrypt the tunnel. Fixup the encryption alg/hash and everything should go better.

The hardest problems to detect are different keylength timers (you’ll just have to review them on both sides to make sure your P1 and P2 keylife timers are identical on both sides). Problems that you encounter with different timers show up as a VPN that works for a while, but then stops work, and won’t come up unless you bounce both sides. With valid timers the same on both sides, the VPN should keep up and key rollovers happen automatically.

Also, DPD may not always negotiate. One side may have it on and let a VPN connection stay up for a certain time until the timer kicks off and closes the connection for the lack of keep-alive packets. Make sure both sides have it on, or both sides have it off.

There are a few other error conditions that may come up, but these are the more common errors.

The most important thing with the low level debugging like this is to learn to pick out the important error lines from all the rest of the junk flying by. It just takes practice. You may want to deliberately break an existing setup just to see what happens. But once you can zero in on that one error line out of a 100 that is important, it will be a lot easier to troubleshoot what problems may come at you.

A Kickstart file basically answers the questions that pop up in the installer as the installer goes removing the need for human interaction. If an question isn’t answered, the installer pops up with the proper dialog, takes user input, and continues. I can pick and choose what information I want to populate automatically and which information dialogs I want the customer to answer. In my auto install ISOs I prompt the customer for a username and password as I want the users to enter that information.

When I was tasked with making an auto installing ISO for our customers I was able to create one quickly by using a kickstart file.

The process of making a CD is a bit verbose, and better handled by some of the how-tos out there.

But I’ll take your through my Kickstart file.

First are some of basic information about the system. These are fairly self-explanatory.

platform=AMD64
#System language
lang en_US
#Language modules to install
langsupport en_US
#System keyboard
keyboard us
#System mouse
mouse none
#System timezone
timezone America/Chicago

I disable root, to reflect the Ubuntu default. You can enable it by removing the next line, and setting it with the second.

rootpw --disabled
#rootpw jpDhuZtql4of4rfq

I do not automatically add a user, but you can with the next line.

#user johndoe --fullname "John Doe" --password changeme

I don’t think this does much in an Ubuntu Server install but I put it in anyways.

#Use text mode install
text

We’re installing not upgrading.

#Install OS instead of upgrade
install

Use the CD-ROM.

#Use CDROM installation media
cdrom

Where are we going to put the bootloader?

#System bootloader configuration
bootloader --location=mbr

Get rid of any existing partitions.

#Partition clearing information
clearpart --all --initlabel

Partition the disks using Ubuntu defaults (512MB swap, etc) This allows the ISO to work on whatever size disk you want. Linux isn’t great about using swap anyways, so 512 is plenty.

#Disk partitioning information
part /boot --fstype ext3 --size=200 --ondisk=hda
part swap --recommended
part / --fstype ext4 --size 1 --grow

Passwd information. I know… MD5… You can use something more secure if you wish.

#System authorization infomation
auth  --useshadow  --enablemd5

We need DHCP for some of the following steps, as I have no idea what type of network this will be run on. You can specify other info here if you want.

#Network information
network --bootproto=dhcp --device=eth0

My customers hate having UFW on. I don’t think this actually works yet in Ubuntu, so I also do it in a later script.

#Firewall configuration
firewall --disabled

X-Windows on a Server? No thanks.

#Do not configure the X Window System
skipx

And finally, we want to reboot after installing. This isn’t actually done, as we’re going to run a post-install script.

#Reboot after installation
reboot

Add additional packages to install. I install the fewest here, as I update in a later script, so why install a bunch of stuff only to update it later?

%packages
@dns-server
@openssh-server
gcc
build-essential

Here comes a a post install script.

%post

Mount the CD again, as there’s data we want off of the CD.

echo Making CD Mountpoint
mkdir -p /mnt/cdrom
echo Mounting CD
mount -t iso9660 /dev/sr0 /mnt/cdrom

Copy over a script that I’ve written that does updates and additional installs when the virtual machine is first booted.

echo Copying Firstboot Script
cp /mnt/cdrom/firstboot /etc/init.d/
chmod +x /etc/init.d/firstboot

Updated the init structure to run the firstboot script on boot.

update-rc.d firstboot defaults
echo Adding new Crontab

Add a custom crontab with some randomized sleep values.

cp /mnt/cdrom/crontab-template /etc/crontab

A script that I wrote that edits resolv.conf to point to the local bind server

echo Copying resolvfix init script
cp /mnt/cdrom/resolvfix /etc/init.d/
chmod +x /etc/init.d/resolvfix
update-rc.d resolvfix start 99 2 3 4 5 .

An updated sources.list with a closer mirror.

echo Copying Apt Sources
cp /mnt/cdrom/geeks-org-sources.list /etc/apt/sources.list

A new dhclient with the local bind server seeded.

echo Copying dhclient.conf
cp /mnt/cdrom/dhclient.conf /etc/dhcp3/

A new named.conf.options with some useful defaults.

echo Copying named.conf.options
cp /mnt/cdrom/named.conf.options /etc/bind/

Moving over vmware-tools for installation upon first boot.

mkdir /vmware
cd /vmware
echo Extracting Tools
tar zxf /mnt/cdrom/VMwareTools-*.tar.gz

Ejecting the CD.

echo Unmounting CD
umount /mnt/cdrom

Update the system.

echo Updating
apt-get update
apt-get -y dist-upgrade

And finally, reboot the system (sync for good luck ;) ).

echo Rebooting
sync
reboot

Now, as I mentioned before, there’s a firstboot script that I run that does quite a bit of work before the machine is finished. It does things like wipe out the SSH keys, install VMware Tools, remove and purge old kernels and install applications like MySQL, Apache, as required.

Well, that’s one of the tricks I have tucked up my sleeve, I hope it helps!

unless you don’t realize that its been enabled for you, in which case you’re likely to spend an hour bashing your head into something trying to get nfs to work. ufw is normally driven from the command line, although a GUI is also available.

you’ll need to have root privileges to run ufw.

the command to see whether or not ufw is running is ‘ufw status’. if ufw is not running, you should see…

$ ufw status
Status: inactive

if ufw is running, you’ll see something like this instead…

$ ufw status
Status: active

To                         Action      From
--                         ------      ----
Bind9                      DENY        Anywhere
22                         ALLOW       Anywhere
3306                       DENY        Anywhere
Apache Full                ALLOW       Anywhere

here, ufw is active, and is configured to deny or allow specific types of traffic. for example, connections to port 22 (ssh) are allowed from anywhere, whereas connections to port 3306 (mysql) are denied from anywhere. in addition to simple port numbers, ufw can recognize applications, such as ‘Apache Full’ (ports 80 and 443/tcp). for more information, see the Application Integration section of the man page.

the basic command for opening ports is ‘ufw allow 161′. ufw will also refer to the /etc/services file if you specify services by name, ‘ufw allow snmp’. either will allow connections to port 161 (SNMP) from anywhere.

these examples imply ‘from any to any’, but you can also specify source and host addresses. for example, ‘ufw allow from 10.0.0.42 to any port 161′ only allows connections to port 161 from a single address. you can also specify a netblock, such as 10.0.0.0/24. there are additional options, including specifying protocol (tcp or udp) and direction, and limiting or rejecting connections (instead of dropping them); see the man page for these and for more examples.

also note that rules are processed in order, and the first match wins. more specific rules should come first, followed by more general rules. you can insert a rule into the list using ‘ufw insert 2 allow snmp’ (here, into the number 2 slot, moving the current number 2 and following rules down one slot).

ufw isn’t a bad thing to have running on your ubuntu host, and is particularly important if its not behind a network firewall. but if you’re having problems getting a new service running, it’s probably something worth looking at.

When you have a VMForge VDC and control your own area of the FortigateFirewall in front of your VDC, you can setup a secure VPN connection with several different technologies.

If you want to use the built in VPN client in Windows or Mac OSX without installing any other VPN Client software, then L2TP over IPSec is the way to go. Although you will need to escape out to the CLI of the FW to complete this setup.

This is only one way of doing things. There are many options along the way that may be required of more advanced setups, such as using SSL Certificate authentication in order to provide two-factor authentication to comply with certain security policy requirements (ie. PCI-DSS requires this).

Step one: Setting up users.

Most people starting out use local user authentication on the FW. While there are more advanced options available, such as authenticating back to a Windows Active Directory server, or RADIUS or LDAP, using the local user database in the firewall is simple and straightforward.

Login to your VDC’s FW admin area.

Open up the User menu, go to the User subarea, and the User tab.

(Fortinet could use some better UI descriptions sometimes.. :-)

Click the “+ Create New” user button and supply the username/passwords for each new user you want to create. I generally use full email addresses of users as they are most used to that now-a-days for their usernames. Future remote authentication options (ie. RADIUS) may influence what you use for usernames here.

Step two: Create a usergroup. 

Next, still in the User menu, heda to User Group->User Group. And click the “+ Create New” here. Name your group something meaningful. Select all your new users and click the ➜ button to move them to the Members area and click OK.

Step three: Create the IPSec wrapper.

Now for some VPN setup!

Head into the VPN Menu, open up IPSec and choose Auto Key (IKE). There are two phases to IKE and we need to start with Phase 1, and then Phase 2. Also, both Windows and Mac have strong preferences for certain cryptographic choices, so we’ll be changing them from the defaults.

Click (+ Create Phase 1) to start.

Name your VPN’s Phase1 some name meaningful. I usually either end the name in P1 or GW (from some old training of another vendor’s preferred naming scheme way back when).

For Remote Gateway: Choose “Dialup User”.

For Local Interface, this is your WAN interface for your VDC. Most likely this will look like VLAN_EXT_517 and the _EXT_ part of the name signifies that is the external WAN interface for your VDC.

Leave Mode at Main, and Authentication Method as Preshared Key.

The preshare Key is very important, having this longer and more random gives you more security. This will also have to be distributed out to each user. While the user passwords are also signifigant, the preshare Key can not be changed without rekeying all your users. I’d recommend between 12 to 16 random characters. Make sure to note what you choose for later client setup.

Now choose the Advanced button to change away from the defaults to make Windows happy.

For the P1 Proposals, you’ll want AES256/MD5, 3DES/SHA1 and AES192/SHA1 (clicking the + button to add a spot). You’ll want DH Group (Diffie Hellman) group 2. Leave the keylife here the default 28800.

Click OK to get back to the VPN area and now click (+ Create Phase 2).

Name this something meaningful, I use the same name as before with P2 or VPN on the end.

For Phase1: choose your existing Phase1 name.
And now for the Advanced section.

For the P2 proposal, you’ll want AES256/MD5, 3DES/SHA1 & AES192/SHA1 to make Windows happy.

Leave replay detection on, but turn off PFS. Another item Windows7 especially wants is for the P2 keylife to be both bytes and seconds, so open up Keylife and select Both with a keylife of 3600 seconds and a rekey bytelength of 250000 bytes.

Everything else can be blank, so go ahead and hit OK here.

Step four: Setting the right L2TP mode. 

For whatever reason, Fortinet moved L2TP setup out of the GUI of previous versions into CLI only on the current code revs.

You can either ssh directly, or go to the Firewall’s Dashboard, and click on the CLI console application on the Dashboard in order to continue. First set the IP addresses used by the VPN server.

config VPN l2tp
set eip 192.168.16.1
set sip 192.168.16.15
set status enable set usrgroup "VPN Users" end

This last name has to match the User Group name you first used.

The IP addresses here have to be in a different subnet than your current private range IP addresses used inside your VDC. It doesn’t matter much which of the RFC1918 space you take, just take a small chunk somewhere and remember what it is.

Next we need to set the mode.

config VPN ipsec phase2
edit "My L2TP VPN" set encapsulation transport-mode end

Where “My L2TP VPN” matches the name of the Phase2 proposal earlier entered.

And finally type “exit” to get out of the CLI Console as we are done in there.

Step five: Create the Firewall Policy for the VPN.

Now we need an address object to contain the L2TP users’ IP address range, so head over to the Firewall->Address section. “+ Create New” address, and call it something like L2TPClients. For the range we picked above, the syntax to type in would be 192.168.16.[1-15] and click OK

Finally we get to create a firewall policy to trigger the VPN!

In the Firewall->Policy section, “+1 Create New” a new policy.

This will be the policy for traffic going out over the VPN, so

• The Source Interface is your internal interface, so something like VLAN_517_INT.
• The Source Address is the internal address pool, which probably looks like LAN_VLAN_507.
• The Destination Interface is your internal interface, so something like VLAN_517_EXT.
• The Destination Address is your address pool we created, so choose the object L2TPClients.
• Service can be ANY
• Action must be IPSEC
• Choose VPN Tunnel to be the P1 proposal you setup in Step 4 and Allow in & out bound traffic.

Click OK to move along to create the matching inbound traffic over the VPN.

• The Source Interface is your external interface, so something like VLAN_517_EXT.
• The Source Address is the address pool we created, so choose the object L2TPClients.
• The Destination Interface is your internal interface, so something like VLAN_517_INT.
• The Destination Address is your internal address pool, which probably looks like LAN_VLAN_507.
• Service should be a list of protocols that you want the VPN users to be able to do (RDC? MS-SQL?)
• Action should be Accept (not IPSEC here, only used for outbound VPN policy).

Click OK to finalize the VPN setup.
Complete!

We are done with the VPN setup, and all it takes is to setup the client and dialin.

The next blog post will be client setup for Windows/Mac and testing.

What is a VPN?

A VPN (Virtual Private Network) is a way of creating a secure connection to and from a network (site to site or LAN to LAN) or computer (node based VPN). It is usually encrypted end-to-end and lets you route traffic securely over a direct channel into the remote network. There are usually separate policies applied on the VPN connection letting more remote services in that you wouldn’t let in through the primary internet facing connection (ie. MS-SQL server administrative access, FTP services, etc).

IPSec PPTP vs. L2TP over IPSec vs. SSL/VPN vs. many others.

IPSec

is the basis of many modern secure VPNs. It is the most complex, and feature-full of the choices. It also usually requires special client software loaded on the remote client workstation. Example client software either comes from the Firewall Vendor directly (either as a purchase, or bundled in software), or other software vendors and freeware solutions exist. Popular commercial client software is VPN Tracker for the Mac, or The Greenbow for Windows. Free client software for the Mac is IPSecuritas or Shrew for Windows. Other options are setting up the connection site-to-site in your local firewall to your VDC network. This assumes you already have a pre-existing site firewall that supports site-to-site VPNs though.

With an IPSec tunnel, the client software can be setup to automatically connect as needed, or you can also bring up the tunnel on-demand with whatever controls the software gives you.

Otherwise, it sits in the background without you having to interact with it.

PPTP

PPTP is a solution developed by USR and expanded on by Microsoft for Remote Access VPNs. There have been some security concerns with both the length of the hash of the LANMAN password hash used with this solution, as well the actual encryption algorithms employed. You can read up more on the problems encountered here.

Security_of_the_PPTP_protocol

L2TP over IPSec

L2TP merges two different technologies from different areas of Networking into a solution that has replaced PPTP. This solution has client software built into Windows (XP and up) and Mac OS X (10.3 and up) that makes it simple to choose, although the real setup can get a little complex. Troubleshooting this solution can be difficult, as the windows client gives basically one error code for any problem.

This is a Dial Up on Demand connection at the client end. Each time that you want to connect, you’ll have to initiate the VPN tunnel setup and make sure it connects before doing what you want across the VPN tunnel.

SSL/VPN

SSL/VPN is a VPN solution running over SSL/TLS encrypted HTTP traffic. I think the perceived acceptance of this solution is that it is easy because it is just SSL and it is just HTTP. The reality of this solution is that it depends a lot on what you want to do, what software is installed on the client end (ie. Java may be required, which not many people install by default any longer), and it operates in 3 different modes.

The first mode is connecting to the VPN gateway as a web proxy into the internal network (ie. so you can access an internal web site). Depending on software version, telnet proxy and ssh proxy may be available. This is all that is allowed though.

The second mode is download a JAVA app that will let you do port forwarding through the VPN tunnel. Ie. More like a traditional VPN that you can access restricted services such as MSSQL server that you wouldn’t let out publicly.

The third mode is via special client software installed on the workstation (is very vendor specific), which again will let you do port forwarding through the VPN tunnel like a regular IPSec client and access remote protocols like RDP and MS-SQL over the encrypted VPN tunnel.

OTHERS

Other solutions exist such as OpenVPN, ssh port forwarding, OpenSWAN, etc.

Our firewalls only support the methods I talked about above, not these alternatives, although that doesn’t mean that you can’t deploy a firewall gateway virtual machine utilizing your favorite software within your local VDC as well (I’m sure I’ll be doing a blog post about this kind of setup later).

Overall, the IPSec VPN is the most secure and easiest to use, but is the hardest to setup and required client software to be installed. L2TP over IPSec is popular because the client software is already installed and easy enough to use.

Either solution does work well, I’ll be detailing more details on setting up either in further blog posts.

I am using FTP-SSL in passive mode, with explicit SSL.  I do that because most of my users run their computers behind some sort of firewall. This sometimes means that their data channels get blocked by their firewall. The symptom then is that they can connect, but can’t send or receive files or list directories. So I have them use passive FTP in their client software.

I put all of my Windows servers behind a firewall. Since the FTP session is encrypted, the firewall cannot look into the content of the control channel and allow the ephemeral data connections through. To be clear: passive FTP with SSL will not go through your firewall without specific rules allowing the data channels.

To get around this, allow a specific port range incoming in the firewall, and configure IIS to use that same range. I am using ports 55000-56000 for this example.

Configure the firewall:

Allow TCP/21 inbound from all
Allow TCP/55000-56000 inbound from all

Configure IIS:

Assuming you have a FTP site already set up in IIS without any encryption and you now want to secure it. Here is what to do:

Create an SSL Certificate:

If your site is already using SSL, you can probably use the SSL certificate you already have.  Otherwise, create a self-signed SSL certificate on the server.

In IIS Manager, select the server in the left-hand pane. Select Server Certificates from the IIS section, and click “Create Self-Signed Certificate”. Name it “Self-signed certificate for FTPS”

Set the Data Channel range for FTP:

Select the server in the left-hand pane. It must be set server-wide. If you select the FTP site here, the Data Channel Range field will be grayed out. Enter the same port range you have allowed in the firewall (55000-56000). If your firewall is doing NAT, enter the external IP address of the firewall here.

Restart the Microsoft FTP Service:

Now you need to restart the FTP Service for the setting take effect. If you restart the FTP Server within IIS manager, or even restart the whole of IIS, the FTP Service is unaffected. Open the Services control panel, right-click “Microsoft FTP Service”, and select “Restart”.

Configure the client:

Set your web client to use passive mode and Explicit SSL. Now it should work.

Today Rainer Enders published a rebuttal op-ed in support of VPNs. Mr. Enders argues, in part, that one of the biggest issues facing companies was hackers in general and specifically the protection of all corporate data, both on the systems where it is stored and when it is in transit. As more and more employees work not only from home but from WiFi hotspots in coffee shops, fast food restaurants and hotel rooms around the world, encrypting sensitive information end-to-end has ever-increasing importance.

Mr. Enders Op-ed is much more in touch with the way businesses need to operate in today’s networked world. Yes, there are corporate features and functions that can be pushed off physical corporate computers and onto the hardware at hosting companies. This does not mean that all information can or should be placed in fully public cloud environments and it certainly doesn’t mean that your information in “the cloud” is safe just because you can account for all your employees laptops and smart phones.

Corporations do not need to make either/or choices. Less sensitive, collaborative projects might be best hosted at massive cloud providers while the most sensitive information needs to be more carefully protected on private servers only accessible via the local corporate network and remote access VPNs.

At least once a week I work off-site. While I don’t need a VPN to reach my email, I do use a VPN to get access to in-house documents and systems. I use VPN Tracker from equinux on my Mac. It is simple and easy for both me (as an end user) and our IT staff that has to support us normal users.

Because we use them ourselves and understand the benefits, we made sure our new vmForge VDC product line supported both site-to-site VPNs for remote offices *and* desktop (end user) VPNs for remote workers. vmForge VDCs configured with Fortigate firewalls will support end-user VPNs and ipHouse can set them up and manage them for you.

ipHouse has never outsourced any type of operations prior to this move. This bold move in efficiency makes ipHouse the premier facility manned and operated 24×7 by a private contractor.

Over the last few months, we have been negotiating with The Wonka Candy Company, directly with president Charlie Bucket for the upgrade to our operations. This might come as surprise to many of you, but Wonka Industries has been branching out for years into other services besides making some mind-blowing, awesome candy. (Though it must be noted, their expansion into day care facilities failed miserably.)

Among the changes to our data center, we will also be upgrading our on-site security measures, our fire suppression solution, and our emergency elevator escape system.

We have also negotiated our new off-site storage with TheCandyMountainSecureStorageServicesCompany(tm) (TCMSSSC). This is great news as it helps us achieve the elusive 5 nines Gobstopper rating for data centers.

Security

The new security measures are sugary sweet, and truly state of the art. We’ll not only be using the Oompa-Loompa workforce for the operations of the data center, but we’ve also contracted with Chocolate Security Services to supply us with their Oompa-Loompa Security Force agents to guard both the front and rear entrances.

We have also initiated changes to our security card system by moving away from easily bypassed proximity cards to Snozzberry Scented Access Cards (SSAC). Digital security systems are easily bypassed because of the single 1s and 0s used in binary computing, the SSAC, though, is purely analog allowing for an infinite combination of scents for authscentification.

Emergency

Our updates to the fire suppression system will be happening during the month of April, 2011 as we move away from the current dry pipe solution to the very first rollout of the Bubble Fire Suppression Solution (BFS) from Bucket Services, Inc. Instead of water (used in dry pipe), Halon (poisonous), or FM200 (where did the air go) uses in the past, the new BFS system actually uses bubbles filled with a secret gas to take the fire up and away from the servers, equipment, and personnel in the facility. Mr. Charlie Bucket says “This is by far, the best system to move fire away from expensive equipment and up into the cutting fans, where the fire will be chopped into smaller, more manageable pieces and mixed into Atomic Fireballs and Big Tex Jelly Beans.”

To handle any impossible emergency events in the data center, the Factory Airation Individual Lift (FAIL) subsidiary will be installing their patented Great Glass Elevator Emergency and Security Cylinders throughout the facility, including both entrances. These can be used by oompa loompas and humans alike to escape an unlikely flood from the new HVAC, which uses hundreds of thousands of gallons of chocolate to remove heat from the data center. They may also be used for security; when a human is determined to be a “bad egg” in the “veruca trap”, they can, and will, be shot into orbit.

Tickets

When customers are coming down to work on their network after these new measures are put into place, a lottery of golden tickets will be used to create some excitement. By working with our customers through multiple – multiple choice questionnaires, we have determined that this will be the most effective way to for their system admins to stop by the data center to patch and update their systems regularly. The winning Golden Tickets Winners (GTW) give the system admins an exclusive 5 minutes alone to wade into, or relax next to, our chocolate waterfall.

While nobody wants to have to come in to fix something broken, this lottery system is designed to add some excitement back into the process.

This is something that has been in the works for some time. If you currently have an access card issued in the past five years, you may already be a winner. Fold your access card LENGTHWISE in half so that the printed side ends up in the middle. You will feel a snap as the card’s contents are revealed.

If your card does not reveal a golden ticket, you are not a winner and will no longer be able to cross the new security perimeter to access your server. You are welcome to try again. Additional access cards are available individually or by the case. Contact your sales representative with any questions or to order.

As an added potential benefit; customers visiting our data center to work on their equipment might win a free candy bar, chocolate coated Windows Server 2008 R2 (the chocolate coating makes it go down easier), apple iPod (tastes like real apples, shaped like a real iPod), or even a full and exclusive tour of our data center by boat.

Finally, with all of these new changes, we will be rolling out a new logo for our Data Security Center Solution Service, seen just below.

Hard Shell Data Center Services

A gallery of pictures of a senior Oompa-Loompa doing an inspection of our current facility is also linked below.

Inverse Investigative Techniques

Reverse Inverse Investigative Techniques

Type Testing of Crash Cart Services

First Test of Upper Rack Security System

Oracle Hands Senior Oompa-Loompa Worker a Wire

Oompa-Loompa on Break

We wish to thank all of the Oompa-Loompas who let us take their photos as we continue to integrate their services into our company.