FYI: in my case the error happens using qemu as hypervisor, and my OpenStack was configured to use it. With KVM it works correctly

I've got several pfSense VMs on ESXi 6.5 using vmxnet3, including 1-2 on VM version 13. It all works fine.

Most likely something else changed in your switch setup so the VM is not connected where you think it is.

@jimp:

TSO and LRO are meant for workstations and servers/appliances, NOT firewalls or routers. Do not uncheck those.

It isn't a FreeBSD thing or a pfSense thing, the fundamental design of LRO is not compatible with routing/firewall roles.

Hmmm, that's good to know. I had no idea, I've always had those two boxes unchecked. For whatever reason I haven't had any issues with it but it seems that it isn't the best/most efficient setup. - Are there any implications other than potentially reduced performance? i.e., since I didn't have any performance issues, is there any other negative impact from having been using these settings such as increased CPU load or anything?
Also, is there any difference how these work in a virtual v physical machine? Or is it purely whether the machine is a client or a router?

@jimp - would it be possible to reword the GUI text on these in 2.4? I also was thrown off by the "broken in some hardware drivers, and may impact performance with some specific NICs" In my opinion this is pretty misleading after having read your above post. It makes it sound like you might have trouble if you happen to have a certain NIC, when in fact it seems that you will be misconfiguring your device if you are using it as a router - which almost everyone here is.

I would suggest something generally along the lines of:

Checking this option will disable hardware TCP segmentation offloading (TSO, TSO4, TSO6). This offloading is broken in some hardware drivers, and may impact performance with some specific NICsintended for machines configured as clients, NOT routers. This will take effect after a machine reboot or re-configure of each interface.

Checking this option will disable hardware large receive offloading (LRO). This offloading is broken in some hardware drivers, and may impact performance with some specific NICsintended for machines configured as clients, NOT routers. This will take effect after a machine reboot or re-configure of each interface.

I am running 2.3.4 installed on a Hyper-V guest under Windows 8.1 and have VLAN trunking working.

What native VLAN id did you specify? I had trouble with anything other than 0, as Windows strips the VLAN tag off traffic matching the native VLAN id before serving it to the VM.

Hi, I'm also trying to use PfSense inside OpenStack.
I'm able to start the VM and the interfaces seem to be configured correctly. Anyway I'm always having an error running pfctl -o basic -f /tmp/rules.debug

/tmp/rules.debug:18: cannot define table bogons: Invalid argument pfctl: Syntax error in config file: pf rules not loaded

Have you faced this?

…This is where it might be a little scary - the system won't boot into the shell - instead, you see this:

simply type in
ufs:/dev/da0s1a
and hit enter, then hit enter again to get to the # prompt.I change into /sbin again, and issue ./growfs /dev/da0s1a again:

and a gpart show after:

Now we need a swap file again:
./gpart add -t freebsd-swap da0s1

After that, I activated the swap by issuing ./swapon /dev/da0s1b , but rebooting should take care of it.
I type exit and hit enter to reboot, then do an option 5 once the console menu comes up to reboot again.  After a normal boot, choose option 8 to get to the command prompt and do a gpart show (it's in the path now), and you should see your expanded partition.

So far, it hasn't given me any trouble.  If I've made any obivous mistakes in here, please let me know.

snm777's instructions worked for me! Thanks!

Couple of additional issues
Got a warning that the swap file size was larger then the kernel config allowed.
Backed it down to 4GB and it was fine.
Steps:
./gpart delete -i 2 da0s1
./gpart add -t freebsd-swap -s 4G da0s1
./swapon /dev/da0s1b
./exit
hit enter to reboot
option 5 once the console menu comes up to reboot again. 
After a normal boot, choose option 8 to get to the command prompt
./gpart show
No further complaints about swap file size.

I also got the mountroot> issue every time I rebooted.
I mounted using smn777's mount command: ufs:/dev/da0s1a
Once pfsense was running I looked at fstab and foud some strange entries for the root and swap partitions.
I performed ls /etc nd saw that thee was fstab and fstab.old files using vi.
I looked at fstab.old and the entries were what should have been in fstab.

Device                Mountpoint      FStype  Options        Dump    Pass#

/dev/ada0s1a            /              ufs    rw              1      1
/dev/ada0s1b            none            swap    sw              0      0
I replaced fstab with fstab.old
./mv /etc/fstab /etc/fstab.old2
./mv /etc/fstab.old /etc/fstab
After that, I was able to reboot successfully.

Any advice out there?

Thanks

I don't know.. I've experimented with MTU as far as up to 9000 on the virtual NIC and the VMware switch and have seen throughput up to about 150Mbps but it's wildly inconsistent.

I really got into this thread because I found the original post interesting and was able to replicate a similar issue in my personal (home) setup.  It is not, in fact, a real problem for me as I do so little inter-vlan routing on my home network that it doesn't affect me one way or the other.

One thing I can verify is that my shaper config limits inter-vlan traffic; disabling the root queue on the DMZ interface allows much faster throughput during a sustained NFS -> local storage transfer on a DMZ machine from a NFS mount in LAN.  But that's for a different forum.

Have you tried "disable Source/Destination Check" on the AWS pfSense instance?  Just a thought.

Hey mate

Massive thank you! I created the same rule for OPT1 and my kali box now sees both pfsense and the outside world!

Thanks again

Scotty

I had a problem with bridged networks after that update. Checking vmware network config I found that there was no bridged network (settings removed). The solution is to reset the setting thus restoring the bridged connection. After that things worked fine again…lesson learned, don't trust MS

here is a link to an explanation as to why this happens...

https://chentiangemalc.wordpress.com/2015/07/09/windows-10-build-upgrades-break-vmware-workstation-network/

You can't if you aren't directly connected to the LAN-side with no NAT. VirtualBox ruins most of that all the time.

All the answers above are rights. I just would like to add that if you need some kind of sniffing possibilities, you can add another port in your vswitch with VLAN 4095. Authorized promiscuous mode on this port only. Attach to this lan your sniffing machine in stealth mode and you have some kinds of span port on your switch without allowing all machines to enter promiscuous mode.

Thanks that has given me confidence to go forward with just 2x ports.. Is it difficult to setup the vlan in esxi? I've found rough text guides but nothing too detailed, do I need to create a route for the vlan so I can access the network over my main LAN?

Thanks again

I've fixed this issue.

For anyone wondering it was network drivers on the Hyper-V host (or lack of!)