Have you tried to do so and are having issues, or are you simply asking if it is possible?
If you have tried and are having issues, what kinds of error messages are you seeing?
I have performed a number ofr Virtual Firewall installations, but have to confess that I've not peformed and installation (physical or virtual) in transparent mode. Certainly, when running through the console setup wizard on a virtual installation, you are still given the option to install in transparent mode, so I assume it is possible.
Essentially, as far as I can work out, you would need to ensure that you have two interfaces configured which are assigned to different vSwitches within the virtualization environment - just as you would if you were trying to do this on a physical device. Whether they are then mapped to physical NICs in the box would depend on whether you are connecting this Firewall to a physical network or whether you are using it to separate machines within the VM environment.
Have you tried it in standard mode first to make sure that the client machine (DJ-W2K8) is able to see the corresponding interface on the virtual Firewall?
If it doesn't then there's something else wrong (though the VM network configuration looks OK from here). If it does then maybe you can't do transparent in a VM installation. Unfortunately, as I've already said, I don't have any direct exposure to transparent configurations. The McAfee guys on this forum tend to come on line a little later in the day, so it may be a case of waiting to see what they can offer or raising a service request with McAfee technical support.
Having said all that, the Firewall Enterprise Virtual Appliance installation guide (downloaded from a KB article dated 19th December 2012) does contain the following info, which probably answers your question:-
(Page 23 - Quickstart Wizard Responses)
Do you want the system to have a standard interface setup or a transparent (bridged) interface setup? - Press s. Note: Firewall Enterprise, Virtual Appliance does not support transparent interfaces at this time.
It is still worth checking with Technical Support. Even though the KB article has a very recent date, the actual installation guide PDF file contained within it is for version 8.0.0. Given we are now on 8.3, this may have changed.
But, the presence of this statement along with your results would strongly suggest that is still doesn't work in the virtualised version.
This is how I got it to work in vSphere:
- You need to click on the name of ESX server itself (not one of the machines)
- Click on the Configuration tab
- Find the vSwitches that 'contain' the two interfaces of your firewall, click 'Properties' (so, you have to do all this twice, on two different vSwitches)
- Click on the name of the PORT GROUP, NOT the vSwitch!
- Click Edit
- Click the Security tab
- Check the box next to Promiscuous Mode and change the dropdown to Accept
If you do this on the vSwitch itself (uncheck the box next to Reject) all the machines connected to it will start to see ALL the traffic on the switch. Firewalls connected to this vSwitch will start to RST packets that are not destined for them. You will lose connection to this ESX server then also because the firewall connected to the vSwitch will start to Deny all the VMware server traffic itself. Try not to do that :-).
This error has been caused by a misconfiguration of sendmail, causing a mail loop. Sendmail will continue to spawn processes until the system resources are fully utilized. The article below will help prevent sendmail from doing this, but ideally we should find the misconfiguration causing the loop.
KB61274 addresses limiting the number of sendmail process that can be going at once.