Open Telekom Cloud for Business Customers

VPN between a CISCO Router and the Open Telekom Cloud

Why configure VPNs to Cloud Services?

When we consider Virtual Private Networks, or VPNs, we immediately think of security. Indeed, VPNs do normally deliver security, through both authentication and encryption, but that is not the only reason people use them. With a VPN, we can make any remote set of networks, possibly connected over a third-party or untrusted link, part of our home or company network. In this case, the link in question is the Internet.

Using a VPN, accessing remote resources can be as easy as accessing local ones, with a consistent network address scheme across both zones and seamless use of existing services like DNS and Active Directory. The remote cloud networks become part of the enterprise’s network. Often thought of as a hybrid-cloud environment, where local and remote resources work together or the cloud resources are used to deal with peak workloads. Indeed, when used like this, there is no need to use public internet addresses in the cloud or offer services over the Internet at all. All required internet access can be delivered via a company’s own Internet links. However, owing to the nature of the applications deployed, Internet access is very often desirable but it is not necessary when VPNs are used.

Many customers with have described to me exactly this need—to use public cloud resources in a hybrid mode over a VPN—where there is sensitivity around the applications or data involved. The cloud becomes an extension of the data centre. Having heard this mentioned as an essential requirement several times, I thought I would try it out with the Open Telekom Cloud.

Target Network Design

Most of my customers use CISCO hardware so wanted to try something comparable.  I borrowed an old CISCO router from my network department. It was nothing special: a CISCO 1841 with IOS 12.4, 2x100Mbps Ethernet ports and a cryptographic acceleration module. Of course, there are many other IPSec supporting devices, Linux and BSD distributions, and OpenWRT firmware, which could also be used to provide this VPN connectivity.

Here I have two networks in the Open Telekom Cloud Virtual Private Cloud (VPC) (192.168.100.0/24 and 192.168.200.0/24), which I want to include in a VPN with one network at home (192.168.1.0/24). I have left the rest of my home network out for simplicity but there are no conflicting network-addresses.

When configuring the VPN service on the Open Telekom Cloud, the systems checks that your router public address is not already configured in a VPN. This is true even where different VPCs are used. So if we needed multiple VPNs configuring, which is quite likely if we were connecting our data centres to the Open Telekom Cloud via VPN, then we would need multiple IP addresses on our gateway. It may be possible to have multiple VPNs on one end point with manual configuration but I have not explored this yet.

VPN between a CISCO Router and the Open Telekom Cloud

In this configuration, both VPN endpoints have public addresses so no NAT traversal is required.

The order of configuration was:

  • Collect my local router IP and network details
  • Configure the Open Telekom Cloud VPN, which allocates an endpoint public-IP address
  • Configure the VPN on the local router.

Open Telekom Cloud VPN settings

IKE Policy

Authentication Algorithm

sha1
Encryption Algorithm

aes-256

DH AlgorithmGroup14
Versionv1
Lifecycle (sec)86400

IPSec Policy

Authentication Algorithmsha1
Encryption Algorithmaes-256
DH AlgorithmGroup14
Transfer ProtocolEsp
Lifecycle (sec)86400
Local Subnets:192.168.100.0/24; 192.168.200.0/24
Remote Gateway:MY-ROUTER-PUBLIC-ADDRESS
Remote Subnets:192.168.1.0/24

When the VPN is created, the Open Telekom Cloud VPN service allocates a public IP address for the Open Telekom Cloud VPN end-point. This is needed to configure the local end.

Local Cisco Router VPN Configuration

Isakmp policy

crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 14
 crypto isakmp key MYPRESHAREDSECRET address ALLOCATED-VPN-ADDRESS
 crypto isakmp keepalive 12

Encryption proposal and map

Note that we have esp-aes 256, which corresponds to aes-256 in the IPSec policy, encryption algorithm setting, and esp-sha-hmac, which corresponds to the authentication algorithm of the IPSec policy.
We create a transform proposal, proposal5, that embodies these settings and include it in a crypto map along with an access list which matches traffic between the source and destination subnets. In this case:

  • 192.168.1.0/24 ßà 192.168.100.0/24
  • 192.168.1.0/24 ßà 192.168.200.0/24

This crypto map is applied to the external interface of the router, in my case FastEthernet0/0.

crypto ipsec transform-set proposal5 esp-aes 256 esp-sha-hmac
   crypto map otcmap 2 ipsec-isakmp
 set peer ALLOCATED-VPN-ADDRESS
 set transform-set proposal5
 match address 111
interface FastEthernet0/0
  ip address dhcp
 ip nat outside
 ip virtual-reassembly
 speed auto
 full-duplex
 no mop enabled
 crypto map otcmap
access-list 111 permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 111 permit ip 192.168.1.0 0.0.0.255 192.168.200.0 0.0.0.255

I tested with and without pfs (perfect forwarding secrecy) enabled—both worked.

No NAT through the VPN

In my case, as I am using this router for broadband internet access, I have NAT overload configured to hide my internal network behind the address allocated by my ISP.

ip nat inside source route-map nonat interface FastEthernet0/0 overload

The access list, in this case 110, controls which traffic is included. permit means NAT the traffic, deny means don’t. These deny rules match the rules in the crypto map but with deny rather than permit.

route-map nonat permit 10
  match ip address 110

I needed to make sure the VPN traffic was not NATted as this would not make sense. This was done with the following two lines in the NAT access list

access-list 110 deny ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
 access-list 110 deny ip 192.168.1.0 0.0.0.255 192.168.200.0 0.0.0.255
 access-list 110permit ip 192.168.0.0 0.0.0.255 any
 access-list 110permit ip 192.168.1.0 0.0.0.255 any

Running VPN

I was able to open the VPN from either end, either by attempting to connect to 192.168.1.3 from a server in the OpenTelekomCloud or via browsing to http://192.168.100.117 from a browser on 192.168.1.3. As you can see the VPN status shows as normal.

Open Telekom Cloud VPN running VPN

Other Observations

The local router address and the pre-shared secret can be updated in the Open Telekom Cloud VPN definition dynamically. This is useful if you are using a broadband provider, which changes your address periodically. Mine doesn’t unless I change the MAC address of the router.

VPNs with NAT traversal cannot be configured automatically. This should be possible with a manual update to the Open Telekom Cloud VPN configuration. This could potentially be done via a support ticket. I am yet to test this, but a command like this would appear to be required.

 remote-address vpn-instance vpn<num> MY-ROUTER-PUBLIC-ADDRESS
 authentication-address MY-VPN-PRIVATE-ENDPOINT 

Closing Remarks

Clearly it is not that difficult to configure a VPN to the Open Telekom Cloud providing you know how to set up your router and you understand IPSec a little. I confess I did not at the start of this process! It was very satisfying to succeed though and I hope these notes will help other people achieve the same.

Anthony Clarke has worked in IT for over 25 years and in outsourcing for more than 15. During that time, he has held various roles in software development, server, storage, firewall and database operations, architecture and management.

In recent years, he has focussed on cloud computing solutions, supporting colleagues and customers in making the best use of this fascinating and dynamic technology.


anthony-clarke

Anthony Clarke has worked in IT for over 25 years and in outsourcing for more than 15. During that time, he has held various roles in software development, server, storage, firewall and database operations, architecture and management.

In recent years, he has focussed on cloud computing solutions, supporting colleagues and customers in making the best use of this fascinating and dynamic technology.

Book now and claim starting credit of EUR 250* (code: 4UOTC250)
24/7 Service
Take advantage of our consulting services!

Our experts will be happy to help you.

We will answer any questions you have regarding testing, booking and usage – free and tailored to your needs. Try it out today!

Hotline: 24 hours a day, seven days a week 

0800 33 04477 from Germany
00800 44 556 600 from abroad

* Voucher can be redeemed until June 30, 2020. Please contact us when using the voucher for booking. The discount is only valid for customers with a billing address in Germany and expires two months after conclusion of the contract. The credit is deducted according to the valid list prices as per the service description. Payment of the credit in cash is excluded.


  • Test it today – with no obligation and free of charge

    Book now and claim starting credit of EUR 250*
    Code: 4UOTC250

    Book now

  • Telefon

    Free expert hotline

    Our certified cloud experts provide you with personal service free of charge.

    0800 33 04477 (from Germany)

    24 hours a day, seven days a week

  • E-Mail

    Our customer service is available free of charge via E-Mail

    Write an E-Mail

  • Arrange an appointment

    Our Open Telekom Cloud experts provide you with free, non-binding and idividual support

    Arrange an appointment