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.

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..