The IBM Cloud is an enterprise-class, multi-tenant, highly virtualized, shared cloud environment designed to provide control, reliability, data security, and massive scalability in performance and capacity. You may not be aware, but IBM actually makes it relatively simple to set up a virtual private network (VPN) for your virtual machine instances on the IBM Cloud in order to provide virtual network isolation of your instances. If you think about it, this is an excellent way to extend the reach of your organization's network onto a secure cloud.

With the IBM Cloud, each VPN service consists of a private virtual LAN (VLAN) in an IBM Cloud Center of your choice plus a VPN gateway for accessing that VLAN. Instances that are provisioned exclusively with IP addresses on your private VLAN can only be accessed by you through the VPN gateway.

What this means is that you can treat the IBM Cloud as if it were part of your own corporate network. Cloud instances can connect to machines inside your network; this allows those instances to use your corporate services such as mail routers or user directories. Cloud instances running in your private VLAN are only accessible from systems within your corporate network; they are not visible or accessible from the Internet.

In this article, I'll explain the basic design considerations and issues and limitations you'll need to be aware of to start planning a VPN from your organization's network into the IBM Cloud. I'll also cover some basic cloud connection troubleshooting, and at the end of the article, provide you with some real-life scenarios (based on Rational cloud images) of what you can do with the IBM Cloud VPN/VLAN feature and offer a list of commonly engaged firewall ports.

Two other goals of this article:

• To help you understand how the VPN/VLAN feature can extend cloud image capabilities.
• To enable the organization's system administrator to effectively engage with the organization's network specialists when it comes to setting up a VPN connection to the cloud.

Let's start with design considerations.

Infrastructure and design considerations

Setting up a VPN connection to the IBM Cloud is not difficult, but it can be time-consuming if you don't do some up-front planning. Before getting into infrastructure and design considerations, let's look at the architecture of the IBM Cloud VPN/VLAN feature (see figure below).

The far right side of the diagram shows the IBM Cloud. When configuring a virtual machine instance in one of the IBM Cloud data centers, you can choose to make it accessible directly from the Internet (on a shared VLAN) or to place it on a virtual private LAN (VLAN).

To place it on a private VLAN, you simply select the private VLAN at provisioning time. You can route network traffic between that VLAN and your own corporate network by establishing a VPN tunnel between your network and an IBM Cloud data center. You must provide an IPSec gateway (firewall) on your side of the network and then work with IBM to configure the connection between your network and the IBM Cloud data center. After the VPN tunnel comes up, you then configure your side of the VPN by opening up ports in your firewall so that IBM products in the IBM Cloud can communicate with computers in your network.

Infrastructure requirements

To connect your corporate network to a private VLAN in an IBM Cloud data center, you need the following:

• A firewall capable of supporting IPSec termination. Additionally, your firewall must be configured as a "route-based VPN". A policy-based configuration is not supported.
• Domain Name Servers (DNS) in your corporate network which can be accessed by systems in the IBM Cloud VLAN across the tunnel.
• An IP address range (or subnet) defined for use by the IBM Cloud VLAN. Additionally, host names should be registered in your corporate DNS for each IP address in the selected range. You need to provide IBM with the domain name that you use for these hosts.

You also need to provide IBM with information about your VPN encryption parameters. Table 1 lists the values that IBM prefers to use.

You need to take these additional actions to use your IBM Cloud instances running in the IBM Cloud VLAN with systems in your network:

• Open ports in your firewall based on what kind of integrations you want to run across the VPN (see Appendix B).
• Ensure that systems in the IBM Cloud VLAN have network access to the computers in your network that you want the IBM Cloud systems to use. This can require configuration of the firewalls on both sides of the VPN connection and may additionally require configuration of other parts of your network infrastructure (especially if you have isolated the part of your network that is connected to the VPN from the rest of your network).

Design considerations

Now let's look at the items I classify as design considerations. You should consider the following things when planning how to implement a VPN connection to the IBM Cloud:

• The location of your VPN endpoint relative to IBM Cloud data centers.
• The systems within your network that need communicate across the VPN to the IBM Cloud VLAN.
• The specific integrations you want to enable between the IBM Cloud VLAN and your own systems and the network ports those integrations require.

Network latency issues: Locating your VPN endpoint
You should locate your VPN endpoint in a geography that minimizes the total network latency between your own computers and the IBM Cloud data center to which you are connecting. Network latency refers to the time required for a packet of information to move across the network from one computer to another; as the network latency increases, the performance of applications running in the IBM Cloud will degrade.

For example, when you use a web browser on a computer on your network to access an instance of Rational Quality Manager that is running in the IBM Cloud, each operation that you perform causes many packets of network traffic to flow across the VPN. Any network latency is therefore magnified; a 100-millisecond delay for a single network transaction can turn into a full second of delay if 10 network transactions are issued.

The total network latency consists of two parts:

• First, there is the latency between your computers and your own VPN endpoint.
• Second, there is the latency between your own VPN endpoint and an IBM Cloud data center.

If the latency within your own network is low (as would usually be the case for computers located within a single geography), you can focus just on the latency between your VPN endpoint and the IBM Cloud. Usually, the best practice is to pick an IBM Cloud data center that is closest geographically to one of your own data centers and establish the VPN connection over the minimum physical distance.

If your organization is spread out geographically across several sites, then you will see more variation in network latency between computers in your sites and your VPN endpoint. Consider how to optimize network latency for the largest percentage of your network. You will most likely end up making trade-offs with some machines seeing low latency and others having higher latency, but keep in mind that the IBM Cloud allows you to create one VPN connection per account per data center. This means that you could, for example, establish one VPN connection to the IBM Cloud data center in Raleigh | North Carolina | USA and a second one to the IBM Cloud data center in Ehningen | Baden-Wurttemberg | Germany. You may therefore be able to leverage multiple IBM Cloud data centers as part of a strategy to minimize network latency.

Proper component identification: Which systems and applications to be used across the VPN
Part of planning for connecting your network to an IBM Cloud VLAN should be to list the computers (and applications) that you expect will be interacting with virtual machines running in the IBM Cloud VLAN. You need a list of IP addresses (or subnets) for the computers in your network, as well as a list of software products or services that you want to have enabled for operation across the VPN.

The IP addresses or subnets are needed by the VPN endpoints on both sides of the VPN tunnel so network traffic can be routed properly between systems in your network and systems hosted in the IBM Cloud VLAN. You might hear this referred to as "setting up the encryption domain" for the firewalls.

You also need the list of services or products that you want to use across the VPN in order to open up the correct network ports in your firewall; otherwise, traffic to systems in your network will be blocked at the firewall and you won't be able to use the integrations as you expected. (Appendix B has a list of ports that need to be open to support common IBM products or services.)

Keep in mind that your corporation may have policies that require networks that connect to outside systems (like the IBM Cloud) to be isolated from other parts of the corporate network. As you identify the systems in your network that you want to use with the IBM Cloud systems, be sure that these systems will in fact be accessible once the VPNs are configured correctly:

• Ask about any isolation or routing policies that would restrict access to the systems you want to use.
• Work with the people in your corporation responsible for network administration and security to resolve potential connectivity issues.

Following is a partial list of the kinds of servers you might find useful to run from a cloud system:

• Domain Name Servers
• LDAP servers (for setting up logins to products in the cloud)
• An SMTP server (to enable email notifications from IBM products)
• Computers running automated test tools like Rational Functional Tester or Rational Performance Tester which you want to integrate with an IBM Cloud instance of Rational Quality Manager
• A Rational Build Forge console or computers running the Build Forge agent
• Deployments of Rational tools that you want to integrate with Cloud instances (examples would be Rational RequisitePro, DOORS, or ClearQuest)
• Deployments of other IBM products which integrate with the IBM Cloud instances (for example, Rational Quality Manager in the cloud can integrate with a deployment of Tivoli Provisioning Manager)

Network port requirements: Specific integrations to enable between the cloud and your network
As I mentioned in the previous section on infrastructure requirements, specific integrations require a thorough reading of individual product documentation to determine network port availabilities and requirements. For a good start on this, take a look at the table of common application port usage in Appendix B.

Back to top

Issues and limitations

Part of good planning is knowing what the system you're working within can and cannot do. With that in mind, let's talk just a bit about current known issues and limitations with the IBM Cloud environment that can affect enabling a VPN/VLAN connection. These include:

• Cloud instances in a VLAN do not have access to the Internet.
• Cloud instances deployed into a private VLAN are not properly assigned host names.
• Mail routing over SMTP requires Cloud IP addresses to be registered in your corporate DNS.
• The Rational Build Forge image will not connect to a Rational License Server.

Cloud instances in a VLAN do not have access to the Internet

One limitation of using a private VLAN is that IBM Cloud instances deployed into a VLAN are isolated from the Internet; this isolation works in both directions. Instances in a private VLAN cannot be seen from the Internet and in addition, instances in a private VLAN cannot access the Internet. This means that an IBM Cloud instance in a private VLAN can only communicate over the VPN and has access only to systems in your organization's network.

One implication of this limitation is that you can't access www.ibm.com from within the VLAN; this means you can't leverage ibm.com directly if you need to update IBM products running in the IBM Cloud. You need to download patches or updates to systems in your own network and then copy the patches to your cloud systems.

Cloud instances deployed into a private VLAN are not properly assigned host names

When you create a cloud instance in a private VLAN, the host name for the instance is not set correctly. Instead, the instances are assigned arbitrary names derived from the IP address of the instance. So if you have registered host names in your corporate DNS for the network addresses used by a cloud VLAN, those host names are not automatically assigned to your instances.

After you deploy a cloud instance into a VLAN, you need to manually edit the /etc/hosts file and change the host name to be the name registered in your DNS servers.

If you choose not to apply this workaround and access your cloud instances only through IP address (and not host name), keep in mind that some IBM product features may not work correctly. For example, the integration features that support linking between artifacts in Rational Quality Manager, Rational Team Concert™, and Rational Requirements Composer will not work if the IBM Cloud instance does not have host name registered in your corporate DNS.

Mail routing over SMTP requires IBM Cloud IP addresses to be registered in your corporate DNS

If you are trying to send email from IBM Cloud instances through your corporate email server, please be aware that you may need to register the IP addresses assigned to the IBM Cloud VLAN in your corporate DNS server. Some SMTP servers perform a reverse DNS lookup on the IP address of machines that send email and reject the email if the sending computer is not registered in the DNS server. This is a way of preventing spam generation.

The Rational Build Forge image will not connect to a Rational License Server

The Rational Build Forge 7.1.1.3 cloud image cannot be reconfigured to use a Rational License Server across the VPN. This is a defect that will be corrected in a future release of the Build Forge cloud image.

There is a workaround. After deploying an instance of Build Forge, login to the instance using ssh then enter the following commands:

cd /opt/buildforge_711/server/tomcat/webapps/rbf-services/bin
sudo chmod 777 *

Then restart Rational Build Forge.

Back to top

Bonus: Basic troubleshooting

The types of trouble you are most likely to encounter in the VLAN/VPN configuration are issues of connectivity. Connectivity issues usually surface as timeouts reported in error logs or sometimes as error messages in the user interfaces.

Troubleshooting with ping

There are a couple of basic steps you can take to isolate the issue before contacting the administrator of your VPN (or contacting IBM):

1. Ping the cloud.
2. Connect to ports of interest.

Let's go into a little more detail.

1. Try a basic ping against the machine you are trying to use. You should be able to ping IBM Cloud instances from machines in your corporate network and you should be able to ping your machines from cloud instances. If this fails or if you can't login to IBM Cloud systems from your network using ssh, then you most likely have configuration problems with the VPN tunnel.
2. If ping works, then try to connect to ports of interest on the target computer using the telnet command (running on your IBM Cloud instance):

   telnet target_ip_address port

   
   If this command hangs or reports an error, then there might be a firewall blocking traffic on that port.
3. First confirm that something is listening on the specified port by logging into the target machine and trying telnet locally. If this works locally but not remotely, then check whether traffic is being blocked by firewalls running on your servers. For IBM Cloud systems, you can temporarily disable the firewall by entering the following command:

   sudo /sbin/service iptables stop

   
   
4. If you can connect after disabling the firewall, then you can adjust the firewall rules on your systems to allow the traffic to pass.
5. If you still can't connect, then you need to adjust the configuration of your VPN/firewall to open up the required ports.
6. If this doesn't work locally, then nothing is listening on the port. Start up the necessary software and repeat from the beginning of step 2.

Troubleshooting with netstat

Another useful diagnostic tool is netstat. The command netstat -a list the connections (including port numbers); this can help you understand which connections have been made successfully. Errors reported by netstat can also indicate DNS configuration issues.

The following listings demonstrate what a failed and successful telnet command should look like.

[root@cloudvpntest3 ~]# telnet 10.128.0.3 54000
Trying 10.128.0.3...
telnet: connect to address 10.128.0.3: Connection timed out
telnet: Unable to connect to remote host: Connection timed out

[root@cloudvpntest3 ~]# telnet 10.128.0.3 2049
Trying 10.128.0.3...
Connected to cloudvlan3.bcsdc.lexington.ibm.com (10.128.0.3).
Escape character is '^]'.

If you are having trouble sending email from IBM Cloud instances through your SMTP server or if you are having trouble configuring integrations between applications running in IBM Cloud instances, then you might have DNS configuration issues.

To check the DNS configuration:

1. Login to your IBM Cloud instance and then look at the file /etc/resolv.conf. This file should contain the IP addresses of your corporate DNS servers and the domain suffix that should be appended to cloud host names. Be sure you can ping each of the DNS servers from IBM Cloud instances and verify that the domain name is what you expect.
2. Verify that the IP addresses assigned to IBM Cloud instances have been properly registered in your corporate DNS server:

   nslookup cloud_instance_ip -

   
   The output of the command should tell you the host name assigned to this IP address. If you see something like ** server can't find 3.1.128.10.in-addr.arpa.: NXDOMAIN, then the IBM Cloud IP address range isn't properly registered in your corporate DNS server. You need to work with the DNS administrator to make that happen.
   
   
3. If nslookup returns the correct host name, then you can check the file /etc/hosts to confirm that the IBM Cloud instance is configured with the correct host name. If the host name in /etc/hosts doesn't match the host name returned by nslookup, correct the value in /etc/hosts.

Back to top

In conclusion

In this article, I've provided a quick overview of the architecture of the IBM Cloud VPN/VLAN feature, explained how it can be used to extend your organization's network into the IBM Cloud, and provided some examples of design, infrastructure, and planning considerations you'll need to make concerning firewall setup, network latency, application/system identification, port assignments, and VPN encryption parameters before you can set up a VPN tunnel to the IBM Cloud.

I've also listed a number of real-world scenarios that you can only do with Rational products in the IBM Cloud by using the VPN/VLAN feature, provided two options for basic troubleshooting your VPN cloud setup, and detailed workarounds for several known limitations of the IBM Cloud VPN/VLAN feature.

Using this information, you should be able to begin to work with your organization's network engineers to set up a VPN/VLAN that can safely and efficiently extend your network into the IBM Cloud.

Back to top

Appendix A: Examples of Rational scenarios in the cloud

The IBM Cloud image catalog contains several Rational product images, including Rational Team Concert, Rational Quality Manager, Rational Build Forge, Rational Requirements Composer, and Rational Asset Manager. When you deploy those images into a private VLAN, the Rational cloud instances can connect to machines in your corporate network; this enables several new use cases that are not possible without the VPN/VLAN feature.

• You can set up the Rational products to use your own LDAP servers for authentication, eliminating the need to create user accounts locally on each Rational cloud server.
• You can enable email notification features and route email through your corporate SMTP servers.
• You can set up the cloud instances of Rational Build Forge and Rational Asset Manager to use your own Rational license servers.

You can also integrate Rational products in the cloud with other products running outside the cloud on your own network. Integration scenarios include:

• Launching automated tests from Rational Quality Manager in the cloud with automated test tools like Rational Functional Tester or Rational Performance Tester running on machines in your own network.
• Integrating a Rational Requirements Composer server in the cloud with RequisitePro or DOORs deployments in your own network.
• Using a Build Forge console in the cloud to run jobs on agent systems in your own network so that the agent systems can access your ClearCase or ClearQuest systems.
• Using Build Forge agents in the cloud to run jobs from a Build Forge console running in your own network.
• Integrating a cloud instance of Rational Team Concert with your own ClearCase or ClearQuest systems, by using the connectors to transfer data across the VPN.
• Integrating a cloud instance of Rational Quality Manager with deployments of Rational products hosted in your own network.

Back to top

Appendix B: Firewall ports by application

IBM products send network traffic over a number of different ports, so you need to configure your firewalls to allow traffic to pass through these ports before you can use IBM products in the cloud in a VPN/VLAN configuration.

Remember that there can be more than one layer of firewall protection in your particular configuration; you might need to open ports in more than one place (such as in the VPN firewall, in client-side firewalls running on your own systems, and on client-side firewalls running on cloud instances).

Table 2 summarizes ports used by some common applications; this is not an exhaustive list, so consult product documentation for more information.

¹The default ports for the Rational License Server are 27000 and 27001, but these port numbers can be overridden in the license data files. If you have problems connecting to a Rational license server over these ports, check in the license data files to see whether the default ports have been overridden.

²The Network File System in IBM Cloud instances is turned off by default.To access file systems on cloud instances over NFS, you must configure the NFS protocol to use a set of static ports, and then open those ports in your firewalls for both TCP and UDP traffic. Edit /etc/sysconfig/nfs and remove the comments from the lines for LOCKD_TCPPORT, LOCKD_UDPPORT, MOUNTD_PORT, RQUOTAD_PORT, STATD_PORT, and STATD_OUTGOING_PORT. The NFS ports listed are the defaults in /etc/sysconfig/nsf; you can use other ports if necessary, but be sure to open up those ports in your firewall. To start NFS servers on an IBM Cloud instance, run the following command: sudo /etc/init.d/nfs start. (You also need to update /etc/iptables to allow NFS traffic to flow through the firewall running on the IBM Cloud instance).

³Rational ClearCase is limited in its ability to work across a corporate firewall. Refer to the About Firewalls and ClearCase technote for additional details.

⁴IBM DB2® uses port 50000 by default, but this can be changed. If you are connecting to a DB2 instance in the IBM Cloud, check on the port that instance is using.

Resources

Learn

• See how a VPN figures into offering more control of cloud networking to the data owner in Deliver cloud network control to the user.
  
  
• In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
  
  
• The next steps: Find out how to access IBM SmartCloud Enterprise.
  
  

Get products and technologies

• See the product images available on the 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.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Infrastructure and design considerations
• Issues and limitations
• Bonus: Basic troubleshooting
• In conclusion
• Appendix A: Examples of Rational scenarios in the cloud
• Appendix B: Firewall ports by application
• Resources
• About the author
• Comments

Next steps from IBM

Learn more, join the cloud community

---

• Community: Cloud computing conversations led by IBM community members
• Buy: Try IBM software on IBM SmartCloud Enterprise

Dig deeper into Cloud computing on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers