Navigating the SoftLayer cloud and VPN

TwitterFacebookGoogle+LinkedInRedditStumbleUpon

With the acquisition of SoftLayer by IBM, many of us, including myself, are adjusting our point of view on what a public cloud offering is and what can be done with it. Fundamentally, the technology is the same as what I’m used to dealing with at IBM. It’s SoftLayer’s philosophical approach that has brought about the adjustment to my point of view.

This blog is the first of many where I’ll walk you through the common cloud technologies and discuss how SoftLayer conceptually approaches them. The purpose is to help those of us who are used to dealing with IBM enterprise services, or even other public cloud providers, relate to the SoftLayer way of approaching cloud. We’ll discuss various subjects in order to help you move forward with SoftLayer and identify your business needs. Now, let’s start with SoftLayer’s VPN as an offering and what capabilities you can deploy.

VPN for administration

From an IBM point of view, when someone says “VPN,” the first thought is bridging a shared intranet from one location to another. So when I saw that SoftLayer offered a VPN connection, my first reaction was to start designing an architecture utilizing that connection to expand an on-site network to the public cloud. Honestly, it took a couple of explanations to understand that the provided VPN wasn’t designed for this at all. SoftLayer’s VPN focus is more on system admin—using a secure VPN connection to manage systems via services such as Microsoft’s Remote Desktop Protocol (RDP) or a SSH tunnel to a Linux server. SoftLayer provides two types of connections for this type of machine administration. The first is for simple user-based VPN access. SoftLayer has setup a SSL VPN connection and a PPTP connection as an extension of a customer’s account. The second method is to order an IPSec tunnel for a site-to-site connection. Don’t be confused because site-to-site connection is still only for admin traffic to manage systems in the SoftLayer environment.

VPN for back office communication

Now that you understand what SoftLayer offers for secure admin tasks, let’s take a look at the two VPN offerings for back office traffic between servers and applications.

The first is the Fortigate Security Appliance (FSA). The FSA is a Fortinet Hardware Firewall like all of SoftLayer’s managed dedicated firewalls. The main difference is that a client will have direct access to the firewall when purchasing a FSA. The direct access will give a client full control of the FSA’s capabilities including IPSec and SSL VPN options.

The second option is the Vyatta Gateway Appliance (VGA). This appliance utilizes SoftLayer’s current dedicated server capability with the Vyatta Network OS to provide a network gateway capable of complex network routing, firewall, and VPN tunnels. Once deployed, the user will have full access to the command line interface and the graphical user interface on the gateway appliance.

Design your connection

Understanding the proper way to utilize these VPN offerings is just as important as knowing they are available. With that understanding, let’s take a look at some possible deployment options. Figure 1 shows the simple design of connecting all of the public networks based systems in SoftLayer to a user data center utilizing a Fortigate Security Appliance (FSA) IPSec VPN tunnel.

Figure 1: All public network traffic in VPN secured with FSA

The design in Figure 1 completely secures a SoftLayer user’s cloud environment as an extension to a remote location.   Everything is encapsulated by the VPN, and will be an extended part of the data center’s network.

Now, while this design is a direct and simple way to do things, most of you require a more complex means of cloud management, which is where the Vyatta Gateway Appliance (VGA) comes in. The user can secure the public network in SoftLayer using VGA, and they can also set up custom routing between servers on the public and private network. As you can see in Figure 2, the VGA manages the VPN traffic from the user data center and the routing to the private network.  This management enables the designing of a tiered network environment with access controls to the different zones.

Figure 2: VGA secures public VLAN 1 and private network VLANs from public VLAN 2

Both of these scenarios will allow you to extend a secured environment to your cloud infrastructure using the tools that SoftLayer has provided. And many of us who are used to working with IBM will understand the correlation quickly, but for those of you wondering how this maps to other public cloud offerings; let me provide a quick offering comparison:

As IBM moves forward with SoftLayer we will continue to find new ways to help our business partners and customers achieve a creative, yet efficient, use of SoftLayer’s infrastructure as a service (IaaS) offerings. So please keep tuning in to these blog posts as we continue to explore these offerings.

TwitterFacebookGoogle+LinkedInRedditStumbleUpon
Comments: 5
Steven Schiffer

About Steven Schiffer

Steven Schiffer is an advisory architect for the IBM Global Technology Services (GTS) Global Cloud Ecosystem team.
This entry was posted in Managing the Cloud, SoftLayer and tagged , , , , , , . Bookmark the permalink.

5 Responses to Navigating the SoftLayer cloud and VPN

  1. Pingback: Navigating the SoftLayer cloud and VPN - Thoughts On Cloud Blog - Blogs - Tivoli User Community

  2. Pingback: Navigating the SoftLayer cloud and VPN - SkyOffice Consulting | SkyOffice Consulting

  3. Pingback: Nov 12 – Today’s Handpicked Cloud News and Press Releases | Cloud Computing Wire

  4. @ajcronk says:

    Thanks for the post, Steven. We also blogged about our SoftLayer inter datacenter VPN setup.
    http://blog.tempo-db.com/post/50442490065/archite

  5. Mr Dev Ops says:

    As a developer I have used the Vyatta Gateway Appliance in Soft Layer.

    What I like about this is Vyatta Gateway Appliance gives the developer a more DevOps option for setting up networks.

    This allows a developer to set up firewalls, IPSec tunnels, and NAT, along with DNAT.

    The challenge though is Vyatta Gateway Appliance is opensource. So, there is a pretty steep learning curve.

    I eventually got it to work, but it was kind of a trial and error.

    Plus, do we know if Vyatta Gateway Appliance, is a viable platform for a production.

    We are going to try, but we aren't sure.

    Maybe, IBM can become a member of the Vyatta opensource to help guide the project.
    This could be similar to what they did for Apache and Eclipse.

Comments are closed.