Stange. That'd mean that the XenServer product is using a Dom0 that doesn't play nice with the hardware. I checked my inventory, I have two HP servers running Xen (not XenServer, just Xen), a DL180 G6 and a DL360 G6, and they are doing just fine. They are nearly identical setups; Xen 4.6 and Xen 4.8, but both Debian 8 as a Dom0 host, pfSense 2.3.2-p1 as firewall and a bunch of DomU's, all Linux (mix of Debian and Fedora). I'm using the internal NIC's on both of them, and pulling 100Mbit up/down. (branch office uplinks)

Running it with Xen but also the XenServer product, no issues since 1.2.x… works fine!

Hello all and a good 2017 for all.

I have a new Intel i3-6100 3.7GHz with an Asus H110M-K board that don't get the  I for installer. It fails to mount the DVD.

Any help would be very usefull.

Thanks a lot in advance.

Problem solved,

Symantec was blocking the traffic on the host  :o i don't know how but disabling the AV solved the problem…

Thank you all for the support.

Thanks for coming back and letting everyone know what happened.

@gjaltemba:

Hyper-V 2016 supports Discrete Device Assignment (DDA). With the proper hardware, you can pass a physical nic to the vm.

That sounds good. So that would be the perfect option for the WAN interface, where I am still at least a little bit worried that the host might somehow somewhere get compromised? (At least it manages the virtual switch on top of it in my configuration right now - even if it is not connected itself.)

Which commands were executed on pfsense?
System: Advanced: System Tunables
hw.em.txd value
hw.em.rxd value
right?

System 2 Nics  Wan -em1000 and Lan -em1000

I'm running PFsense in a Hyper-V server and its been running great for months.

This guide is pretty much how I set mine up.

www.erickscottjohnson.com/blog/how-to-install-pfsense-on-windows-10-pro-hyper-v-with-2-physical-nics-part-1

As for the virtual switches. I would recommend you create the virtual switches as described in the article but ALSO edit the properties and set a custom MAC for each of the NICs. This way during the PFSense install and selection of the NIC ports, you will know what MAC is the WAN and the LAN. No need to guess.

There is a few articles out there that are mostly correct but they state to use the Legacy Network Drivers instead. Don't do this. Just used the standard Hyper-V NIC drivers first. Then try Legacy if you are having issues getting connected to the internet or address LAN etc…

Hi Guys,

Thank you all for your reply.
The guilty was the couple BSD/Xen.
I disabled TX offloading on pfsense but forgot to do the same on the hypervisor (XenServer 7).

The following did the trick :)

xe vif-param-set uuid= <vif uuid="">other-config:ethtool-tx="off"
xe vif-param-set uuid= <vif uuid="">other-config:ethtool-tx="off"

Thank you again</vif></vif>

He wants a VLAN testing lab as the topic states.  Literally, an environment where he can play with configuring VLANs.

So we've put in static entries for the arp tables via /etc/ethers, as a temporary work around, in our RHEL 6.8 and 7.3 VMs.
Is this configuration which works in pfSense 2.0.1 no longer supported in pfSense 2.3.2?

I think the script should be not just /usr/local/etc/rc.d/fixtime but
/usr/local/etc/rc.d/fixtime.sh
I have two scripts that are working fine on startup.
May be its needed full path to sysctl to be added.
/sbin/sysctl kern.timecounter.hardware="ACPI-fast"

Anyway I glad you have solved it, but it looks a little bit strange that nothing works as it should just for you. I think the devil is in the details.

I have contacted the internet provider, but its i think its strange if its something wrong with the internet? since it works ok with E.G Windows?

@dotdash:

Wouldn't it be simpler to create a new VM with a larger disk, install fresh, and restore the config?

Much, much simpler. You'd be back up and running in minutes. Before any disk clone would ever have finished.

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.