I was trying to enable SSLVPN for the SonicWall TZ100 at a client site and just couldn't get it to go using these directions. I would be able to get the NetExtender software to launch but I couldn't ping across the link to the remote LAN. Looking at the logs on the TZ100 didn't help; the only error listed was "destination for 255.255.255.255 is not allowed by access control". OK, but access control was limiting it from where?

Checking the firewall rules showed the correct SSLVPN->LAN permissions to allow traffic to flow. Checking the LAN DHCP scope showed that the SSLVPN scope wasn't colliding with it. Checked the user account info, it was in the "SSLVPN Services" group. All fine, nothing was different from the official writeup, but no traffic flowing, pings not working.

After poking around at the definitions for each network Address Object, I figured that the user account was only halfway there. The user had been given the rights to the "SSLVPN Services" group so that it could be used to authenticate and connect but also needed to have the "LAN Primary Subnet" listed in the VPN Access tab for the user account to have the rights to pass traffic through to the LAN. And with that change, traffic started to flow.

So, to sum up, the directions to set up a SSL VPN on a TZ100 running SonicOS Enhanced 5.6.0.0-30o are:

1. Configure SSL VPN Access for Users
1. Navigate to the Users > Local Users page.
2. Click on the configure icon for the user you want to edit, or click the Add User button to create a new user. The Edit User window is launched.
3. Fill out the new username and enter the password, or skip this step if this is an existing user.
4. Click on the "Group" tab.
5. In the "User Groups" column, click on "SSLVPN Services" and click the right arrow to move it to the Member Of column.
6. Click on the "VPN Access" tab.
   
7. In the"Networks" column, click on "LAN Primary Subnet" and click the right arrow to move it to the "Access List" column.
8. Click "OK" to save these changes.
   
2. Configure SSLVPN Portal Settings
1. Under "SSL VPN", choose the "Server Settings" menu item.
2. Click the "WAN" item to allow the SSLVPN services to accept incoming connections on the WAN port.
3. On the "Portal Settings" menu item, adjust as you'd like. I'd suggest checking the "Enable HTTP meta tags..." item at least.
4. Click "Accept" to save your change(s).
3. Configure SSLVPN Client Settings (IP address range and enable on WAN Interface).
1. On the "Client Settings" menu item, complete the following fields at least:
1. Interface: likely X0 if you are using a standard setup (X1 is the WAN port)
2. NetExtender Start and End IP: make sure that the range given here does not overlap the LAN DHCP scope elsewhere on the router or another server. Also, if this scope is not in the same subnet as the other equipment, you will need to manually make a Client Route.
3. DNS Server 1 and 2: I used the default public DNS servers for the client's ISP. Just hit the "Default DNS Settings" button to populate these fields.
4. Click "Accept" to save your change(s).
4. Enable User HTTPS login on the WAN (or X1) Network Interface
1. Click on the "Network" menu item and choose "Interfaces" under it.
2. Edit the X1 interface by clicking the pencil in the right-most column of the X1 row.
3. I would check both "HTTPS" next to "User Login" and "Add rule to enable redirect...".
   
5. Alter the SSLVPN->LAN access rules
1. Under "Firewall", choose the "Access Rules" item.
2. Select the "SSLVPN>LAN" item.
3. Edit the "SSLVPN IP Pool" item and change the "Users" item to "SSLVPN Services".
4. Click "OK" to save your change(s). Click "OK" on the message that this will require users to log in from the SSLVPN zone; this is a phantom issue.
   
6. Configure SSLVPN Client Routes (Optional)
1. You only need to do this step if you have your SSLVPN clients on a different subnet.

A client using ESX 3.5u3 had a VM that used a disk file from another defunct (but usable) VM. The defunct VM was finally deleted but the disk descriptor file was trashed in the process. I'm assuming that the only reason the flat VMDK file was still there was because it was in use by the second VM.

After restarting the second VM, it could no longer access or see the first VMs disk file. Looking in the Datastore Browser showed that the VMDK file was still there; what's going on?

The Datastore Browser hides the fact that there are two parts to the virtual disk. The first part is a small file called VMDisk.vmdk and the second part is a large file called VMDisk-flat.vmdk. The first file holds the drive characteristics and geometry, such as sectors and heads. The second file should be the size of the disk as the VM OS sees it.

In this case, the smaller file had been deleted and so the VM couldn't figure out how to address the virtual disk.

Here are links to two very helpful VMwareKB articles:

• Recreating a VMDK header file
• Verifying ESX virtual machine file integrity

The first link has the magic on how to recreate a standard header or descriptor file that should match your flat VMDK file. The second link is a good refresher on the file system parts of your VMs.

For this client, I created a new blank VMDK using the -thin option to save on space, deleted the larger VMDK disk file and renamed the smaller VMDK file to match the existing VM disk file.

I also commented out the existing UUID line in the descriptor file when cleaning it up. I've had issues with UUIDs not matching on Ubuntu VMs and didn't want to hit them here.

After that, the VM started up perfectly.