@Matty-CT:

I have two cluster nodes (for this test) in the same cluster, One an AMD based HP Proliant and the other an Intel based HP Proliant.

AMD based Hyper-V: fail as in screen shot.
Intel based Hyper-V: success

On a sidenote, the above config is not supported by Microsoft and I don't think you VM's are going to be that happy when doing live migrations…

FML.

I had my Killer E2100 NIC set to 10Mbps.

ESXI sounds like what you want.

You have two NICs in the box, right?  On the host just configure the WAN NIC so that it has no IP addresses assigned to it and does not attempt to acquire any.  The LAN NIC can either acquire a local IP from the pfSense VM or be configured manually to use it for its gateway and DNS if DHCP is not picking it up in a timely manner.

Well, I never did solve this problem, but I did notice one morning while watching both the pfsense consoles that this is happening on that they both error out at the same instant, so I do suspect that it has to be the underlying hardware or host OS. This usually happens in the morning right before the boss (and her iPad) show up at around 8:00am, but there is no cron job taking off at that time. Weird.

Since none of the other machines that are running on this server have given me so much as a hint of trouble in a similar way, I am just going to chalk it up to pfsense does not like this box. I moved both VM's to a server running proxmox. So far - smooth as silk. I hope it stays that way. Crossing my fingers - I hate getting phone calls on when on vacation!

works in 2.1
http://forum.pfsense.org/index.php/topic,50128.msg266531.html#msg266531

Hi,

i have 100% your shema (and more ;-) here running. You must configure the two bridges in proxmox. One for the DMZ and one for the internal network.

Here is an example from my /etc/network/interfaces

## this is for the internal network auto vmbr0 iface vmbr0 inet static         address  192.168.1.3         netmask  255.255.255.0         gateway  192.168.1.1         bridge_ports eth0         bridge_stp on         bridge_fd 0 ## this is for the DMZ - Pfsense auto vmbr10 iface vmbr10 inet manual         bridge_ports eth1         bridge_stp off         bridge_fd 0

Now create the cenos and assign one network interface to vmbr0
Create the pfsense machine an assign to network interface to it. One to vmbr0 and the dmz/modem to the vmbr10

Valle

What software are you using?

Right now, for all of my pfSense boxes are running in KVM virtualization.
http://www.linux-kvm.org/page/Main_Page
But on client's site I also manage VMWare ESXi. I've also tested Citrix XenServer, Proxmox and few other platforms..
Right now, I'm going to learn something about Open vSwitch,
http://openvswitch.org/
which I belive can support LACP for VMs, VLANs and other advanced network features.. I'm also interested in DRBD as HA solution for KVM
http://www.drbd.org/
and Intel Vt-d / IOMMU as solution to attach physical NICs to the VM.

I'm sorry to say this, but I don't read books :( recently only one. I'm testing, testing, testing.. just check in practice.

Have you read this thread?

http://forum.pfsense.org/index.php/topic,36562.0.html
Clean Install with pfsense 2.0 using transparent firewall

I actually fixed it and got it working. Turns out I had to configure the WAN interface on the host side.

My /etc/network/interaces file now looks like this:

# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 0.0.0.0 auto eth0:1 iface eth0:1 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers 192.168.0.1 # The WAN interface auto eth1 iface eth1 inet static address 0.0.0.0

ok. I have:

Reboot VM
added a second interface by VM
assigned a new LAN IP
Vm tools is also unmanaged.

S.

I've accidentally destroyed ESX 4.0 networking on single host after connecting all available 8-cables (2 x Quad Gigabit network cards) to single switch.
I did nothing more than plugging all cables to single switch. Worked on 5 hosts. Didn't worked on 1 host.
Don't know why it was responding on one part of company (ICMP ok), and was unreachable on other part (ICMP unreachable).
I think this was a driver failure in ESX, since I was able to get all 8-port working in LACP mode under LiveCD Linux distro.
I had to reinstall ESX to ESXi 4.0 then it worked with all 8-ports used with link aggregation mode IP hash.

Hope this helps someone one day.

esx-teaming.png
esx-teaming.png_thumb
esx-nics.png
esx-nics.png_thumb

Ive had some stability issues since updating to 2.0.1 on AMD architecture. Prior to this my WMware+Pfsense setup worked flawlessly.

Since the update after a couple of days of uptime it starts acting up (can't access various pages of the webgui, ssh goes down, WAN goes down but WAN2 stays up, all sorts of odd behaviour). After a reboot things clear up for a few days then rinse and repeat.

I found another PFsense thread by someone with a similar problem: http://forum.pfsense.org/index.php?action=printpage;topic=47354.0

I tried to fix located here: http://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards - but whoever wrote the fix in the wiki was mistake, you cannot do as he suggests and set "hw.em.num_queues=1"

Any ideas? Should I just go back to 2.0 or should I perhaps try one of the new experimental builds? The funny thing is that I can generally fix the problem even when I'm not home by remoting into the Windows 7 Machine through WAN2 and rebooting the VM. However, I would much rather just see it work all the time.

Here my vmware configuration

Cattura.JPG
Cattura.JPG_thumb

Lots of things to check here:
http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

But first stop would be the firewall logs, then checking the state table to see if it shows up, some packet captures, etc… Only so many things to go wrong with a port forward.

It wouldn't be a security risk, but the OS itself will just not see it until you reboot. Those types of NICs are only probed at bootup and wouldn't show up if added while the VM was running. In some cases, adding hardware like that could potentially panic the OS.

That isn't the case with dynamic hardware (USB, cardbus, etc) but those are special cases and not something you'd want to use for NICs, especially in a VM.

I don't think freebsd even has expresscard hotplug support.

So, long story short, it's best to power off the VM, add the NIC, then boot it back up.

Or use VLANs, but in ESX it's generally best to use virtual NICs/vswitches rather than VLANs.