I got the Barracuda Spam & Virus Firewall Vx virtual appliance working in less than 30 minutes, it’s really easy to setup and use, there is almost no learning curve if your job involving managing email server daily.
In fact, I almost got a Barracuda 300 back in 2008, but the performance back then wasn’t good, now with the VM version, it’s lightening fast, thanks to latest CPU and Equallogic SAN, so I may eventually purchase one of these nice stuff for my clients this month.
One major drawback is the lack of comprehensive reporting capability even after almost 10 years of it’s product life. It can’t even provide simple things like list the top 100 domain name with most email usage and size for a specific day or time, list the top user who used the most email bandwidth, etc. Without this kind of reporting capability, I would say Barracuda can never make to the real ISP enterprise market, it’s good for SMB though.
PS. I just found out Barracuda Networks introduced the Barracuda Reputation Block List (b.barracudacentral.org) for free! Of course, you need to register your DNS server first in order to use it.
Then I found this thread on VMTN which explained everything.
This is not a BUG. However, is the way we understand the HA Settings and Functionality. When in “HA Settings” you specify the “Failover Capacity” as “1″ and you have a 2 NODE Cluster, you are simply telling the HA that in any given instance it will have “At least 1″ spare HOST. Now, when you Manually or Using Update Manager try to put a HOST in Maintenance Mode, HA Failover Capacity is “Violated” because while the HOST is in Maintenance Mode, there is “NO Spare HOST” for HA. Meaning in an event the Second Node goes down, everything goes down and HA will never work. This a Straight Violation to the “Failover Capacity” that you have specified.
Hence, by all means in a 2 NODE Cluster you have to “Allow VMs to Power On even if they violate the availability constrains” if you want them to be Automatically Migrated when you put HOST on Maintenance Mode or use Update Manager. If you don’t want to change this setting and still use this feature you need to add another HOST to the Cluster while keeping the Failover Capacity at 1.
The good thing, it’s FREE with ESX Advance/Enterprise/Enterprise Plus version.
Yes, it’s simply a transparent firewall utilizing VMsafe API, so there is no need to change the default public IP on VMs, vShield Zone (ie, firewall) comes with limited functions comparing to real stuff like Netscreen, but it does get the job done by limiting ports, source, destination, direction on L2/L3 and L4 layer, one extra nice thing is vShield Zone comes with a bunch of dynamic ports based application such as FTP, DNS, etc.
In version 4.1, there is no more separate OVF for vShield agent, it’s been renamed to vShield Zone, and deployment of vShield Zone is simply by clicking the Install link on the menu, it’s so much simpler to install a firewall on each ESX host with v4.1, no need to create any template for vShield Zone like in the old days as well. In additional, A new vSwitch, called vmservice-vswitch, is also created. It has no physical NICs assigned to it and has a VMkernel interface with a 169. IP address. This vSwitch should not be modified. It’s used exclusively by the Zones firewall VM, which has two vNICs connected to it. Through the vNICs , the Zones VM communicates with the LKM in the VMkernel. One vNIC is used forcontrol, and the other is for data path communication.
The original version of vShield operated in bridged mode and sat inline between vSwitches so that all traffic to the protected zones passed through it. The new method of monitoring traffic at the vNIC, instead of the vSwitch, eliminates the vSwitch reconfiguration that previously occurred, and it provides better protection. In bridged mode, VMs in a protected zone had no protection from other VMs in the protected zone, but now that vShield Zones operates at the vNIC level, every VM is totally protected.
So if something happens to the Zones virtual firewall VM (e.g., it’s powered off), the networking on a host will go down, because nothing can route without the virtual firewall VM. If you migrate a VM from a Zones-protected host to an unprotected one, vCenter Server automatically removes the filter, so a VM won’t lose network connectivity on its new host.
Also in the new version of 4.1, VM Flow is gone (it was available free in is previous version), you need to upgrade to VShield App get have it back again. For my environment, I use PRTG’s packet analyzer on switch mirror ports, so such feature is not required.
In this new version 4.1, committed firewall policy is applied in real time, there is no need to login to console and issue validate sessions anymore.
vShield Zone firewall can apply to 3 levels, Data Center, Cluster and Port Groups (?), I usually deploy it at Cluster level due to DRS.
If you have a cluster, then it’s highly recommended to install vShield Zone on all ESX hosts as VMs may got vMotioned between ESX hosts in the cluster and they will still be protected by vShield Zone (ie, firewall).
Install vShield Zone process does not need to reboot the ESX host, but uninstall vShield Zone does require reboot the ESX host, after the reboot, often you will find the originally configured vShield Zone switch is not removed, so you need to remove it manually.
It’s nice to see the extra tab in vCenter interface, but I still prefer to manage vShield using the web interface.
You can always get more features by upgrading to other advanced vShield Products like vShield Edge as those will provide features like VPN, routing, load balancing, etc.
Under Maintenance Mode, vShield Zone for a particular ESX host SHOULD NEVER NOT be vmotioned away although vShield Manage can. You will need to manually shut it down (by using CLI shutdown) after DRS automatically migrates all other VMs on the host and reboot the host. I am still trying to figure out how to set maintenance mode DRS recommendation for vShield VM, if you know, please do let me know, thanks.
I found the solution to my last question in how to avoid vShield Zone VM to be moved away during Maintenance Mode by DRS, the answer is at the end of the Install vShield Zone PDF (Page 13, can’t believe I missed this extremely important piece of information). Basically, you need to set vShield Zone VM Restart Priority to Disable under HA and Automation Level to Disabled under DRS.
To prove it’s working I did a test, I put the host in to Maintenance Mode, DRS was able to vmotion away everything to other available nodes except the vShield Zone VM, then it shuts it down nicely, everything is done automatically.
Comments (0) 
