Tor and Tortilla

I was finally able to get around and test Tortilla. Tortilla allows you to send all traffic through TOR when using a virtual machine.No need for additional software or VPN's

Download the Tortilla software HERE

You will need TOR Expert Bundle. Download that HERE

When installing the TOR expert bundle i had to install it as an administrator. Right click the EXE and choose Run As Administrator.

Once you have TOR and Tortilla installed, run TOR and once it loads up, run Tortilla. The first time Tortilla runs it will take a couple minutes to install the adapter.

Once both pieces of software are running you will need to add or adjust your VMNET on your virtual machines. Those of you who have VMWare Player will need to somehow extract the vmnetcfg.exe and library file from VMWare workstation. Below are some helpful links:

Link 1
Link 2

Once you have the ability to edit the network configuration you can modify and exisitng VMNET or create a new VMNET and bridge the Tortilla adapter to it. Please note, I was only able to modify the VMNET0 since I did not have the option to select the Tortilla adapter when i created a new VMNET to bridge to. I am not sure why.

Once all of this is setup (Installing Tor expert bundle, Tortilla and modifying a VMNET to bridge to the Tortilla adapter) you should be able to select Custom in your VM network settings and select the VMNET that is bridged to the Tortilla Adapter. In my case this is VMNET0:

At this point in time power on your VM and all traffic will be sent to Tor using the Tortilla adapter.

Lexis Nexis Bridger Insight XG SmartClient MSI

We use a program from Lexis Nexis called Bridger Insight. Normally this software is a simple "ClickOnce" type of program that will update itself. However, since we are in a Terminal Services environment with roaming profiles we have to use the MSI version.

When using the MSI version Lexis Nexis pretty much wipes their hands of any technical support saying you assume any risks when using this product. That's all good and dandy as I understand everybody's environment is different and trying to troubleshoot something can take a long time.

Over the weekend they had an update. Normally all that needs to be done is to run the new MSI. The MSI will usually uninstall the old version and then install the new version. This time it was throwing out "ERROR 1714. Call Tech support." when trying to remove the old version. I even tried uninstalling it using Add//Remove Programs.

Tech support wasn't much help, suggestion something I already did and then of course reiterating that I assume all responsibility when I went into the agreement for the MSI version...blah blah blah.

After some digging and using a 3rd party uninstaller I found 2 registry entries that are not removed when uninstalling the program:

HKEY_CURRENT_USER\Software\Microsoft\Installer\Features\ODBA2711A9D468F4A9E21433FF2120B0

HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\ODBA2711A9D468F4A9E21433FF2120B0

HKEY_CURRENT_USER will be whatever user you used to install the program. In my case, Administator.

Once you delete that folder under Features and Products you can install the new MSI.

This now brings me to another subject (I'll be quick, I promise): Why don't software vendors support their products or at least try and make the install/uninstall smooth? It seems to me that no one wants to troubleshoot anything anymore. I competently understand that its getting harder to troubleshoot with so many different pieces nowadays but that's part of the job.

New Private Search Engine

I came across a new seach engine called Disconnect. It's a plugin that allows you to use several search engines without giving them your personal information.

ESXi 5.0, LUNS, SANs and Mulitsessions

We recently installed and configured new Overland S5000 SANs for our virtual environment. In doing so we noticed tons of errors once we added the SAN IPs to our iSCSI Software Adapter. The vmkernel.log was saying that the SANs were offline and then online and then offline and then online constantly.

The issue turned out to be that our new SAN doesn't support Multisessions. It doesn't like seeing the same subnet connecting to the SAN network cards and controllers.

What we ended up doing was putting each NIC on the two controllers in their own VLAN:

Controller 0, NIC 0 - VLAN 2
Controller 0, NIC 1 - VLAN 3
Controller 1, NIC 0 - VLAN 4
Controller 2, NIC 1 - VLAN 5

With this setup you will need 4 NICS on each host, one for each VLAN to ensure redundancy and multipathing. Each ESXi NIC would go to one VLAN.

Intstalling Python easy_install

I'm posting this is case anyone gets confusing search results like I did. If you want to install easy_install type this at a command prompt:

sudo apt-get install python-setuptools

If for some reason you get an error you may need to do:

sudo apt-get update
sudo apt-get upgrade

Once it's installed you can use easy_install like this:

sudo easy_install web.py

or whatever program you need to install.

Removing LUNS and Datastores on ESXi Hosts 5.0 and above

We had a need to remove the LUNS from one of our SANS. If you go to your iSCSI Software Adapter and remove the SAN IP's from the properties (Dynamic and Static tabs), you will have issues when the ESXi host rescans the HBA's and VMFS stores. The reason is because you didn't remove the datastores from the host. The proper order to do this is:

1. Unmount the datastore from each host
2. Detach the LUNS from each host
3. Remove the iSCSI IP's of the SAN from your iSCSI Software Adapter (or appropriate adapter)

Unmount The Datastore From Each Host
To do this you will need to go to the Datastore view and find the datastores attached to the LUNS. Right click and select unmount. A screen will come up letting you know if you can unmount the datastore. You should remove all VM's and it can't be part of a datastore cluster.

When you unmount the datastores it will ask you which hosts to remove them from. This saves time from having to go to each host and unmount.


Detach The LUNS From Each Host
To do this you will need to go to your configuration tab and then select Storage adapters. Select your storage adapter (mine is the iSCSI software adapter).

When you select your storage adapter you will see all of the LUNS on the bottom. Find the LUNS that you want to remove and right click and then select detach. Make sure you are selecting the right ones.

I had to to this for each host and each LUN. It took me a few minutes. I don't see an option to do this for all the hosts at the same time like we did with the unmounting of the datastore.


Remove The iSCSI IP's of the SAN From Your iSCSI Software Adapter (Or Appropriate Adapter)
Still inside your Configuration tab and Storage Adapter, right click your iSCSI Software Adapter and select properties. Go to Static entried and remove the IP's one at a time of your SAN. Do the exact same for the Dynamic tab. Once you do that click CLOSE and have it rescan.

The reason you want to go through all of this is because the datastores that are still mounted on those LUNS will cause issues if you just remove the IP's from the storage adapter. When it rescans it will take forever and could cause it to lose connection to the vCenter. Since the datastores were not unmounted the ESXi host doesnt know what to do and keeps trying to access it.

If you don't have any datastores on those LUNS, then you should be able to remove the IP's from the storage adapter and rescan.

Importing Certificates with Watchguard

I came upon an interesting problem while trying to set up SSL VPN on a Watchguard XTM 5 series firewall. Every time I would import the certificate I received from my CA, the firewall would simply say Error in importing certificate.

What I ended up doing was grabbing the root certificate and Intermediate certificate from the CA's website and importing it into the firewall first and then importing my SSL cert.