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

Well.. I've found the problem, and boy do I feel stupid!  :-[

Turns out I hadn't allocated enough RAM to my Dom0. Whenever I launched the pfSense HVM, the Dom0 would run out of RAM and crash xl.

Changed the allocation on the boot line from 256M to 2G, and it works beautifully.  8)

Thank you very much for the reply

Migrating to 2012 R2 is not a valid option for me right now.
I will continue searching for something or waiting for an update of the FreeBSD kernel in which pfSense runs  :-\