Warning: this article uses terms of art that may not be comprehensible to the lay man. I depart from my policy of explaining everything simply, because I’m using this as a reference for myself, and don’t want to belabour the task with tedious analogies - so I beg the reader’s patience.

What is the problem at hand?

(a) Disruption to our paradigm

We work with Tekla. Our working paradigm was that employees connected to a Tekla License server on-site. Everyone wants to work from home. We’ve got 44 people, working two shifts. We have 22 licenses. All our licenses are genuine. Each license cost us a tremendous amount of money, but:

(b) Tekla Don’t Care

How will you manage your Tekla licenses given everyone’s at home? We spoke to Trimble, and there’s no respite from them - at least not from their agents. Some temporary licenses would have been very handy but no bueno.

If we go out of business, it’s no loss to the agent, and only a minor loss to Trimble, so the apathy is to be expected.

Juxtapose that with our situation: we have clients demanding drawings. Our ability to work has been severely hampered given our licensing situation. The solution?

(c) Solution: Tekla Server in AWS connected via VPN

The solution is simple: we need a license server on the cloud: sitting in an Amazon VPN and secure from the outside world except through a VPN connection.

Avoid Problems with Physical Servers

You could roll your own in your current office - but then again, why rely on physical offices, and physical servers etc. all liable to problems such as theft, connectivity problems, and staff forgetfulness:

• Example #1 - Staff forgetting passwords: my man on the ground insists that the server he manages myseriously changed its password ¯¯\(ツ)/¯¯ what am I to even say in response to this? That’s a $3,000 server, which we now can’t access. And untold hours to rectify it all, because a ghost mysteriously decided to change the password. I was hoping my man would have have the good sense to write down the password in big capital letters and attach it to the server, in full view, allowing any bumbling hacker to take control of it - but no - he made use of the good ol’ “the ghost changed my password” routine.

I asked him to download and make use of a password manager. He’s like “yeah yeah” - which, when translated from Malayalam into English means: STFU. You’ve heard the saying, “the only sure thing is death and taxes” well I’m not so sure about either of them, but I am damn sure that my man after screwing a $3,000 server, still has not downloaded a password manager and will continue to use “password” as his super secure password. I wouldn’t mind if he stuffs around with his own money, but when he endangers our life blood I feel I have just cause for criticism with righteous indignation. Unfortunately, I did not select this man, yet I have to deal with him. Or rather, work around him.

• Example #2 - Theft. A hilarious example: someone snuck into one of our offices and made off with a computer while staff were busily working, entirely unawares. I do believe that this was a genuine theft.

• Example #3 - Hardware failure: Our main PC supplier in Chennai apparently was not putting thermal paste on our CPUs. A large number were failing, randomly. These are high spec and very expensive PCs too. Untold dollars down the tube.

• Example #4 - Ransomeware. What if your license server goes down or gets ransom-ware in there? We might loose our entitlement certificates and this would afford a nice opportunity for Trimble to hold us up.

Save yourself these headaches: go straight to the cloud.

(d) Do not change your licensing terms

Why bother with this when you can just convert to Trimble’s subscription model?

Because if you’ve bought a permanent license, consider carefully whether you should surrender them..

It’s not too difficult to set up an EC2 instance. And if you don’t want to do that, then simply set up a computer, in an office that you can directly control. All you have to do is to then set up a VPN connection to that server. To my mind, just set it up on AWS. Or Azure, if you are so inclined.

See below for Details:

Implementation and the Reasoning

(i) VPN Server

You want staff to connect to your Tekla License server? Then you need a VPN server.

Roll your own VPN vs AWS’s Managed VPN Infrastructure

You could choose an Open VPN AMI from the AWS market place, and configure it all yourself. The advantage is that you get control - especially in terms of handling user access, with friendly user interfaces etc., and if you don’t care for that particular flexibility, or you want to substitute Azure as your portal for managing user access, then you might as well use AWS’s managed service.

I have opted to use the AWS managed service. Scaling and set up is handled automatically. But the access part becomes tricky: I want to control who has access to the VPN. If Freddie decides to chuck his job tomorrow, I would not want Freddie to continue to access the VPN and those expensive Tekla licenses. Nor can you adopt a SAAS solution and charge Freddie, because that will likely violate Trimble’s EULA.

There are a few options, using AWS’s client VPN:

(i) certificates, and/or (ii) Microsoft Active Directory (using AWS Managed Directory Services), and/or (iii) Federated Authentication (using SAML 2.0)

Certificates don’t scale

One method of allow access to VPN is by manually generating certificates.

This is a pain: I would have to come up with some sort of BASH script to create licenses and keys to 40 people and then disseminate them to our staff. They’re going to inevitably cock up any installation that happens, and at that scale, I don’t want to baby sit users into telling them where to click etc.

What is clear to me is that users typically don’t read any documentation that I provide them with, nor watch videos, and there is also a tendency to do crazy things (or perhaps I am expecting too much from them (?)), so the certificate based solution is clearly not going to work. If you have perhaps one or two users, then it is an ideal solution with every little overhead.

The other option is to use AWS Managed Active Directory. This is old skool. The way of the future will no doubt be some type of federated permissions structure. Unfortunately, it looks like AWS have not implemented their own which works well with their own client VPN so we might have to resort to Azure’s Active Directory (to be constrasted with Microsoft Active Directory and AWS Managed Active Directory – the latter being an incarnation of the former except on AWS Infrastructure – I know, the names are confusing, right?).

Now if a staff member leaves, at the click of a button, I can deny access.

And the best part is, if they forget their password, it becomes their problem, not mine.

Cloud Architecture - Set up Details

• Azure Active Directory to Manage Staff. In my particular case, I am inviting them as external “guests” so that they can use their own email addresses. Then to connect to the VPN we can authenticate them via SAML. Everyone in the Azure Active Directory Steel Detailer group gets access. If someone leaves the firm, I can remove them from the group and they will no longer get access. If someone signs in from Moscow or another crazy location, I can prevent authentication, or I can request MFA. The possibilities are endless and it’s quite powerful.

Add the following custom ports inbound rules:

Tekla:

• TCP 1238 (Tekla)
• TCP 27007 (Tekla)

AWS VPN Client:

• TCP 1194
• TCP 443

SSO via Azure VPN:

• TCP 35001

If you want to be even more secure, you can limit the RDP to your own IP address, limiting access even further. Instructions:

1. Set up a Tekla License Server on an EC2 Windows Server Instance in a public subet in AWS.
2. Expose the RDP Port in a security group (RDP / TCP / 3389) and apply it to the public subnet. (i.e. create a security group, setting RDP access right.)

3. Now you can RDP into that instance and set up the license server - see the instructions below. After you’ve set up the license server then: remove the Internet Gateway from the public subnet and “turn it into a private one”:

   (i) set up a “private route table”. (ii) change the route table in the “public subnet” to point to the “private route table.” (iii) add a NAT Gateway in a public subnet; (any will do) (iv) point the private subnet’s route table to the NAT Gateway in the public subnet - this will allow your EC2 instance to communicate to the outside world but will severely limit any traffic coming in. But if you truly want your instance untouchable from the inside and outside - then remove the NAT gateway. This means your EC2 instance won’t be able to access the internet:

   

   Why are we doing this? I don’t trust Trimble. They are not above playing dirty, in order to unjustly extort more money from you. Changing their “permanent” licensing model, coercing people onto subscriptions is the perfect example of this. This does not smack of truth. Honor your commitments, was what I was taught. If this is how Trimble act to prejudice their customers, who knows what other questionable means they might employ, whether they employ spyware etc - I wouldn’t put it beyond them to do this. Ocassionally someone sends us a model that we did not generate, and if we should open it - BAM: we get a call from Tekla: “why are you using a pirate Tekla model, who sent it to you etc?”. So this kinda sounds like “spyware” in my book. In order to prevent or minimize Tekla screwing you over, it might be an idea to completely cut off your EC2 instance from the oustide world.

Here’s how the “private route table” should look like:

Now - your EC2 instance will effectively be hidden from the world. The only way you can access it, is through via VPN. Sometimes this may be inconvenient. If you ever want to RDP into the EC2 instance, then you’ll need to: turn the subnet back into a “public” one: simply change the subnet’s private route table into the “public” one - the route table that has an internet gateway attached to it:

• Set up the AWS Managed VPN Server. Point this to your PRIVATE subnet. Selected Federated SAML authentication.

• Go to Azure Active Directory and set up an AWS VPN Connection as an enterprise app. Copy the meta data file created you’ll use it below.

• Set up an identity provider in AWS: use the meta data file in the Azure set up above and point it to your VPN. Your VPN will give you a config file. Distribute this config file to all your staff and ask them to download and install AWS VPN Client and set up the profiles.

Details on how to do that are here.

AWS client VPN connection from Tek1 on Vimeo.

Voila, you are done!

Setting up the License Server on EC2

Here’s where you can stuff up:

• Download the latest License Server and the latest LM Tools.

• If you can’t connect, start and stop your server.

• Ensure that you have exposed the following ports through windows firewall to allow the license server to operate. Or you can give free reign to Tekla’s programs if you wish.

• Allow traffic to fixed IP Ports. In our case we are using port: 1237. Follow the instructions here. Don’t forget to start and stop the server.

Start your engines

• Run the AWS VPN Client.
• Authenticate with Azure.
• Start Tekla on your local desktop.
• Connect using this method: 1237@172.31.42.153 (or port_number@private_ip_address_of_ec2_instance)
• Enjoy your license

Resource Links

• Video Instructions on How to Connect to Tek1 Tekla Licenses
• Getting Errors?

How to RDP Given the Above Set up?

1. Connect to the private subnet using AWS VPN.
2. Then using RDP software, connect to the EC2 private IP address: 172.31.42.153.
3. Username is: “Administrator”
4. Password is contained in your password manager.

VPN via Meraki

If you have a Cisco Meraki device, you can set up a site-to-site VPN with your EC2 instance.

You need to set up a Customer Gateway, and a Virtual Privage Gateway. In the console, in the latter, you can download some specific configuration instructions for your particular device (how cool is that?) so you don’t even have to think. The only tricky point, was that I attached the Vitual Gateway to the route table of our private subnet, and I set as the Destination, the IP addresses existing our our private on-premesis network. Similarly, on the Meraki devise, I set the target private IP address range as being the entire VPC. I suppose I could have limited the scope to just our private subnet.

Cisco does not have an easy way to manage fail-overs - i.e. if one tunnel fails, there’s no ability to automatically re-route through the working tunnel. You’ll have to do that. But where? You’d have to set up a script on a Lambda. In our case, it’s easy enough to run the script from my own PC. Every time you restart it, you gotta make sure it runs. That’s the only catch. The script details are here, if you’re interested. You’ll also have to add tags, to the peers, and ensure they comply with the nomenclature used in the python script.

Just login to your Meraki cloud device, and plugin those numbers.

AWS also offers the option of a back-up tunnel, in case your first one is down. At Tek1, we are probably a little too safe: we have a tunnel, and then a backup tunnel, and if that fails, then we have a separate client VPN end point, to allow access to the EC2 instance. And if that goes down? That becomes tricky. Given it’s a license server, you would have to spin up an identical instance in another availability zone. In our case, this is a single point of failure. If the AWS Data Centres in Mumbia go down - for example, if the corrupt ~~BJP~~ bureaucrats there decide to shut off the power - then we’re without recourse. We’d have to manually manage Tekla licenses on our on premesis server.

It’s too complicated?

Sorry, folks, I wrote this as a reference to myself, and didn’t want to expend a volume explaining ABCs.

If you want help, you might have to ask an AWS specialist to help you. And you might need a Tekla user to set up: LM Tools and your Tekla License Server Admin Tools properly. All you probably want to do is to press a button and have your Tekla licenses available to whom you want to give access, anywhere in the world. My plan is to set it all up with a click of a button, using Cloud Formation and AMIs - or even better, to use Terraform to set it all up for you.

In the mean time, if you are looking to implement a solution on AWS, the above should give you a good starting point: good luck! Or if you want, you could use Trimble’s cloud solution (actually, they’re using AWS behind the scenes) - but running with Trimble’s cloud offering, is something you should seriously consider not getting into.

The Risks…

The risk is if something happens to your EC2 instance, then you can kiss your licenses good-bye. Tread carefully…..or you can risk putting it on a physical license server. But if something happens to that computer: same problem: you can kiss your licenses good bye.

Troubleshooting

I Can’t RDP

Every now and again (once in 1-2 years), you may find that you can no longer RDP into your instance. Rebooting your AWS instance may solve it. Of course, you’ll also need to restart your Tekla Server. Check your security group. I had found that I limited RDP to a specific IP address - my one. Accept, my “fixed” IP address had actually changed, without me realising.

TLS Handshake Error

Every 2-3 years you might get this error. This means you need to update your security certificate.

Look in: ~/Documents/Tek1/aws_certificates and run the update instructions here: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/mutual.html . Basically upload your certificate to AWS Certificate Manager. Then, go to your VPC -> Client VPN endpoints and then modify your cpvn endpoint, and select the certificate you just uploaded.

aws acm import-certificate --certificate fileb://server-2023-12-12.crt --private-key fileb://server-2023-12-12.key --certificate-chain fileb://ca.crt --region ap-south-1

(Our EC2 instance is located in Mumbai. Yours may be somewhere else: be sure to change the key accordingly. Check the list of reigions and set the flag accordingly.) You shouldn’t need to change anything else.

AWS Tunnel Maintenance

You will have to establish each tunnel as a peer on your Meraki device.

You can use API code in case of failover. If one tunnel fails, then on the other tunnel, change the network availability tag via API. Make one to be available in “no network”. Or alternatively, tag your network, and remove the tag on the failing tunnel, and establish on the tunnel you want to connect with.

Links:

• Here is some sample code you can start with.
• Meraki Ruby SDK

Just get your API key, run the code according to your preferred interval, perhaps on a lambda, or on your own server - and you’re off to the races!

If you are happy to do it manually, then simply manually toggle between the tunnels as the need requires!