![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This article describes two new features of IBM SmartCloud Enterprise version 2.0:
- Multiple virtual private network (VPN) tunnels into an IBM SmartCloud Enterprise data center.
- Multiple virtual local area networks (VLANs) in each data center.
Each of these features is examined in detail.
It is important to understand that this feature of the IBM SmartCloud Enterprise environment has security implications which need to be fully understood by the consumer. The VPN and VLAN capabilities of IBM SmartCloud Enterprise are options that provide a transport extension service and, while it does provide the additional security of encrypting network traffic over the Internet, it is not intended as a complete security system.
For example, these features do not provide firewall capabilities that a client may require and do not encrypt the network data between IBM SmartCloud Enterprise instances.
The goal of this article is to describe the VPN and VLAN features and capabilities. It is the client's responsibility to fully understand the architecture being deployed in the cloud and all security requirements of that deployment. Clients should take care not to expose data that needs to be protected (such as confidential corporate information, client information, credit card numbers, addresses, etc.).
IBM SmartCloud Enterprise is an infrastructure as a Service (IaaS) offering that provides an enterprise-class virtual server cloud environment. By default, virtual machine instances are provisioned with IP network addresses that are accessible through the Internet.
Optionally, enterprises can sign up for a virtual private network (VPN). The optional VPN provides an Internet Protocol Security (IPSec) based, point-to-point communication channel between the enterprise's network and one of the IBM SmartCloud Enterprise data centers. Network communication over the VPN still travels over the public Internet but is encrypted prior to leaving either the enterprise network or the IBM SmartCloud Enterprise network and decrypted upon receipt at either end, thus allowing for secure communication of data.
By default, when the VPN is established in the IBM SmartCloud Enterprise environment for the enterprise account, a single private virtual local area network (VLAN) is also provisioned for the account. This VLAN provides an additional layer of network isolation for instances which are provisioned on it. Users in the enterprise account that have the VPN option are able to provision new instances either on the public Internet-facing VLAN or the private, VPN-facing VLAN.
The ability for an instance to span between the public and private VLAN was introduced in IBM SmartCloud Enterprise Release 1.4. For more information about this capability, refer to the article "IBM SmartCloud Enterprise tip: Span virtual local area networks."
IBM SmartCloud Enterprise VPN glossary
Terminology can often be confusing when describing technical issues. To avoid any confusion, a few terms used consistently throughout the article are defined to better understand the capabilities being described.
Let's start with the term Virtual Private Network Environment (VPNE). A VPNE is a set of virtualization technologies used to deliver multi-tenant VPN features in SmartCloud Enterprise. Each IBM SmartCloud Enterprise account can subscribe to an optional VPNE for each IBM SmartCloud Enterprise data center location. Today, there are six IBM SmartCloud Enterprise data centers. All virtual instances within the same data center and same VPNE may communicate freely with each other. A client may have one VPNE per IBM SmartCloud Enterprise data center.
Each client VPNE can contain multiple VPN tunnels. A VPN tunnel is an encrypted communication path between a unique client endpoint located in the client's enterprise network and a IBM SmartCloud Enterprise data center's VPN concentrator (networking device to handle logical separation of multiple VPNs). A client's VPN tunnel is part of the client's VPNE. A client can have up to 5 VPN tunnels per IBM SmartCloud Enterprise data center.
A private virtual local area network (VLAN) is a logical grouping of network interfaces associated with a client's IBM SmartCloud Enterprise instances. These grouped interfaces share the same broadcast domain (a logical division of a computer network in which all nodes can reach each other by broadcast at the data link layer). Client instances with network interfaces on the same private VLAN share the same IP subnet and can communicate freely among themselves. A client can have up to 5 private VLANs per IBM SmartCloud Enterprise data center. Additionally, it is possible in IBM SmartCloud Enterprise for a client to optionally create private VLANS without a VPN. This option is examined in more detail.
Both the VPN and VLAN capabilities of IBM SmartCloud Enterprise are optional components of the offering and as such incur additional charges. Since pricing may change, please refer to the latest charges schedule on the IBM SmartCloud Enterprise product page.
A client can request 1 VPNE per IBM SmartCloud Enterprise data center. There is a one-time charge for each VPNE which will include the first VPN tunnel. Purchase of a VPNE requires at least one private VLAN in the IBM SmartCloud Enterprise data center.
Setup of the private VLAN incurs a one-time charge. In addition to the one-time setup charges, there is an hourly charge for each VPNE. A client may optionally request additional VPN tunnels and/or private VLANs per data center up to 5 total of each. Each additional private VLAN incurs an additional one-time charge.
Over time, you may need to make changes to your VPNE. At this time, there is a charge when a change is made to a VPNE (per data center). A change may include one or more of the following:
- Modifications to the VPNE, VPN tunnels, or private VLANs
- Addition or change of VPNE
- Addition or change of VPN tunnel(s)
- Addition or change of private VLAN(s)
To provision a VPN and/or VLAN in IBM SmartCloud Enterprise, a client must complete and submit the respective forms for these optional services. These forms can be found on the IBM SmartCloud Enterprise Community Support Forum in the file section.
These forms are used to request the VPN and VLAN options and provide the required information to correctly establish these services. It is very important to provide all the required information and that is correct for your enterprise network. Any missing or incorrect information in these forms will cause delays in establishing the requested network services.
In the following sections, screen shots of the forms show how to complete the forms. Once the forms are completed, they should be submitted through email to devtest@us.ibm.com. Note, if submitting a VPNE request, you also need to submit an "Additional Services Order" form found in the IBM SmartCloud Enterprise support forum.
VPN/VLAN configuration capabilities overview
Before going into the network use cases, let's outline the IBM SmartCloud Enterprise Release 2.0 capabilities for the VPN and VLAN optional services by listing the supported configurations and associated constraints. IBM SmartCloud Enterprise 2.0 supports the following configurations:
- One VPNE per data center
- Between one (required) and five VPN tunnels per VPNE (per data center)
- Between one (required) and five private VLANs per VPNE (per data center)
- Multiple VPN tunnels to one private VLAN
- One VPN tunnel to multiple private VLANs
- Multiple VPN tunnels to multiple private VLANs
- Up to a total of five private VLANs with or without a VPNE
The constraints on these configurations are as follows:
- No more than five private VLANs total per site (combination versions associated with a VPNE and versions not associated with a VPNE)
- No more than five VPN tunnels per VPNE (per data center)
- No more than one VPNE per data center
- All private VLANs in a VPNE will be able to communicate to each other
- All private VLANs in a VPNE will be able to communicate across all VPN tunnels in that VPNE
- All VPN tunnels in a VPNE will be able to communicate to all private VLANs in the VPNE
- Client may only provide one IP subnet representing his side of a VPN tunnel
- IP subnets must be unique across all VPN tunnels in all VPNEs for all data centers for a given client
- Only RFC1918 addressing (current best practices for address allocation for private Internets) is allowed for private VLANs and are either specified by the client or will be provided by IBM
- All RFC1918s used for private VLANs must be unique across all of the client's VLANs and VPNEs
- All client instances associated with a private VLAN must be de-provisioned before the private VLAN can be deleted
As you have seen, there are many configuration possibilities with IBM SmartCloud Enterprise VPN and VLAN options. In this section, we look at these common configurations in a little more detail:
- One VPNE, one VPN tunnel, one private VLAN (1:1:1)
- One VPNE, one VPN tunnel, two private VLANs (1:1:2)
- One VPNE, two VPN tunnels, one private VLAN (1:2:1)
- One VPNE, two VPN tunnels, two private VLANs (1:2:2)
We'll also look at some additional VPNE scenarios.
One VPNE, one VPN tunnel, one private VLAN (1:1:1)
In the simplest use case, Client A has requested a single VPNE which has been established between his enterprise network and a single IBM SmartCloud Enterprise data center. In Figure 1, see that there is one VPN tunnel and one private VLAN configured for the client's VPNE.
Figure 1. One VPNE, one VPN tunnel, one private VLAN
Network communication between the enterprise network and the instance subnet (VPNE) provisioned in IBM SmartCloud Enterprise is encrypted as it travels over the Internet through VPN tunnel 1. Machines within the enterprise that are properly configured to route traffic over the established VPN tunnel will be able to communicate with all instances provisioned in private VLAN 1 over the communication path labeled "A". The subnet associated with private VLAN 1 (10.10.30.0/24) will be an extension of Client A's enterprise network as defined by the client's VPN gateway.
Figure 2 shows the parts of the IBM SmartCloud Enterprise VPN form that specify the basic configuration for Figure 1.
Figure 2. Form data for the 1:1:1 configuration
In this scenario, the customer incurs the one-time setup charge for the VPNE which includes the single VPN tunnel and a one-time setup charge for the single private VLAN. There is also the recurring hourly charge for the VPNE above the normal hourly instance rate.
One VPNE, one VPN tunnel, two private VLANs (1:1:2)
We can expand on the previous use case by provisioning a second private VLAN for Client A. Figure 3 shows that there is one VPN tunnel and now two private VLANs configured for the client's VPNE.
Figure 3. One VPNE, one tunnel, two private VLANs
Network communication between the enterprise network and the instances provisioned in IBM SmartCloud Enterprise is encrypted as it travels over the Internet through VPN tunnel 1. Machines within the enterprise that are properly configured to route traffic over the established VPN tunnel are able to communicate with all instances provisioned in private VLAN 1 over the communication path labeled "A" and private VLAN 2 over the communication path labeled "B". Additionally, instances in private VLAN 1 are able to freely communicate with instances in private VLAN 2 as illustrated in Figure 3 by path "C". This path of communication ("C") is not encrypted by the VPN tunnel, but the traffic is routed through the VPNE between the private VLANs. Although not illustrated, this use case can be extended to include up to five private VLANs.
Figure 4 shows the parts of the IBM SmartCloud Enterprise VPN form that specify the 1:1:2 configuration.
Figure 4. Form for 1:1:2 configuration
In this scenario, the client incurs the one-time setup charge for the VPNE (which includes the single VPN tunnel) and a one-time charge for each of the two private VLANs. There is also the recurring hourly charge for the VPNE.
One VPNE, two VPN tunnels, one private VLAN (1:2:1)
In this scenario, we go back to only a single private VLAN but add a second VPN tunnel to Client A's VPNE as illustrated in Figure 5. This scenario allows a company that has multiple physical data centers to connect to a single IBM SmartCloud Enterprise data center via the same VPNE by using a separate VPN tunnel for each enterprise data center.
Figure 5. A single private VLAN but add a second VPN tunnel to the VPNE
In this scenario, network communication from the two enterprise networks utilizes the two VPN tunnels to communicate with the single IBM SmartCloud Enterprise data center. Properly configured machines in Client A's enterprise networks, whether located in Site 1 or Site 2, can securely communicate with instances in private VLAN 1 over network paths "A" and "B".
Although not illustrated, this use case can be extended to include up to five VPN tunnels between Client A's locations and a single IBM SmartCloud Enterprise data center. One thing to note is that network traffic between Site 1 and Site 2 of Client "A" is not permitted via the IBM SmartCloud Enterprise VPNE. The client side of the network must already be enabled for network communication between sites if that is a client requirement.
Figure 6 illustrates the parts of the IBM SmartCloud Enterprise VPN form that specify this configuration.
Figure 6. Form data for 1:2:1 configuration
In this scenario, the client incurs the one-time setup charge for the VPNE (which includes the two VPN tunnels) and a one-time charge for the one private VLAN. If the second VPN tunnel is requested as a change and not provisioned with the initial VPNE request, then an additional one-time charge is incurred for the change request to add the second tunnel. There is also the recurring hourly charge for the VPNE.
One VPNE, two VPN tunnels, two private VLANs (1:2:2)
As you might have guessed, the final VPNE-related scenario we examine in detail is one that has two VPN tunnels and two private VLANs as illustrated in Figure 7. This scenario allows a company that has multiple physical data centers to connect to a single IBM SmartCloud Enterprise data center through the same VPNE by using a separate VPN tunnel for each enterprise data center and defining multiple private VLANs to provide additional network isolation within the cloud environment.
Figure 7. A VPNE with two tunnels, two VLANs
As illustrated, network communication from the two enterprise networks utilize the two VPN tunnels to communicate with the instances in the two private VLANs in the single IBM SmartCloud Enterprise data center. Properly configured machines in Client A's enterprise networks, whether located in Site 1 or Site 2, will be able to securely communicate with instances in private VLAN 1 over network paths "A" and "C"; and instances in private VLAN 2 over network paths "B" and "D". Additionally, instances in private VLAN 1 are able to freely communicate with instances in private VLAN 2 as illustrated by path "E". This path of communication ("E") is not encrypted by the VPN tunnel, but the traffic is routed through the VPNE between the private VLANs.
Although not illustrated, this use case can be extended to include up to five VPN tunnels and five private VLANs. Again, network traffic directly between Site 1 and Site 2 of Client "A" is not allowed via the IBM SmartCloud Enterprise VPNE.
Figure 8 illustrates the parts of the IBM SmartCloud Enterprise VPN form that specify this configuration.
Figure 8. Form data for 1:2:2 configuration
In this scenario, the client incurs the one-time setup charge for the VPNE (includes the two VPN tunnels) and a one-time charge for each of the two private VLANs. If the second VPN tunnel is ordered at the time of the initial VPNE, no additional charge is incurred. There is also the recurring hourly charge for the VPNE.
Each of the VPNE-related use cases just detailed can be extended to include up to the maximum of five VPN tunnels and five private VLANs as illustrated in Figure 9.
Figure 9. One VPNE, five VPN tunnels, five private VLANs
Also, each of the scenarios in this section was illustrated using a single VPNE which means it is a restricted to a single IBM SmartCloud Enterprise data center. It is possible for a client to define a VPNE for each of the IBM SmartCloud Enterprise data centers. At the writing of this article, that would mean a total of six data centers.
Private VLANs without a VPNE configuration
Version 2.0 of IBM SmartCloud Enterprise supports the ability to define multiple private VLANs both with and without an associated VPNE. We've already examined the use cases that define private VLANs with the VPNE option, so now let us take a closer look at private VLANs without the VPNE option.
By default in the IBM SmartCloud Enterprise environment, when a user provisions an instance, the instance is provisioned on the public VLAN with an Internet-facing IP address. The instance is accessible to anyone directly over the network (although firewall rules and such may prevent or limit access as specified by the owner instance). In IBM SmartCloud Enterprise 2.0, client accounts can now, optionally, request up to five private VLANs to enable additional network isolation of their instances. Five private VLANs is the total number allowed and can be a combination of both private VLANs associated with a VPNE and private VLANs that aren't associated with a VPNE.
A separate order form (E Cloud VLAN Only Boarding Form) is designed to request private VLANs without a VPNE. Figure 10 shows the key field of the form where the client has opted to have IBM assign the subnets for the private VLANs being requested. When using this option the client only needs to specify the number of private VLANs to be provisioned and the number of IP addresses available to each.
Figure 10. Form to request private VLANs without a VPNE
In Figure 11 the client has opted to specify the subnet for the three private VLANs being requested. In this scenario the client must also specify the subnet range and the subnet mask for each requested private VLAN.
Figure 11. Specifying the subnet for private VLANs being requested
Once the private VLANs are provisioned, clients can select the VLAN to provision a new instance on through the IBM SmartCloud Enterprise portal or application programming interfaces (APIs). When provisioning instances on the private VLANs, the client needs to provision at least one instance that spans the public and private VLANs; in other words, an instance with a primary IP address on the public VLAN and a secondary IP address on the private VLAN. You can read more about spanning VLANs in the article "IBM SmartCloud Enterprise tip: Span virtual local area networks."
Doing that makes the instance multi-homed. Keep in mind when doing that, by default the second interface is not enabled when initially provisioned. The second interface needs to be enabled manually via the instance operating system. Once a multi-homed instance is provisioned, the client should properly protect the instance and the private VLAN by specifying appropriate firewall and IP table rules for the instance.
As seen in Figure 12, the instance labeled PublicSpanToPrivate has a primary IP address on the public VLAN and a secondary IP address on the private VLAN; the instanced labeled PrivateOnly has only a primary IP address on the private VLAN. The spanning instance is needed in order to access the PrivateOnly instance.
Figure 12. Spanning to private VLAN
With the private VLAN capability of IBM SmartCloud Enterprise, a single instance can span more than two VLANs (as shown in Figure 13).
Figure 13. Spanning more than two VLANs
Great care should be taken in securing any instances configured to span into the private VLANs: Depending on your requirements, you may want to consider only provisioning the spanning instance at times when setup, configuration, customization, and maintenance would need to be done on instances in the private VLANs.
Let's close this article with a little about security. Security is a critical consideration that every client must examine when deploying resources in any public cloud environment. As we've shown, it is possible in IBM SmartCloud Enterprise to provision an instance that spans the public VLAN and a private VLAN. If a client chooses to do so, the client should be aware of the exposure and carefully protect against external attacks by imposing strict firewall or IP table rules or other protective measures. The instance that spans the public VLAN and the private VLAN exposes all instances on the private VLAN which could, in turn, expose the client's enterprise network if that private VLAN is accessible through a VPN tunnel.
It is critical that the host- and guest-based firewalls are utilized in a deployment where instances are used to span the public and private VLANs. Proper configuration of the firewalls is essential for securing instances deployed in the cloud.
For more information about configuring firewalls in the IBM SmartCloud Enterprise environment, refer to the User's Guide and firewall documentation for the operating systems you are using. In addition, in IBM SmartCloud Enterprise 2.0, a firewall image was added to the public IBM SmartCloud Enterprise image catalog. This image provides tooling to configure and manage a firewall running as an instance in IBM SmartCloud Enterprise.
Learn
-
For more on how to perform tasks in the IBM Cloud, visit these resources:
- Up and download files from a Windows instance.
- Install IIS web server on Windows 2008 R2.
- Create an IBM Cloud instance with the Linux command line.
- Create an IBM Cloud instance with the Windows command line.
- Extend your corporate network with the IBM Cloud.
- High availability apps in the IBM Cloud.
- Parameterize cloud images for custom instances on the fly.
- Windows-targeted approaches to IBM Cloud provisioning.
- Deploy products using rapid deployment service.
- Integrate your authentication policy using a proxy.
- Configure the Linux Logical Volume Manager.
- Deploy a complex topology using a deployment utility tool.
- Provision and configure an instance that spans a public and private VLAN.
- Secure IBM Cloud access for Android devices.
- Recover data in IBM SmartCloud Enterprise.
- Secure virtual machine instances in the cloud.
-
In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
-
Find out how to access IBM SmartCloud Enterprise.
Get products and technologies
-
See the product images available for IBM SmartCloud Enterprise.
Discuss
-
Join a cloud computing group on developerWorks.
-
Read all the great cloud blogs on developerWorks.
-
Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
Andrew R. Jones is a Senior Solution Architect with over 22 years of experience at IBM. For the past 16 years, he has focused on customer and business partner enablement of IBM middleware solutions in cloud computing, telecommunications, wireless technologies, and network computers. Andrew is an IBM Master Inventor and Certified IT Architect.
Mitchell DeKeyrel is a Technical Solution Architect with over 13 years of experience at IBM; in the past he spent 5 years focused on Infrastructure and Systems management in large lab environments as well as production data centers. He was the Chief Application Architect for the IBM CIO Enterprise Content Management Solution and spent 7 years working for the IBM CIO office. He worked across the business to understand and interpret end user requirements and setting the roadmap for ECM application changes based on industry trends. Mitchell worked with subject matter experts across the ECM space to identify integration opportunities with other strategic applications and IBM products. Currently Mitchell is working in Cloud Service Enablement for the GTS division of IBM.
Table of contents
Next steps from IBM
Learn more, join the cloud community
