I'm assuming the VHD is a custom image and not marketplace pfSense?

To confirm:

So your setup looks like this on Azure right – assuming the vhd has one interface assigned on deployment

pfSense                Nic1  (WAN)              {what subnet?} 
                      Nic2  (not yet assigned) {what subnet?}
                      Nic3  (not yet assigned) {what subnet?}
                      Nic4  (not yet assigned) {what subnet?}

When you assign & enable Nic2, you lose connectivity? How are users connecting VPN, public ip, etc?

I am running 5 dedicated servers all with virtual pfsense with hyper-v in OVH.  Did you buy a second IP?  Did you set the MAC address correctly on the pfsense virtual wan interface?  Did you add the commands to have the additional routes added to startup of pfsense?

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.