@trunix:

I've got the Open-VM-Tools-8.8.1 package installed on the pfSense vm I'm running under ESXi 5.1 (installed via the System menu in the pfSense webGUI > Packages).  From what I remember, the regular Open-VM-Tools package gave me some errors, but the 8.8.1 version seems to be fine.  I'm running the i386 2.0.1-Release.  My vSphere client reports the tools as installed and 3rd party/Independent.  You may consider upgrading to 5.1, as it fixes a problem where the pfSense vm (or any other vm for that matter) wouldn't auto-start after the ESXi host was booted.  Not sure if auto-start is important to you or not.

There's another release something like 5.0.1 update 1b that also fixes it. Off the top of my head build number is 8xxxxx

dhatz.

I tested pfsense in virtualbox for over an year and i got always the sam kind of crashes.
Since the main reason i use pfsense is for squid, i always used squid and i believed those crashes every couple of hours were happening because of squid.
Then i installed pfsense without the squid package and pfsense was not crashing any more…...until it crashed but 2 days later.
For a couple of days i believed that squid was the reason but i was wrong.

Having squid installed just makes more frequent reads and writes than not having squid at all.

Since i believed also that it was virtualbox, i tested pfsense with vmware but the very same crashes happened every couple of hours forcing me to reset the VM

So to fix this:
Open your VM VirtualBox Manager
Click on your pfSense VM
Click on settings
Click on Storage
Click on your IDE or SATA controller
Uncheck the Use host I/O cache

Also I don't thing there is any difference between IDE or SATA controller.

I noticed that some snapshots didn't work with SATA controllers but now they do.

But as long as you have that host I/O cache in your virtual storage controller, pfsense works just fine.

There is a little overhead an waste because of virtualization so if you virtualize, make sure you get a powerful computer.

Anyways the more power the better it is with or without virtualization.

Hi miodzicho!
I'm not sure, but see if this post gives you some hints to solve your issues…
Cheers!

Im with matguy on this – VMKernel on public IP?  As stated not a great idea.

So is this as assumed a hosted box?  Do you have physical access, is it say a locker or room/suite at a colo?

That being said the esxi does have built in firewall that you could use to lock down the access to the VMK, do you have console outofband access to the box if needed?

which vSwitch?

VM network (default) or the newly created for the 2nd interface?

Of course all NICs are connected. How would I see the NICs during boot if they weren't connected.

Just to close off on this, I have rebuilt the 32-bit PFSense in a 32-bit VM container, and it's been stable for a week now.  I think that must have been the issue.  Glad to have spotted that or it would have driven me round the bend!

ESX is the host? I'd try configuring the VLAN networking on the ESX side, this way pfSense handles traffic and ESX tags the VLAN.

@jimp:

Just a note, 2.0.1 is based on FreeBSD 8.1 and so is 2.0.2, after that is 2.1 which will be based on FreeBSD 8.3, so if they did get things working on 8.2 and 8.3, it would require at least pfSense 2.1 to function.

Exactly jimp.

Anyway particularly interesting to think MS support to FreeBSD on your Hyper-V. In a way, means that they admit the relevance of the platform in the enterprise!

i guess it depends if you want to use the vmxnet drivers or not.
if you only want to be able to have your guest shutdown nicely by *tools then the open-vm-tools work fine

I never noticed the clock stopping, buit it was probably just cause I wasn't observant enough.

I wonder if this was related at all to my puzzling pfSense stability problems under ESXi 5.0.0 where the DHCP function would just stop working at random intervals.  Clients already assigned IP's would continue to work just fine nd data would be routed to them,  but new clients would not get IP's and not function at all.

It was a puzzling issue I never quite figured out.  In the process of reinstalling with 5.1 now, time will tell if the issue disappears.

Personally I don't want to risk any slowdowns to my router from the vSwitches and virtual adapters, so I forward my dual port Ethernet NIC (Intel EXPI9402PT) directly to my guest using DirectPath I/O.

@cmb:

I've seen about everything there is to see with this kind of stuff countless times, people would be a lot better off if they just believed me. ;D At least you fessed up to it, thanks for the follow up.

Glad you found and fixed it. And that I was right. ;)

No need to rub it in though.. ;)

Microsoft is interested in as wide of OS support as possible in Hyper-V, proven by the FreeBSD support code they put out very recently. We'll be integrating that post-2.1. In the mean time, I know of some minimal usage installs running on Hyper-V, but I'd strictly recommend serious production installs on hypervisors that have had FreeBSD support for ages (VMware is best, but others work great too).

They are server grade Intel nics, MT series I believe. Do I need to configure the nics in a certain way?

@iFloris:

Recently I ran across a similar problem.
The latest update to 5.01 (not the Pro version) fixed it for me.
Have you tried 5.01 yet?

I am not sure if Fusion 5.0.1 solved it or not.

I have moved my PFsense FW VM to a different Mac.  The original phsyical host had only a single ethernet, and an Airport card.  The PfSense interfaces were:

em0 = WAN = Mac Ethernet
em1 = LAN = Mac airport card

I have moved the VM to a new Mac, a Mac Pro tower which has two physical ethernet ports.

Also… I rebuilt the VM for pfSense and this time I chose not to upgrade the VM hardware.  I stuck with the older version of Fusion 4.0 rather than update the HW to Fusion 5.0 (Even though the VM is running under Fusion 5.0.1)

I have it working.  But... at some point I will move the VM for pfSense back to my Macbook Pro and test it again with a single ethernet and an airport.

Unfortunately too many things changed within my environment for me to determine what the fix was.

you can do it with an L2 managed switch. my setup has:

on the switch:
port 23 = tagged vlan100 with vdsl modem connected
port 24 = tagged vlan100, vlan201, vlan202, vlan 203 which is connected to intel nic on esxi5 host
other ports on switch tagged as required

on esxi host:
virtual switch is set to allow all vlans (vlans are not set here)

on pfsense vm:
interfaces are set as vlan - vlan100 = wan, vlan201 = lan1, vlan202 = lan2, vlan203 = lan3
wan interface is pppoe

although i haven't tried it, i would imagine if i wanted a multiwan, it would be as simple as adding another vlan eg vlan101 to port 22 & 24 of the switch and to pfsense and then set the desired routing.

Come to think of it, I don't really know what would be considered best practice for deploying pfSense on a Type 2 virtualizer as a primary firewall.

I'm going to start another thread asking just that.

http://forum.pfsense.org/index.php/topic,53469.0.html