I have it working with Xen just fine as well. Works with onboard but also with plug-in PCIe NIC's. Using a 4-port Intel-based one is doing just fine.
Try to see if pciconf sees the passed cards at all, it should say something like:

[2.3.2-RELEASE][john@fw-1-prod]/home/john: pciconf -l | grep igb
igb0@pci0:0:8:0: class=0x020000 card=0x12a18086 chip=0x150e8086 rev=0x01 hdr=0x00
igb1@pci0:0:9:0: class=0x020000 card=0x12a18086 chip=0x150e8086 rev=0x01 hdr=0x00
igb2@pci0:0:10:0: class=0x020000 card=0x12a18086 chip=0x150e8086 rev=0x01 hdr=0x00
igb3@pci0:0:11:0: class=0x020000 card=0x12a18086 chip=0x150e8086 rev=0x01 hdr=0x00

The problem that requires this patch is that it will not be improved unless it is officially adopted in FreeBSD

I see.

Thank you

@Nagilum:

That's our experience from our last LAN, which made us a lot of trouble, because you just have about 2 days and every hour, stuff is not working… :/
That stuff had cost us several hours.

But, whyever, the PV-devices are not shown as limiter-capable and we needed traffic shaping.
For performance reason, we didn't want to take the captive portal, which does limiting, too.

They are limiter-capable here.

Try not using a legacy adapter. Add a "Standard" network adapter in external mode in R.

As others had said, sounds like an ISP problem.

You want to do what?  You want to firewall traffic from your vswitch to your physical network?  Is pfsense physical or vm?

But all this traffic is on the same layer 2, so you want pfsense as a transparent/bridge firewall.  Not going to work as a vm, but sure could do on a physical machine between your vswitch uplink nic and the real world switch…

esxi nic -- pfsense --- switch

Why do you want to do this?  What exactly are you going to be firewalling?  Why do you need transparent?

To know what kind of frontend it is, you need to know what kind of traffic it is? Is it https? or just ssl? or a plain http connection? If it is SSL does it send SNI information? A short wireshark capture of a new connection should be able to tell..

In my Hyper-V setup I set a vNIC for each VLAN.

IE, I have a vNIC for LAN(3 port LAGG), WAN(separate port) that are using default VLANs. Then 2 more vNICs with the VLANs tagged in the adapter settings(using the 3 port LAGG). So as far as pfsense is concerned each 'VLAN' is actually a separate physical interface.

This is probably not an ideal setup for more than a couple VLANs given there is a max network adapter you can have, and it would be pretty messy even if you could, but it works quite well for my purposes.

I know this is an old post,but as long as you choose "other install media" template when installing, it's automatically PVHVM

an easy way to check it's using PV drivers in an HVM VM is go to status>interfaces, they should be named xn0, xn1, etc

Your actually quite behind for build numbers, the current build is 4510822, which is 3 newer than what your running.

I have been running pfsense on esxi for many years and have never seen such an issue.  But then again your issue has ZERO to do be it the pfsense was virtual or on hardware.

You should create your thread in different area, maybe the general area..  What your seeing has zero to do with system being vm or not.

Yes, I believe this should work, I have used several versions of pfsense running on multiple vlans in this way.

You are basically trunking all vlans to the port group and allowing pfsense to do the the tagging instead of the virtual switch or port group.

Ok Problem was fixed. It was port issue. Only 2 connections were allowed.

Personally, I ran pfSense on KVM, with openvswitch.

It worked like a charm, truth be told. Plus, with virtIO drivers, the uplinks to the virtual pfSense were 10Gig. And using openvswitch, the .1Q part was done entire outside of pfsense on the virtual switch.

The pastebin pages were removed so I can't see what it said. I run over a dozen VMs in ESX and none ever crash, and I know customers using it in production with no issues as well.

It could be a hardware issue, a driver issue or OS issue triggered by some combination of options in use. Hard to say, but it isn't a widespread issue.

Apologies I thought I had replied to this thread to thank you. I just wanted to confirm this was the issue for anyone else who might find this thread via searching in the future.

Been running pfsense on esxi for years.. Hundreds if not 1000 is not 10's of thousands of people run routers/firewalls on VM.. Yes it a standard practice..