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!)

Update –  I decided to start from scratch without importing the entire backup from the working standalone server.

Instead, I created a new VM from the current 2.3.4 and established a working (albeit sparse installation).  From there I restored individual sections of the backup, each time rebooting to assure there was not an error encountered in the restore of the individual section.  As it turns out, all went well and all the sections/modules are now installed again and working flawlessly.

With the above, the only thing that I can think of is that the complete restore process has some issues.  Perhaps someone can help with debugging the complete restore process..

Anyway, thanks for the help.

I've had some initial success getting pfSense 2.3.4 running on Oracle Compute Cloud.  It requires several manual changes to the configuration before launching the image on Oracle Cloud

A few pointers so far:

The interfaces names change from em0 to xn0 because VirtualBox and the Oracle Compute hypervisor use different drivers. Oracle Compute is Xen based and pfSense uses the Xen PV-HVM drivers by default for the nics.  The WAN and LAN <if>setting in the config.xml must match the interface names the image boots with on Oracle Compute</if>

If the interfaces are not pre-configured correctly pfSense prompts to start the setup on the serial console, but Oracle Compute has no direct console input so the boot halts without any interfaces setup.

Both a WAN and LAN interface need to be defined for pfSense to fully boot.  The LAN interface defaults to 192.168.1.1, this needs to be set to correct IP network interface that the instance will be launched with, note the 192.168.1.1 address can't be used even if you create a 192.168.1.1/24 IP network as the first address is allocated for use for the default IP Network routing

The default dhclient for FreeBSD 10.3 has issues with the pv-hvm drivers and Oracle Compute due to an issue with TCP RX checksum offloading, which results in the interface not being able to get its IP from DHCP - one workaround is to set hw.xen.disable_pv_nics=1 in the /boot/loader.conf.local, or use manually assigned IP on the interface

If you are using pfSense with the WAN interface on the Oracle Compute shared network all traffic is blocked be default as pfSense filters private and bogon ip address ranges on the WAN interface. The Oracle Compute shared network uses a 10.x.x.x range, with floating public IPs. The fix is to remove the <blockpriv>and <blockbogons>from the wan section in the config.xml</blockbogons></blockpriv>

Enable sshd to allow remote administration

To allow management over the WAN interface add a rule to enable inbound ssh and http(s) traffic

To access the webConfigurator over the WAN interface enable the <nodnsrebindcheck>and <nohttpreferercheck>options in the <webgui>section of the config.xml</webgui></nohttpreferercheck></nodnsrebindcheck>

The pfSense dhcpd configuration should be disabled as DHCP is already provided in the Oracle Compute Shared and IP networks

@MaximMasiutin:

OpenBSD appears to support the vmware paravirtual scsi driver using the vmwpvs driver. Can this driver be installed into freebsd?

No, OpenBSD and FreeBSD are two different animals. OpenBSD diverged from NetBSD which itself wasn't based on FreeBSD. The KPI/KBIs are very different and the drivers from one OS can't be used on the other.

I was able to get SR-IOV running; you need a setting in boot/loader.conf as described here
https://lists.freebsd.org/pipermail/freebsd-bugs/2015-October/064355.html

Even without using SR-IOV this improves the performance. I am able to measure rates about 8 Gbit/s at MTU 1500
using one system on esxi.

However it seems to be difficult to reach more than 5 Mpps using Freebsd on a hypervisor.

170518_Throughput.PNG
170518_Throughput.PNG_thumb

You would have to add static routes for the VPN'ed subnets to your clients or, ideally, to the physical pfSense router.

Recently having issues with my IPSec tunnels to my AWS VPC created with the "AWS VPC VPN Wizard", I opened a ticket with AWS support. I ended up sharing my IPSec settings and logs with AWS VPN support. They wrote me back an informed me that the IPSec tunnels were not configured correctly! AWS said that both tunnels were not supposed to be active at the same time, and their logs and my logs showed that traffic was traveling across both tunnels. They said that only one tunnel was supposed to be active and have traffic routed over it, and the second tunnel was only to be a standby to be used if the first tunnel was down or not passing traffic. I have opened a ticket with NetGate (the current developer of pfSense who offers commercial support), to investigate these issues. I'll post back the results of their findings here.

I had to add pass rules in opt1, traffic was blocked by default.

Reinstall resolved issue.  I think I shut it down improperly once during initial install.

When looking at the possible deploying of dozens of units I am factoring in the potential savings of going opensource.  Zen..,etc

I also use on hyper-v on 5 dedicated servers in OVH including hyper v replication.

Though I just deployed hyperv 2016 and having issues with latest pfsense image.

@linuxjunkie:

Hi

I have pfSense 2.3.3-1 AMD64 running on VMWARE ESX 5.5u3. It is installed according to this KB https://doc.pfsense.org/index.php/PfSense_on_VMware_vSphere_/_ESXi

The firewall performs great but the vmware console stops responding to input after about 2 minutes of inactivity.

The https interface works fine and so does SSH access into the firewall. Just the virtual console in vmware is impacted.

The only way I can get back to the virtual console is to reboot the firewall which is a bit of a pain.

Any ideas?

Does this issue impact any other VMs on the same host?  I'm running pfSense 2.3.x on several ESXi hosts, from ESXi 6.5 down to ESXi 5.0 and have never seen this.

Have you tried with different drivers versions for physical nic that you are using for Wan?
IE the driver in the host operating system?

In worst case it might even be worth to try another nic (If it doesn't do anything else it will rule out the nic as the cause)

are you on W10 pro or better?
if so you got hyper-v available and in my eyes it's better for this jobb