A bunch of Sonicwall goodies–Part 2, SRA (secure remote access)

Sonicwall has a range of remote access servers that can be very effective in various situations.  There is the SRA range suited to smaller installations (think SMB/SME) and the larger E-Class SRA series that more suited to larger organizations or applications that require a whole bunch of connections at once.  I’ve seen the E-Class units in use by very large organizations such as UPS but I want to focus on the smaller SRA devices as I think there is a lot of suitability to smaller organizations that need the security these devices supply.

In simplistic terms, the SRA devices offer a number of secured, proxied connection services that wedge themselves between your LAN and the outside world. They build upon the basic SSL VPN features offered in the Sonicwall firewall products and give an expanded range of options.  I like them because they allow you to very quickly build up customised, secured access for remote users to various inside services without having to spend a lot of time doing so.

The SRA’s offer SSL VPN, secured web access, secured RDP/VNC/Telnet/SSH access, secured remote meeting access (sharing a desktop on the inside LAN), secured support access as well as a few other features.  The big point to remember is that all access is proxied via the SRA, there is never a direct connection made between a user on the outside and a service on the inside.

I had cause recently to install an SRA at a customer that had a requirement to make secured access to an internal webpage available to various trading partners.  Their application vendor had built the website on a local IIS installation on the customer’s terminal server (long story but the LOB application is simply monolithic so everything the customer does is tied to that terminal server).  I did NOT want to expose the website directly to the outside world for all sorts of obvious reasons but the biggest reason was simply that the application vendor had done a lousy job of writing the website code.  The website is a security disaster waiting to happen if exposed directly to the outside world.  I wanted to give the customer the ability to use the website with their trading partners without putting all concerned through a number of hoops and the SRA seemed to fit the bill.

One very nice feature of the SRA series is that Sonicwall offers virtual appliances as VMware virtual machines alongside their range of physical hardware.  As my customer has a VMware environment it seemed a great way to go and, to my mind, a very cost effective way to implement an SRA. I obtained the latest version of the SRA VM, installed it into the customer’s VMware infrastructure, did the initial config and licensing and that was that, the appliance was ready to do its thing.

If you are familiar with Sonicwall firewalls then the SRA interface and operation will feel pretty much the same, the main login screen is similar to the firewall’s SSL VPN login page:

Once you login you get the main admin screen which also has a very familiar look:

I’m not going to go through all of the settings and options in this post but I will point out a few things.  The virtual appliance comes with two “NIC’s” as can be seen in the Network Interfaces section.  The recommended configuration is to only use one NIC in a “one-armed” configuration and that is how I have set up this SRA.  The NIC connection is made to a port on the DMZ network provided by the main Sonicwall firewall and it is the firewall that handles directing traffic to/from the SRA.  And for those of you that are asking the question … yes, the VMware host has a vSwitch with a physical NIC attached that services ONLY this VM and it is that NIC that is physically cabled to the DMZ network.

The two features I needed to set up the required access for the customer are available under the PORTAL section.  Almost everything that you do on an SRA revolves around “portals”.  It took me a little bit to latch onto what a portal actually is but it really boils down to a portal being a specific site on the SRA that provides specific published services to users that are authorised to access the site.  There is also the concept of DOMAIN but this is not a domain in the Windows sense but rather simply a way to slice and dice user access.  Using portals and domains you can build up a series of sites that provide very specific access and services to very targeted users.  In my customer’s case we are going to have two portals to start, one to provides access for their trading partners to the internal website and another to provide access to systems and services for authorised technical users.

A portal creates the top level collection to hold all the links that will be displayed to the users in question while the domain generally defines a group of users and how they will be authenticated.  Again, in my customers case, one domain will have users that are authenticated against a local security database within the SRA as they have no “internal” user equivalent. The second domain will provide authentication against the internal Active Directory.  Once you get your head wrapped around these concepts the rest falls into place very quickly.

When you have your domain and portal created you can start to populate the portal with “bookmarks”.  A bookmark defines a service that will be published to a portal and can be one of the following:

The Web choices were important to me as they were what I needed to create the secured remote access to the internal web site.  The rest I think are pretty self explanatory.  Some of the choices echo those seen with the SSL VPN capabilities of the Sonicwall firewalls but others such as the Web selections, file selections and Citrix selection are only available with the SRA.  Configuring a bookmark is quite easy as can be seen below (this is the start of a Global Bookmark (goes across all portals) for a Web proxy):

 

NOTE:  The Group Bookmark lists all the current domains so you can select a specific domain OR user to tie a bookmark to.  Remember, a portal is tied to a specific domain so assigning the domain effectively also assigns the portal. 

Once bookmarks are created they are automatically published through to the correct portal.  Users can then access the published services by connecting to a portal by pointing a browser at https://full.url.com/portal/portalname.  Once logged in the user will see something like the following:

The various bookmarks show up under various tabs and you simply click on the bookmark to connect to the published service.  Also note that the communication between remote user and the SRA is encrypted (SSL) as is the communication between the SRA and the internal service.  At no point in the communications link is there any unencrypted traffic and at no point in the link is any internal service directly exposed to the WAN.

As in all things Sonicwall there is licensing involved but the SRA devices, particularly the virtual appliance, are quite cost effective and can be licensed for many tens of concurrent users.

The technology is not “sexy” but it is solid, it works well and you don’t need to be a PhD in Rocket Science to figure it out or to get it implemented.  If you have a need to secure access to many types of internal services or even to secure internal access to remote resources (yes, it can work both ways) then the SRA might fit the bill.