A bunch of Sonicwall goodies — Part 1, SSL-VPN

We tend to lose sight of some of the “basics” when all of the “sexiness” of the Cloud and other things get all of the attention.  But it is important to remember that your on-premise kit needs some love and affection, too!  And, most importantly, you need to be mindful of your gateway security.

I am an unabashed fan of Dell Sonicwall gear as Sonicwall offers a wide range of capabilities in their UTM (Unified Threat Management) platforms that is affordable for most small, midsize and enterprise businesses.  We (itgroove) never perform a customer on-premise build without a Sonicwall in place at the gateway.

There are three features I want to reference in this and the following two blog posts that I think are of particular relevance to a number of small and medium sized businesses.

The first is SSL-VPN.  SSL-VPN in simplistic terms is a method to create a secure, encrypted “tunnel” between two devices using SSL (https) as the encryption/connection mechanism.  SSL-VPN is usually much easier to manage than older, more traditional “fat client” VPN solutions.  Sonicwall offers multiple ways to implement SSL-VPN but the two that most come to mind with SMB’s are the SSL-VPN “Virtual Office” capabilities that are baked into all Sonicwall UTM appliances and the expanded SSL-VPN capabilities that ship with the Sonicwall SRA products.  (There are much bigger SSL VPN products in the Sonicwall stable but we’ll stick to the ones listed as they are the most affordable.)  The UTM appliances all provide SSL-VPN based “Virtual Office” capability as well as the NetExtender SSL-VPN client. 

Virtual Office is essentially web-published, proxied links to internal RDP, VNC, Telnet or SSH resources.  Links are presented on a webpage hosted on the Sonicwall UTM which is accessed after the user logs in and authenticates (various authentication methods are supported including LDAP/Active Directory).  The links on the page may be global or may be specific to the user but all operate in the same fashion; the UTM appliance creates a proxied session between the authenticated user on the WAN and the desired target/service on the LAN.  All the user requires is a modern browser (IE, Chrome, FireFox, Safari and others) and Java installed along with the browser.  When a user connects to a Sonicwall with SSL VPN enabled they will see something similar to the following:

The user supplies the appropriate login and password (the domain piece does not actually refer to a Windows domain, it is an internal designation that can be set to anything) and, if authenticated, they’ll then be presented with a screen like the following:

(Note that in the address bar you can see that the site is secured (the padlock is displayed).  In this particular case the Sonicwall has a third-party SSL cert installed but the whole process also works with a self-signed cert.)

In this case there are two choices available to this user; the user can connect to the Server using the published Virtual Office bookmark OR the user can initiate a VPN tunnel connection using NetExtender (more about that in a bit).  As can be seen, the bookmark for Server is set as RDP5/ActiveX which means this bookmark should be used with IE.  The Sonicwall administrator could also create a bookmark using RDP5/JAVA which will work with any browser including those on non-Microsoft machines such as Mac’s or Unix/Linux machines.  The user also has the ability to create their own bookmark (proxied connections) using the Add bookmark button (this ability can be turned on or off, per user, by the Sonicwall administrator).

Here is the process to create a bookmark, the user will create an RDP5/JAVA connection by clicking Add bookmark:

This is the screen that is displayed:

Most of the information is self explanatory and you’ll see it in the next screen shot but some needs to be explained.

The “Show Windows Advanced options” will display different options depending on the service you select.  In all cases the options pertain to abilities of the service that can be enabled or disabled, such as redirecting client printers and disk drives, enabling the clipboard, and so forth.

The “Login as console screen” setting allows the service to attempt to connect to the machine console, if possible.

The “Automatically log in” settings allows you to pas through credentials used to login to the SSL VPN (useful if you have the Sonicwall authenticate to the internal AD) or set custom credentials.  NOT setting this means the user will have to authenticate to the local system once the connection is made.

Here is the filled-in screen for an RDP5/Java connection to the Server:

And here is the Virtual Office screen with the additional bookmark:

Clicking on the bookmark starts the connection process:

Note how the emote computer address is listed as 127.0.0.2; the “real” address is hidden because the Sonicwall has created a proxied connection.

At this point the connection is made and the user can login to the machine on the LAN behind the Sonicwall.  This RDP connection has been secured on a number of levels AND there is no port open through the firewall to allow the connection; all of the connection work is done “behind the scenes” using SSL-VPN and the connection proxy. 

One really nice feature of this method of publishing connections is that you can have many connections created and still have no holes punched through the firewall.  This is a much better method of securing RDP access to LAN-based systems using redirected RDP ports through the firewall (eg:  machine one is at port 3389, machine two is at 3390, machine three is at 3391, etc). 

Virtual Office connections are great for direct access to specific machines on the LAN but what about situations where you need access to the LAN itself because you need to access multiple LAN resources at once?  NetExtender provides this functionality (I did say I would circle back to NetExtender).

NetExtender provides many of the same features of a traditional “fat” VPN client but in a much simpler (for the user) package.  To install NetExtender the user only has to login to the Virtual Office webpage once, click on the NetExender button to install NetExtender, then for all future sessions the user can simply fire up the local NetExtender client.  NetExtender works with may different systems including iPhone/iPad and Android devices as well as the usual PC’s.  I won’t detail the installation process as it is literally click the button and then click OK to launch installation via your web-browser.

Assuming the client has been installed the user only has to start up NetExtender, provide credentials and connect, is is as simple as that.  Here is a sample NetExtender connection session (connecting to the same Sonicwall as used for the Virtual Office):

The user is connected, has received an IP on the LAN, and has routes assigned as well as DNS servers.  At this point the user had the same access to LAN resources as they would if sitting in the office.  When finished the user clicks Disconnect and the connection is dropped.

As I said at the beginning of this post, this is not terribly sexy stuff; but it is critical stuff if you are interested in securing your systems.  Too many small organizations (and large ones, too, for that matter) don;t sweat the small stuff.  Yes, you can poke holes in your firewall and publish RDP connections directly to the ‘Net and you can also rely on Microsoft (or other) VPN technologies that also rely on holes poked in the firewall.  But, if you’re like me (and many other IT pro’s) you want to protect your internal resources as much as possible and one way to do this is to NOT punch any more hole sin your firewall than you absolutely have to.  Using SSL-VPN technologies from Sonicwall (and others) is a simple, easy way to eliminate one source of security headaches.