@Supermule:

You can do that in 4.1 as well :)

The only problem is that if you run HA/DRS then the USB doesnt follow the VM. So if it moves of the server, then the USB is lost….

I dont know if they fixed that issue in V.5

First, HA and DRS are -very- different, not sure they should be lumped together like this.

As far as HA goes, I don't think you -should- expect any software to carry a hardware connection to a device through a hardware failure like that.  In an HA event the Host itself died (or rebooted) so the hardware host to your USB device is no longer functioning.

In 4.1 USB connectivity can be retained through a vMotion as long as the original host maintains connectivity and power and the VM Guests themselves remain powered on and not suspended.

A DRS event shouldn't break the connection, similar to a vMotion.  I have not directly tested this, if you're seeing otherwise, that may be a good reason to call VMWare support to possibly troubleshoot something that could be a bigger problem.  Otherwise, your DRS events should be triggered by performance issues, which I would presume other VMs should/would be moved first.  If you have a bunch of USB connected VMs on one host that seem to be heavy, manually vMotion them to balance the load, if needed.

Unless you're using Distributed Power Management and it shuts off a host that your USB devices are connected to, then obviously, that'll break it.

Basically, I don't think the loss of USB connection through an HA event complaint is all that valid.  You should not be -depending- on a directly attached USB device like that.  HA is all about recovering from hardware failures, and if you're depending on certain hardware, you're breaking that hardware ambiguity.  I know there's certain software that can require a USB "dongle" or key, but there are other USB over IP solutions that might work better in that situation.  (For the most part, that's pretty much what ESXi is emulating, anyway.)

Nevermind, I figured it out.

This is what I did:
1. login into the firewall webgui
2. go to Firewall -> Virtual IP
3. Update virtual IPs
Type: Proxy ARP
Interface: WAN
IP addresses: single IP
Address: 22.22.22.10

Edit your virtual IPs with the new IPs provided
4. go to Firewall -> NAT
5. Select the Port Forward tab
6.  Create new rule:
Interface: WAN
Protocol: TCP
Source: NA
Destination: Type: (select your previously created VIP)
Destination port range: from: MSRDP to: MSRDP
Redirect target IP: 192.168.1.166
Redirect target port: MSRDP
NAT Reflection: Use system default
Filter rule association: Rule NAT

Hope this helps someone!

Cheers!

I have a very similar setup (pfsense under VBox on a Ubuntu 11.04 host) and have noticed the very same behavior.

Apparently we'd have to wait for pfsense to move to FreeBSD 9.0 which has decent virtio net driver support.

@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