Welcome …

Posted on

VMWare: ESX Microsoft Visual C++ Runtime Library Error When Using Converter Plugin

This error message is displayed during import or export of a machine under vCenter Converter plugin and sometimes with the standalone converter.

If a user environment has versions of VI Client 2.5 Update 1, Update 2, Update 3, or Update 4 that coexist with vSphere Client 4.0, and you install the vCenter Converter 4.1.0 client plug-in, when you start the vCenter Converter Import or Export wizard, the vSphere Client session is terminated abruptly. An OpenSSL DLL conflict between the VI Client versions and the vCenter Converter 4.1.0 client plug-in causes this problem.
Workaround: Go to the Launcher folder in the VI Client install directory, for example, C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher, and delete the following DLL files from that location:

  • libeay32.dll
  • ssleay32.dll

For this workaround to function correctly, you also need to ensure that no additional copies of OpenSSL DLL files with different versions exist in the system path.

Also, make sure that the %TEMP% path does not have any non-english characters in it e.g. if you are using French / German / Spanish Windows OS. If you are, create the C:\TEMP directory and update your environment variables to point here.

Note for ESX users: if the fixes above do not work for you, try uninstalling all your VMWare clients, reboot and install the vCenter client from your vCenter’s https page. Now try and access your host using the vCenter client – you will connect and be prompted to download and install the Infrastructure client – if you do it this way then you shouldn’t have any issues.

No related posts.

Posted on

CheckPoint: ISP Redundancy Limitations

When using ISP redundancy with load-balancing, there are a number of limitations where routing comes in to play, I’ll try to bullet point a few rules:

* In general, traffic responses will be routed back through the pipe the requests went out on. (you can force it to do otherwise but then you are into asymmetrical routing and you will be lucky to get your responses.)

* Anything with a static NAT will be forced out through the 1st link

* You can force certain services to go through your first link but you cannot force anything to go through your 2nd link – see here for instructions.

* You cannot use hide NAT to force anything to go through one link or the other – Checkpoint per se does not support source-based routing (policy-based routing)

* You can in theory force one particular machine to route through the 1st link by statically NATing it to a free public address on your subnet but you will need to have 1 routable IP per machine for which this is to be done. You cannot  force any traffic / services through your 2nd link.

If you really need the flexibility to route your traffic based on services and/or source IPs then you can:
* install a router in fron of your firewall which does policy-based routing

* if you are running on linux or SecurePlatform then you can configure the iproute2 daemon (this will NOT be supported by Checkpoint)

* if you are running on Nokia IPSO boxes then Policy-based routing functionality is built in from IPSO 4.2 build 069 onwards.

No related posts.

Posted on

Checkpoint: Configure Wireshark for “fw monitor” Analysis

This article guides you through setting up the Wireshark packet analyser to interpret captures as a Checkpoint FW-1 capture. This will only have an effect on captures taken using “fw monitor”, all other captures will read as normal.

1. Edit -> Preferences -> Protocols -> Ethernet -> Check “Attempt to interpret as Firewall-1 monitor file”:

Wireshark Preferences

 

2. Edit -> Preferences -> User Interface -> Columns -> click “New” to add a new column – give it a title of FW Monitor and choose FW-1 monitor if/direction as the format:

Wireshark Preferences

You should now have an extra column when you open a capture file – if you open an fw monitor capture file you will see  4 entries for each packet tracked as they go in one interface and out of another.

The ethernet interfaces e.g. eth0, eth1 etc etc are marked with either i, I, o or O.

i = pre-incoming ……….. I = post-incoming

o = pre-outgoing ……….. O = post outgoing

So ..

1          i    eth0                                  <- pre-IN: this is the packet as it arrives at the interface

2               eth0    I                            <- post-IN: this is the packet leaving the interface, now in the CheckPoint kernel

3         o    eth1                                  <- pre-OUT: this is the packet having left the kernel and arriving at the egress interface

4                eth1    O                           <- post-OUT: this is the packet leaving the interface

This is dead handy for loads of troubleshooting situations, an ovious one is NAT being applied, e.g.:

A packet from internal IP 10.1.1.1 headed for a destination on the internet 4.2.2.1 through a firewall with an external IP of 81.82.83.84 would look something like:

SRC                   DST                       FW1

10.1.1.1                4.2.2.1                i   eth0

10.1.1.1                4.2.2.1                eth0    I

10.1.1.1                4.2.2.1                o   eth1

81.82.83.84       4.2.2.1                eth1    O          <- NAT has been applied and the source IP is now the firewall’s external IP

Related posts: