jgillman's Liquid Web Update Unofficial tips, tricks, and happenings from a Liquid Web sales engineer


Pseudo-VPN for SmartServers

One of the disadvantages that SmartVPSs or SmartServers have compared to traditional dedicated servers is that you can't stick an ASA5505 (or some other hardware firewall) in front of it for VPN connectivity.

Many times, customers are looking to have some sort of internal site that they don't want being visible to the outside world. So how can we accomplish something like this without a VPN? Read below the fold to find out.

As many of the things I discuss on this site are considered best effort, it should be surprised to find me posting this caveat: What you are about to read discusses things that would fall under our best effort support. While we would be more than happy to assist where possible, we can't necessarily guarantee results.

However, with that out of the way, I will say that in my testing, this procedure seems to work pretty well. So let's get on with the show!

Kick your SmartServers

The idea here is that you will have public facing server, and one "closed" server. This article will be using the "example.com" domain. Who would have thought?

In this case, you would create the two servers with hostnames something similar to "open.example.com" and "closed.example.com". In regards to the image, it doesn't really matter, but most people will probably want cPanel, as it make adjusting of IPs for sites much easier, so that's what I will use in the example here.

Once the servers are created, make sure that they have private networking enabled. For this tutorial, let's assume that "open.example.com" has a private IP of, and "closed" has

Lockdown the "closed" server

So the first course of business is to lock down the "closed" server by utilizing the SmartServer Advanced Firewall. This way, great granularity can be achieved in what is open and what isn't. The basic idea is that you will only want to allow traffic on the private network or to Liquid Web so that we can monitor your servers. Additionally, you may want to leave WHM accessible to the outside so you won't have to jump through hoops to access it. Below is the configuration that I have tested and used:

Internal * any allow
WHM External * 2087 any allow
Allow internal * any allow
Block outside * * any deny

At this point, the only thing that you should be able to access from the outside world is WHM, as it utilizes port 2087 for secured connections. If you want, you may want to allow access to 2083 as well. That way you can access the specific cPanel accounts from the outside as well (of course, in a secured manner) without having to tunnel in.

Create the internal site

Now that "closed.example.com" is secured, you can go ahead and create the cPanel account for the internal site. In this case, I called it "internal.example.com". After creating it, I changed the IP for the site from the default shared IP to the internal, private networked IP.

You'll also want to do the needful in regards to DNS so that "internal.example.com" points to

Keep in mind, to upload content, you will need to tell your SFTP client (SFTP good, regular FTP bad) to use a proxy. This will be discussed in the next section.

Tunneling in

So now that things are all locked down, how do you access it?

Depending on what operating system you are using, the exact process will vary, but the principal is similar. Essentially, you would create a user that you would like to use for the purpose of the tunnel on "open.example.com, and when you SSH into the open server, tell your SSH client to setup a SOCKS tunnel.

A quick google search will tell you how to establish the tunnel based on your OS. So for example, you could search with a string such as "SSH proxy windows" or "SSH proxy linux".

Once the tunnel is established, all you need to do will have your browser (or (S)FTP client) utilize the proxy, which in 99% of the cases, will be "localhost" and whatever port number you decided to choose upon creation of the tunnel.

Pro Tip: For additional security, you could disable interactive (keyboard) authentication, and require keys be used into "open.example.com"


That's the down and dirty of this method of securing an internal site. For me, it worked. Again, it's technically best effort support, although many of the processes I described are things that we can probably assist you with.

Feel free to leave a comment here if you need assistance, or ping your friendly Liquid Web support technician who can certainly get a hold of me if they have any questions.

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment


No trackbacks yet.

FireStats icon Powered by FireStats
Optimization WordPress Plugins & Solutions by W3 EDGE