Skip to Content

SAP released a version of SUP on AWS. It’s easy and fast to set up, you can develop native and HWC apps and because it’s in the cloud, you can use it from everywhere. Right? From everywhere, the benefit of the whole cloud thing. In real life, this everywhere normally stops at your corporate proxy. You’ll find out very fast that corporate proxies are configured to only let specific content through: HTTP and HTTPS. While you can reconfigure the ports SUP uses, to take advantage of the SUP instance you need access to the Sybase Control Center, Sample DB and SUP for the device simulator, and RDP. And when you plan to install more software in the SUP instance, you also need more ports. You can’t map this to just two ports.

Possible solution is a wireless 3G connection. Possible drawback are additional costs and that you don’t know if and how your operator is treating the traffic. As you will run device simulators like BlackBerries, wouldn’t it nice to find out that they block BB traffic as your data contract is for computer traffic and not for BB traffic? Another point against 3G can be availability and stability. I suffer here in Rio de Janeiro from a more than crappy 3G. To give you an example: my 3G connection normally only gives me Edge and a total connection loss is very likely. I do have unlimited data transfer, but it comes with a footnote: after a certain amount of data transmitted the bandwidth gets very, very limited: close to unusable slow. Remote desktop cannot be used anymore. The conclusion is that 3G only can be plan C because of bandwidth and connection; and my operator VIVO is considered one of the bests.

To rule out possible errors you want to have a stable connection, a connection that is always the same. Internet connection is not always as predictable as you need it, you simply don’t know what happens between your computer and your SUP instance. In a local LAN or VM you can rule out any external interferers. But how to achieve the same with your SUP AWS instance?

Plan B

Direct connection is not possible, wireless is not stable enough, access via the internet not predictable enough, obvious corporate users are not part of the focus group SAP had in mind when they released SUP on AWS. That’s sad considering that corporate users are actually the ones that already use SAP, know their business, know what can and should be mobilized and are the ones that do drive the mobilization process in a company. Short: they are the ones that should have access to SUP. But how can you work with SUP when you are behind a corporate proxy? Wait for an on premise SUP instance?

Solution: VPN

To connect two computers you can use VPN, given that you have the permission on your computer (if not, plan C is your only solution) to set up a VPN connection. Windows clients and Windows 2008 R2 comes with everything you need to set up a VPN. The most common VPN types are PPTP and L2TP. If you now think you are done: life is not always so easy. PPTP won’t work on AWS (judging from the Google search results Amazon is blocking) and L2TP uses well known ports. Chances are very good that the corporate proxy is blocking these ports.

There is a 3rd alternative: SSL VPN. Windows Server allows SSTP VPN. Why this is interesting? As Wikipedia states: “The use of SSL over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.” This solution only needs one open TCP port. You can now set up the Windows 2008 server SUP runs in for RRA and SSTP. The process is complicated as you also have to get a SSL certificate.

OpenVPN

I found it easier to use OpenVPN. After downloading OpenVPN and installing it you have all you need to set up your own VPN. The same package is used for server and client.

OpenVPN comes with a tool for creating the certificates, both for the server and client. As the name of the tool suggests, it’s really easy (easy-rsa). While executing the tool on the server, I got an error about writing to rnd and while the server certificate was created, the client certificate wasn’t. The process of creating the certificates for both server and client worked perfectly on my Windows 7 64bit. It doesn’t matter where you create the certificates, just copy them to the config dir.

How to actually install and configure  OpenVPN? There is a very good step by step howto available from OpenVPN. Just follow the guide, create the certificate and configuration files on your computer and copy them later to the server.

The interesting part of the client / server configuration is how they connect. To make a HTTPS connection make sure that in the client.ovpn file you have:

proto tcp

remote <IP of your SUP AWS instance> 443

For the server:

port 443

proto tcp

If you use dev tap or dev tun as the device is up to you. Just make sure your client and server are both using the same interface. Also, for both configuration files keep in mind that because we are on Windows the path to the certificates has to be with double \, for examples:

ca “C:\\Program Files (x86)\\OpenVPN\\config\\ca.crt


That’s it, the configuration is done. Now it is only to start the OpenVPN program in both server and client and connect to the configuration. The OpenVPN client gives you the option to configure the proxy settings, in case your are setting up the VPN because you are behind a corporate proxy.:

/wp-content/uploads/2012/08/supawsvpn1_129471.jpg

/wp-content/uploads/2012/08/supawsvpn2_129472.jpg

Make sure that on the server OpenVPN gets started as a service during startup. From now on you only have to start the server via the AWS console and then you can connect via OpenVPN: enjoy your unlimited access to SUP.

/wp-content/uploads/2012/08/supawsvpn3_129500.jpg

After connecting via OpenVPN to SUP, the IP address changed. It’s not anymore the public AWS IP, now it’s the internal OpenVPN addresss, in my case the standard 10.0.8.1 for the server. This means that you’ll have to configure your SDK and mobile phone simulators to use this IP. In the SDK configure the Sample DB and SUP Server connection:

/wp-content/uploads/2012/08/supawsvpn4_129501.jpg

In the device simulator, register the device using the new VPN IP (example here: HWC):

/wp-content/uploads/2012/08/supawsvpn5_129502.jpg

That’s it. From now on you can start the SUP instance on AWS and automatically the OpenVPN service is started and you can connect to the server using port 443 (SSL).

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply